Spring Cloud Gateway Token Relay：OAuth2客户端身份确认

1. TokenRelay场景下的OAuth2客户端到底是谁？ #

• 这个场景里，网关本身确实是OAuth2机密客户端——这是TokenRelay的核心设计逻辑：网关作为已通过SAML2认证的用户会话与后端OAuth2资源服务器之间的中介，代替用户完成令牌的获取、刷新和中继。
• 你看到浏览器发起授权码调用，大概率是初始配置未正确关联网关的客户端身份与SAML2会话逻辑，导致流程偏离了TokenRelay的预期，变成了前端直接对接OAuth2授权服务器。

2. 为什么会出现浏览器发起授权码调用？ #

• 常见原因是网关同时配置了面向前端的默认OAuth2登录流（比如spring-boot-starter-oauth2-client的默认配置），但未正确将SAML2会话绑定到网关的OAuth2客户端上下文。
• TokenRelay的正常流程应该是：用户通过SAML2在网关建立会话后，网关以自身机密客户端身份，用用户的SAML2身份凭证向OAuth2授权服务器换取令牌，再将令牌中继到后端服务——全程浏览器仅与网关交互，不直接对接OAuth2授权服务器。

3. 机密客户端身份是否还能保留？ #

• 当然可以，且这是推荐模式。只要做好两点：
  • 将网关的OAuth2客户端配置为机密模式（设置client-secret，禁用依赖浏览器跳转的redirect-uri逻辑）；
  • 配置SAML2到OAuth2的身份映射：利用网关的SAML2认证过滤器提取用户身份信息，让网关以客户端凭证+用户身份断言的方式请求令牌，而非让浏览器发起授权码交换。
• 若错误让浏览器直接参与授权码交换，会因无法安全存储客户端密钥而丢失机密客户端的安全性，这种情况下才需要考虑PKCE，但这并非TokenRelay的正确实现方式。

4. 正确配置的核心要点 #

• 确保网关引入依赖：spring-cloud-starter-gateway、spring-boot-starter-oauth2-client、spring-boot-starter-security-saml2-service-provider；
• 配置网关作为SAML2服务提供者，对接SAML2身份提供商，完成用户会话建立；
• 配置网关作为OAuth2机密客户端，指定client-id、client-secret、授权服务器地址，通过自定义OAuth2AuthorizedClientProvider实现基于SAML2断言的令牌获取逻辑；
• 启用TokenRelayGatewayFilterFactory，确保网关将获取到的OAuth2令牌添加至向后端服务的请求头中。

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