SPA分离认证与授权服务器架构下的令牌使用问题咨询

你当前的系统组件拆分：

• UI层：单页应用（SPA）
• 外部认证服务器：负责用户身份核验，签发AuthN认证令牌
• 自建授权服务器：负责用户权限判定，签发AuthZ授权令牌
• 资源服务器：自建后端API服务，提供业务数据
  当前设计的交互流程：

1. 用户端首先从外部认证服务器获取AuthN令牌
2. 前端携带AuthN令牌向自建授权服务器请求兑换AuthZ令牌
3. 前端持AuthZ令牌向资源服务器请求业务数据
   核心待解决问题：第三步请求仅携带AuthZ令牌时，无法判定用户当前认证状态是否仍有效，需要明确是采用双令牌携带方案，还是通过机制整合为单令牌使用。

首先明确：非常不推荐前端请求资源时同时携带两类令牌直传资源服务器，核心原因：

• 违背令牌职责分离原则：AuthN的作用是证明用户身份有效，AuthZ的作用是证明用户有对应资源的访问权限，资源服务器核心职责是处理业务逻辑，强行要求它对接外部认证服务器校验AuthN，会平白增加外部依赖，一旦外部认证服务抖动、故障，所有业务接口会全部不可用，可用性极差。
• 增大安全风险：两类令牌都存储在前端、每次请求全量传输，既增加了请求体积，也扩大了令牌泄露的攻击面。

下面是两种可直接落地的方案，优先推荐第一种单令牌方案，适配你当前的架构设计，改动量最小。

方案1：授权服务器签发阶段绑定认证状态，单AuthZ令牌全链路通行 #

这个方案全程不需要前端感知AuthN的存在，资源服务器也不需要对接外部认证服务，所有认证状态关联逻辑全部收敛在自建授权服务器处理：

1. 换票环节绑定认证关联关系
   前端持AuthN令牌请求兑换AuthZ令牌时，授权服务器首先调用外部认证服务器接口校验AuthN的有效性，确认有效后再签发AuthZ令牌。签发时把两类信息写入令牌（如果用JWT格式就直接写入payload，如果是引用令牌就存在令牌对应的服务端缓存记录中）：
   • 对应AuthN令牌的唯一标识（比如AuthN的jti字段，或者用户ID+AuthN签发时间的组合值）
   • 认证状态有效期：和当前AuthN令牌的剩余有效期完全对齐
2. 分层设置令牌有效期，续期时同步校验认证状态
   给AuthZ设置较短的业务访问有效期（比如15分钟），同时配套签发刷新令牌（refresh token），刷新令牌的有效期和外部AuthN的最长有效期对齐。
   当前端持刷新令牌请求续期新的AuthZ时，授权服务器首先根据绑定关系查询对应AuthN的当前状态：如果AuthN仍有效，就签发新的短期AuthZ；如果AuthN已经失效（比如用户在外部认证侧主动登出、账号被封禁、令牌过期），直接拒绝续期请求，要求用户重新走认证流程。
3. 实时状态失效兜底
   如果需要做到认证状态变更的实时感知（比如用户在外部认证侧刚登出，就要立刻让他名下所有有效AuthZ失效），可以对接外部认证服务器的状态变更回调（webhook），授权服务器收到用户登出、账号封禁这类事件后，直接把对应用户名下所有未过期的AuthZ、刷新令牌加入黑名单。资源服务器校验AuthZ时，先校验令牌是否在黑名单中，再校验权限即可。

这个方案下，前端只需要存储、传输AuthZ和对应的刷新令牌，资源服务器只需要和自建授权服务器做令牌合法性、权限校验，完全不需要感知外部认证服务器的存在，三层服务职责完全解耦，后续如果更换外部认证源，只需要改授权服务器的对接逻辑，其他层完全不用动。

方案2：网关层统一处理双令牌校验（适合已有成熟API网关的场景） #

如果你现有架构已经有统一的入口API网关，不想调整授权服务器现有签发逻辑，可以把双令牌校验逻辑收敛在网关层处理，不要透传给资源服务器：

1. 前端请求时把AuthN、AuthZ令牌都放在请求头中，统一发给API网关
2. 网关收到请求后，首先校验AuthZ令牌的合法性、权限范围，校验通过后再校验AuthN的有效状态，两类校验都通过后，再把用户身份、权限信息通过内部请求头透传给后端资源服务器，资源服务器不需要直接处理两类令牌，只需要读取网关透传的身份信息即可。
3. 网关层可以对AuthN的校验结果做短时间本地缓存（比如缓存30s~1min），避免每次请求都调用外部认证服务器接口，降低接口延迟。
   这个方案的缺点是网关层需要新增外部认证服务的对接逻辑，前端需要同时存储两类令牌，安全风险比方案1稍高，适合已有成熟网关体系、不想改动现有授权服务逻辑的场景。

注意：无论选择哪种方案，都不要让资源服务器直接对接外部认证服务器做校验，否则会把认证、授权、资源三层逻辑完全耦合，后续调整认证源、修改权限规则时改动量会非常大。

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