SPA与后端OpenID Connect安全架构选型及跨端认证问题咨询

一、反向代理作为RP的方案合理性分析 #

该方案是多遗留系统场景下切换OIDC体系的高性价比选择，合理性较高，各子问题解答如下：

1. 遗留系统对接便利性 #

该方案对接遗留系统的成本远低于各后端独立适配的方案：

• 所有后端不需要改造OIDC校验逻辑，仅需要信任反向代理传递的x-userinfo请求头即可获取用户身份信息，不需要为不同技术栈的后端引入适配OIDC的SDK，改造工作量极低
• 认证逻辑统一收敛到反向代理层，JWT有效性校验、过期处理、签名算法升级等安全逻辑只需要在代理层维护一次，不需要每个后端单独迭代，后续运维成本更低

2. Authz逻辑放在RP的潜在问题 #

• 细粒度授权适配能力有限：RP仅能实现路径、角色类的粗粒度权限校验，涉及业务属性的细粒度授权（比如用户仅能编辑自己提交的单据）无法在RP层实现，强行下放业务逻辑到RP会导致代理配置极度臃肿，性能大幅下降
• 必须严格控制访问边界：所有受保护的后端必须禁止公网直接访问，仅能通过反向代理入口访问，否则攻击者可以直接伪造x-userinfo请求头绕过认证，需要额外配置网络ACL限制后端的访问来源
• 单点故障风险：反向代理层是整个保护域的认证入口，一旦出现故障所有服务都会认证失效，需要提前做好代理集群的高可用部署
• 内部调用信任风险：后端间透传x-userinfo头的场景下，需要保证内部服务调用链路完全可信，避免内部服务被攻陷后伪造头信息越权访问其他内部服务
• 回调地址选择：如果IdP仅注册了RP的域名，回调地址直接填RP地址即可，RP完成授权码兑换令牌的流程后再将令牌返回给SPA，该模式安全性更高，避免令牌暴露在浏览器跳转链路中

3. 完整跳转流程 #

1. 未登录用户访问Angular SPA，SPA发起业务API请求到反向代理RP
2. RP检测到请求未携带有效JWT，返回401状态码，同时在响应头中携带IdP登录地址
3. SPA接收到401响应后，跳转到IdP登录页，用户完成身份校验
4. IdP携带授权码跳转到预先注册的RP回调地址
5. RP使用授权码向IdP兑换id_token、access_token、refresh_token
6. RP通过302跳转将令牌返回给SPA，跳转目标为SPA的业务页面，令牌可放在响应头或者短期有效的URL参数中传递
7. 后续SPA的所有请求都携带access_token，RP校验令牌有效性通过后，将用户身份信息解析到x-userinfo头中转发给后端服务

二、Swing应用唤起Angular的跨端免登方案 #

可以实现无感知跨端认证，不需要用户二次登录，优先推荐第一种方案：

方案1：IdP会话共享（推荐） #

• 前置条件：Swing应用登录时已经通过OIDC流程在IdP侧种下了有效的用户会话Cookie
• 流程：Swing唤起系统默认浏览器打开Angular应用地址，Angular检测到本地无有效JWT，自动跳转到IdP登录页；IdP检测到当前浏览器存在有效会话，不需要用户输入账号密码，直接携带授权码跳回Angular的回调地址，Angular完成后续令牌兑换流程，整个跳转过程毫秒级完成，用户无感知

方案2：加密令牌传递 #

适用于Swing应用未走IdP统一登录的场景：

• 流程：Swing应用本地存储了当前用户的有效access_token，唤起浏览器时将令牌做AES对称加密后作为URL参数传递给Angular应用，参数设置5分钟内有效
• 校验逻辑：Angular拿到加密参数后解密，自行校验令牌的签名、有效期，校验通过后将令牌存入localStorage完成登录

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