OAuth 用於帶有 API 網關的微服務 - 架構

Question

在微服務架構中，API 網關位於 API 之前。這樣做的目的是更改一些請求/響應參數，用於單個入口點或檢查身份驗證等。現在我想使用 OAuth2 流程保護我的 API 以獲取訪問令牌。 問題是決定誰是實際的 OAuth 客戶端，我將使用 SPA 示例來演示它：

---

a) 是否是 SPA 通過使用隱式授權啟動了 oauthorize 請求（到 api 網關）。 然后，Api 網關會簡單地將請求路由到 OAuth 授權服務器，充當單個入口點，使用隱式流中的 /authorize 內容

b) 是API Gateway本身嗎，意思是SPA把終端用戶的用戶名和密碼發給api網關（當然這里SPA需要用終端用戶憑證來信任），然后SPA自己作為一個oauth 客戶端使用資源所有者密碼授予

c) 完全關閉 api 網關並創建與 api 網關“並行”的 oauth 授權服務器，這意味着您將失去單一入口點等。

---

下圖展示了一個很抽象的架構，問題是關於數字“[2]”，如果這個請求是由SPA發起並由api網關通過，或者api網關正在攔截請求並作用於它自己作為 oauth 客戶端？

OAuth 與 API 網關

我的猜測是始終為特定客戶端使用最合適的授權類型，無論 API 網關是否介於兩者之間。 這意味着，當涉及到 OAuth 時，API 網關將簡單地傳遞客戶端授權請求，無論它使用什么授權類型。 因此，圖片中的 [2] 將來自客戶端，而不是來自充當 OAuth 客戶端的 API 網關。 這樣對嗎？ 如前所述，對於第一方應用程序，這真的很棘手，因為您可能會使用密碼憑據授予，但它有很大的缺點，例如，SPA 無法刷新。

Answer 1

請記住，這是純粹基於觀點的答案，因為您的問題非常模糊。

我不喜歡使用API​​網關作為對請求進行身份驗證的觀點。 我認為這違反了單一責任原則。 網關的目的通常是將您的后端暴露給外部客戶端，也許更改某些特定客戶端的合同等。但是，它也不應該對呼叫進行身份驗證。 除此之外，它還必須基於傳遞給它的數據來執行此操作，無論如何，您都必須將其收集在其他位置。

我認為不希望發生的另一件事是，您正在考慮為SPA使用資源所有者密碼授予。 這不是此授予流程的正確用例。 您可以查看這篇文章，它比我能更好地解釋它： https : //www.scottbrady91.com/OAuth/Why-the-Resource-Owner-Password-Credentials-Grant-Type-is-not-Authentication-也不適合現代應用

我建議您使用Implicit授予類型，並使用api網關僅將調用路由到后端，而不對該層上的調用進行身份驗證。

如果您使用的是Spring Cloud API網關（本質上是zuul代理），則必須添加適當的配置，以便它轉發所有安全標頭並重定向。 這個例子對我有用：

server:
    use-forward-headers: true

zuul:
    addHostHeader: true
    routes:
        <your oauth server route>:
            url: <your oauth server url>
            path: <if youve got any prefix>
            sensitiveHeaders:
            stripPrefix: false

Answer 2

沒關系，Krzysztof Chris Mejka 在之前的回答中喜歡或不喜歡什么。 看看 BCP - https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#section-6

IETF oauth 工作組的最新建議是使用一種 Api 網關/反向代理，換句話說 - 你需要將令牌完全排除在 js 之外。