微服务架构中基于JWT的授权服务性能优化：避免授权服务器过载的策略

授权服务负载挑战与常见误区

在采用微服务架构的企业级应用中，授权服务（如基于keycloak构建）承担着用户认证和权限验证的关键职责。当系统面临数百万用户并发访问时，一个常见的误区是让每个微服务在处理每个api请求时都去调用授权服务来验证jwt（json web token）。这种模式会导致授权服务器成为整个系统的性能瓶颈，因为它需要处理海量的验证请求，从而在高负载下变得繁忙甚至崩溃。简单地增加授权服务实例进行负载均衡，并不能从根本上解决问题，因为核心问题在于不必要的频繁通信。

JWT的自包含特性与本地验证机制

JWT之所以能够解决上述问题，在于其“自包含”的特性。一个JWT通常由三部分组成：头部（Header）、载荷（Payload）和签名（Signature）。

• 头部：包含令牌类型（JWT）和所使用的签名算法（如HMAC SHA256或RSA）。
• 载荷：包含声明（claims），如用户ID、角色、权限、过期时间等。
• 签名：由头部和载荷通过特定算法和授权服务器的私钥生成。

关键在于，JWT的签名可以使用授权服务器的公钥进行验证。这意味着，任何拥有该公钥的实体（即资源服务器）都可以在不与授权服务器通信的情况下，独立验证JWT的真实性、完整性和有效期。

优化后的授权验证流程

为了在高并发场景下有效管理授权服务负载，应遵循以下优化后的JWT验证流程：

1. 用户认证与JWT获取：

   • 用户向授权服务器（例如Keycloak）提交凭证进行认证。
   • 授权服务器验证用户身份，成功后生成一个JWT，并使用其私钥对JWT进行签名。
   • 授权服务器将签名的JWT返回给客户端。
   • 客户端在后续请求中携带此JWT。

2. 资源服务器公钥获取：

   • 每个资源服务器（即业务微服务）在启动时，或通过周期性刷新机制，向授权服务器获取其用于签名的公钥。通常，授权服务器会通过一个标准的JWKS（JSON Web Key Set）端点暴露其公钥（例如/.well-known/jwks.json）。
   • 资源服务器将获取到的公钥缓存在本地。

3. 本地JWT验证：

   • 当客户端向资源服务器发送带有JWT的请求时，资源服务器执行以下操作：
     • 解析JWT：从请求头中提取JWT。
     • 验证签名：使用本地缓存的授权服务器公钥验证JWT的签名。如果签名无效，则拒绝请求。
     • 验证有效期：检查JWT的exp（过期时间）声明，确保令牌尚未过期。
     • 验证其他声明：根据业务需求，验证iss（签发者）、aud（受众）、scope（作用域）等声明，确保令牌适用于当前资源。
     • 授权决策：基于JWT中的权限声明（如角色、权限列表）进行授权决策。

核心优势：一旦资源服务器获取并缓存了公钥，后续对该资源服务器的每个请求的JWT验证都可以在本地完成，无需再与授权服务器进行通信。这极大地降低了授权服务器的负载，使其仅需处理初次认证和JWT签发请求，而非每次API调用的验证请求。

星绘

豆包旗下 AI 写真、P 图、换装和视频生成

下载

示例配置（以Spring Boot为例）

在Spring Boot微服务中，结合Spring Security和OAuth2 Resource Server，可以非常便捷地实现本地JWT验证。

假设您的授权服务器（Keycloak）暴露了JWKS端点，您可以在application.yml中配置资源服务器：

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          # 配置授权服务器的JWKS URI，Spring Security会自动从中获取公钥并进行本地验证
          jwk-set-uri: "http://your-keycloak-server/realms/your-realm/protocol/openid-connect/certs"
          # 或者，如果授权服务器只暴露了单个公钥（不推荐，JWKS更灵活）
          # public-key-location: classpath:public.pem

通过以上配置，Spring Security框架会自动处理：

1. 在应用启动时或首次验证时，从jwk-set-uri获取JWKS。
2. 缓存JWKS中的公钥。
3. 对传入的JWT进行本地签名验证、过期时间验证等。

开发人员只需关注基于JWT中声明的业务授权逻辑，而无需手动编写JWT解析和验证代码。

注意事项

• JWT有效期管理：JWT应设置合理的有效期。过短会增加用户重新认证的频率，过长则增加安全风险（如令牌泄露）。客户端应处理JWT过期后的刷新或重新认证流程。
• 令牌撤销（Token Revocation）：JWT的无状态性意味着一旦签发，即使授权服务器想撤销它（例如用户登出、密码更改或安全事件），资源服务器也无法立即感知。解决方案包括：
  • 短生命周期JWT：配合刷新令牌（Refresh Token）机制，缩短访问令牌的生命周期，降低风险窗口。
  • 黑名单机制：在授权服务器维护一个已撤销JWT的黑名单，资源服务器在关键操作前可选择性地查询黑名单（这会引入对授权服务器的查询，但频率远低于每次验证）。
  • Opaque Token：对于特别敏感的操作，可以考虑使用不透明令牌，每次都需要授权服务器进行验证。
• 公钥轮换：授权服务器可能会出于安全考虑定期轮换其签名密钥。资源服务器必须能够感知并更新本地缓存的公钥，通常通过定期重新请求JWKS端点来实现。
• 声明验证：除了签名和有效期，资源服务器还应验证JWT中的其他关键声明，如audience（受众）和issuer（签发者），确保令牌是为当前服务签发且由正确的授权服务器签发。
• 安全性：确保JWKS端点通过HTTPS访问，防止公钥被篡改。

总结

在微服务架构中，处理海量用户并发的授权问题，关键在于充分利用JWT的自包含特性。通过将JWT的验证逻辑从授权服务器转移到资源服务器本地，并辅以公钥缓存机制，可以大幅降低授权服务器的负载，避免其成为系统瓶颈。这种策略不仅提升了系统的可伸缩性和性能，也简化了授权流程，是工业级应用中实现高效、安全授权的推荐实践。