带有 API 网关的微服务 OAuth - 架构

Question

在微服务架构中，API 网关位于 API 前面。这样做的目的是例如更改一些请求/响应参数，用于单个入口点或检查身份验证等。现在我想使用 OAuth2 流来保护我的 API 以获取访问令牌。问题是要决定谁是实际的 OAuth 客户端，我将通过一个 SPA 示例进行演示：

---

a) 是否是 SPA 使用隐式授权启动了 oauthorize 请求（到 api 网关）。然后，Api 网关将简单地将请求路由到 OAuth 授权服务器，充当单个入口点，使用来自隐式流的 /authorize 内容

b) 是不是 API 网关本身，意思是 SPA 将最终用户的用户名和密码发送到 api 网关（当然，这里 SPA 需要用最终用户的凭据来信任），然后作用于它的使用资源所有者密码授权作为 oauth 客户端拥有

c) 完全关闭 api 网关并创建与 api 网关“并行”的 oauth 授权服务器，这意味着您将失去单个入口点等。

---

下图展示了一个很抽象的架构，问题是关于“[2]”这个数字，这个请求是SPA发起并经过api网关，还是api网关在拦截请求并作为 oauth 客户端自行操作？

OAuth with API Gateway

我的猜测是始终为特定客户端使用最合适的授权类型，无论 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-nor-Suitable-for-Modern-Applications

我建议您使用隐式授权类型并使用 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