后端API的OpenID Connect JWT令牌验证及使用策略：JWKS还是自建会话？

方案对比与推荐 #

优先选择方案二，具体原因和实现要点如下：

方案一的缺陷 #

• id_token的设计初衷是身份认证凭证，并非用于API授权的访问凭证，标准OIDC协议中明确不推荐将id_token作为API请求的授权令牌使用
• 不同第三方身份提供商签发的id_token有效期、携带的字段规则不统一，你需要兼容多提供商的验证规则，后续维护成本极高
• 你无法自定义id_token的载荷内容，没法往里面加业务需要的用户权限、角色、自有系统用户ID等字段，后续业务扩展非常受限
• 每次请求都要调用对应提供商的JWKS接口做验签，一旦第三方提供商服务不可用，你的接口也会跟着批量失效，可用性完全不受自己控制

方案二的优势与实现要点 #

• 你可以完全自主定义自有JWT的有效期、载荷字段，比如加入自有系统的用户ID、角色、权限列表等业务需要的内容，后续业务扩展灵活
• 验签只需要用你自己服务的密钥，不依赖第三方服务可用性，接口稳定性完全可控
• 实现流程非常契合你当前的技术栈：
  1. 拿到第三方返回的id_token之后，先做完整性校验：验证签名、issuer签发者、aud受众、有效期，确保身份信息合法
  2. 用id_token里的用户唯一标识（通常是sub字段）匹配你自有系统的用户账号，如果是首次登录就自动完成注册流程，绑定对应第三方身份提供商信息
  3. 生成自有服务签发的JWT，返回给前端React SPA使用
  4. 后续前端每次请求API的时候在Authorization头携带Bearer <你的自有JWT>，后端直接用自有密钥验签，读取载荷里的用户信息做权限校验即可
• 你用的node-openid-client本身已经封装了id_token的校验方法，hapi也有现成的JWT认证插件，整个流程的实现成本非常低

额外注意事项 #

• 第三方返回的access_token不要返回给前端，这个令牌是你后端和第三方身份提供商交互用的，比如后续需要拉取用户更多信息、刷新令牌的时候使用，存在后端即可
• 自有JWT建议用非对称加密（RS256）签发，私钥存在后端服务，验签用公钥即可，安全性更高

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