微服务中的身份验证模式

Question

有几种方法可用于管理微服务中的身份验证，包括服务到服务身份验证。我想了解哪种方法更好。

>

当用户登录到系统身份验证服务调用时，身份验证服务返回不透明令牌（不是 JWT），则每个 API 调用都包含该不透明令牌网关通过身份验证服务验证令牌，为下游服务生成新的 JWT 令牌。因此，下游服务不必每次都调用身份验证服务来验证令牌。

从一开始，身份验证服务将生成一个 JWT 令牌。

2.1. 网关将通过下游服务进行验证和传递，所有服务将使用相同的令牌

2.2. 网关每次都会验证并生成一个新令牌，下游服务也会这样做。

每种方法都有其优点和缺点。

问题：

方法1.网关每次都需要进行身份验证服务调用才能验证？

方法2.JWT 代币的到期时间是多久？谁需要处理过期，谁需要再次生成它之间的什么令牌过期？JWT 令牌必须是短暂的，因此它是否不会影响客户端行为或刷新令牌应该在此处出现。

所以我对哪种方法是好的感到困惑，或者还有其他方法。请告诉我。

Answer 1

应避免向外界公开 JWT，因为这些 JWT 可能包含自定义声明中的敏感信息。特别是如果您在一家大公司工作，您无法跟踪最终导致不同索赔的内容。

因此，如果使用 opague 令牌（您应该这样做），网关应验证令牌并将其交换为可在网络内部使用的 JWT。

所有服务的设置都应始终牢记零信任。

如果可能，所有服务都应获取 JWK 以验证传入的 JWT。这些 JWK 应该定期轮换。

这是为了避免如果恶意行为者访问内部网络，他不应该仅仅因为他通过了网关而对任何服务发出任何请求。

当涉及到到期时间时，这些时间应该由发行人设定，并且应该保持简短，因为其中一个大问题是发行代币很容易，但撤销代币更难。

流程通常是这样的：

• 客户端登录并获得 AT（访问令牌）和 RT（刷新令牌）
• 客户端向后端中的服务提供不透明的 AT 令牌
• 网关将 opague 令牌交换为 JWT
• 网关将 JWT 传递给请求的服务
• 资源服务器验证 JWT
• 如果请求被拒绝，则向调用客户端返回 HTTP状态 401
• 客户端接收 401，然后向将颁发新 AT 令牌的颁发者提供其刷新。
• 请求重做新的 AT 令牌。