基于Azure AD的Spring OAuth2流程令牌验证问题求助

当前架构 #

• 前端（Angular）
• 反向代理（Nginx）
• BFF层（Spring Gateway & Spring OAuth2 Client）
• 身份提供商（Azure AD）
• 资源服务器（Spring Resource Server）

核心问题 #

基于Azure AD（login.live.com）的OAuth2流程中，资源服务器无法处理不透明access-token——该身份提供商未提供用于验证access-token的Introspect端点。

现有方案评估与优化建议 #

方案1：传递id_token给资源服务器 #

不符合OAuth2规范，且Spring官方未明确支持该模式，后续易出现兼容性问题，不建议采用。

方案2：BFF生成自定义JWT用于内部通信 #

• 优势：契合微服务内部认证的最佳实践，安全性可控，无需依赖外部厂商的认证端点。
• 实现路径：利用Spring Security或jjwt等成熟工具，在BFF层完成用户身份校验后，签发包含必要用户信息、权限范围的自定义JWT，传递给资源服务器；资源服务器仅需配置对应的密钥/公钥即可完成JWT验证。
• 成本说明：虽需额外开发JWT签发与验证逻辑，但Spring生态提供了完善的工具支撑，实现成本可控，长期维护性更强。

方案3：BFF全权处理集群内认证 #

存在请求伪造的安全隐患，若集群内服务未做额外校验，恶意服务可能绕过BFF发起非法请求，导致权限控制失效。若坚持此方案，需在K8s集群内启用服务间TLS加密，配合RBAC限制服务访问权限，同时在BFF与资源服务器间添加基于服务账号的二次校验，但整体安全风险仍高于方案2。

内容的提问来源于stack exchange，提问作者Matthias Kopeinigg