微服务中的授权和身份验证——好方法

Question

我正在考虑微服务架构，但我在授权和身份验证方面遇到了困难。我找到了很多关于 oauth2 和 openid connect 的资源，声称他们解决了问题，但对我来说还不够清楚。

假设我们有以下架构：

在我的系统中，我只想为role 定义的特定group 用户添加一项功能。我还想知道用户的name，他们的email和id。

经过研究，我发现以下解决方案是一个好的开始：

1. SPA 应用程序显示login form。
2. 用户填写表格并向authN&authZ server发送POST请求。
3. 服务器回复access token（作为JWT），其中包含用户的name、email、id和role。响应还包含 refresh token。
4. SPA 应用程序存储令牌并将其附加到它发出的每个请求中。
5. Microservice 1 和 Microservice 2 检查令牌是否有效。如果是，他们检查角色是否正确。如果是这样，他们会获取用户信息并处理请求。

我离好的解决方案还有多远？登录流程看起来像 Implicit flow with form post 描述的 here 但有隐式同意，我不确定它是否正常。

展望未来，我发现在JWT（例如name、email）中传递用户数据并不是一个好的解决方案，因为它会暴露敏感数据。我发现资源说建议只在令牌中公开对用户的引用（例如ID），并在向微服务发送请求时将此类令牌替换为reverser-proxy/api gateway 中的经典access_token .考虑到这样的解决方案，我认为以下场景是一个好的开始：

1. SPA 应用程序显示login form。
2. 用户填写表格并向authN&authZ server发送POST请求。
3. 服务器回复access token 和refresh token。 API 网关（中间）将 access token 替换为 ID token，并将访问令牌中的声明存储在其缓存中。
4. SPA 应用程序存储令牌并将其附加到它发出的每个请求中。
5. 处理请求时，API Gateway 接受 ID Token 并根据用户 ID 生成新的 access token。访问令牌被发送到微服务 1 或微服务 2，并像以前一样对其进行验证。

您如何找到这样的解决方案？这是一种安全的方法吗？我应该如何改进建议的流程？

提前致谢！

Answer 1

你在正确的轨道上：

零信任

这是一种新兴趋势，每个微服务都使用库验证 JWT - 请参阅 this article。 JWT 验证速度很快，并且可以扩展。

客户的机密令牌

互联网客户端应该无法读取 API 使用的声明。网关概念中的交换令牌是正确的，但通常的方法是在这里发布不透明的访问令牌，而不是使用 ID 令牌。在 Curity，我们称之为Phantom Token Approach。

浏览器中的安全 Cookie

需要注意的一个方面是在浏览器中使用令牌。这些天SameSite=strict HTTP Only cookie 是首选。不过，这需要更复杂的流程。有关安全性的一些建议，请参阅SPA Best Practices。

SPA 应该顺便使用代码流 - 旨在避免隐式流，因为它可能会泄漏浏览器历史记录或 Web 服务器日志中的令牌。

摘要

以上所有都是针对的通用安全设计模式，无论您的授权服务器如何，当然，一次一步达到目标是很常见的。

Answer 2

不要使用您自己的登录表单。正如 Garry Archer 所写，将身份验证代码流与 PKCE 结合使用，即 recomended flow 用于在浏览器中运行的应用程序。

如果您不想获取 ID 令牌，请不要在初始身份验证请求中要求 openid 范围。颁发的访问令牌的类型（JWT 或不透明）通常可以在您的 OAuth2 服务器上配置。所以我认为没有必要在你的网关上发行新的令牌。拥有更多的令牌发行者会打开更多攻击您的系统的方式。

您的后端模块可以使用userinfo endpoint，这将为他们提供有关用户的信息并验证令牌。这样，如果令牌无效（例如用户注销），请求处理将不会继续。如果您只验证 JWT 签名，您将不会知道令牌是否失效。

如果您计划在后端模块之间发出请求作为用户请求处理的一部分，只要您的模块处于安全环境（例如一个 Kubernates）中，您就可以使用从您的 SPA 收到的原始访问令牌。