SPA场景下受控后端调用第三方OAuth服务的身份认证方案咨询

先明确你提到的两种方案的问题 #

• 方案1的核心问题确实是Identity Token（身份令牌）仅用于前端验证用户身份，不能传递给后端服务，它的设计初衷就不是用来做令牌交换的，传递出去会带来安全风险。
• 方案2虽然规避了后端拿Identity Token的问题，但让SPA持有两个Access Token，一是增加了前端的令牌管理复杂度，二是如果服务C的权限范围需要动态调整，前端无法灵活处理，而且把服务C的令牌传给B，相当于让B拥有了用户直接访问C的权限，不符合最小权限原则。

标准解决方案：OAuth 2.0令牌交换流程 #

这是针对这类场景的规范做法，步骤如下：

1. 用户通过SPA A走「Authorization Code Flow with PKCE」流程，向颁发机构I申请并获取仅针对服务B的Access Token（不需要把Identity Token传给B）。
2. SPA A携带这个Access Token调用服务B的接口。
3. 服务B在需要调用服务C时，拿着自己的Access Token，向颁发机构I发起令牌交换请求：
   • 请求中指定需要换取的服务C权限范围
   • 同时通过自身的客户端凭证（比如B的Client ID和Secret）证明身份，确保颁发机构I信任B的请求
4. 颁发机构I验证B的身份、原Access Token的有效性，以及用户是否拥有访问C的权限后，颁发仅针对服务C的Access Token给B。
5. B使用这个新令牌调用服务C，完成请求后将结果返回给SPA A。

该方案的优势 #

• 完全遵循OAuth安全规范，Identity Token始终保留在SPA前端，不会泄露到后端服务
• 服务B只在需要时才换取服务C的令牌，符合按需授权和最小权限原则
• 令牌的生命周期、权限范围都由颁发机构I统一管控，安全性更高
• SPA只需管理一个针对B的Access Token，降低了前端的令牌维护复杂度

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