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 之外。