OpenID Connect社交登录如何在REST API侧完成令牌校验

你的核心架构选型没有原则性错误，基于PKCE的授权码流程是当前OAuth2.0针对SPA这类公共客户端的标准推荐方案，localStorage存储令牌做不到100%安全是公共客户端的天生限制，不需要追求绝对安全，只要把风险控制在可接受范围即可。但当前设计里有两个关键认知偏差需要先纠正：

• ID Token从设计上就不是给后端做API鉴权用的，它的作用是供前端客户端自身核验用户身份、拉取基础用户信息，后端鉴权只应该认可Access Token，你现在把ID Token纳入后端凭证范围本身就是不必要的风险来源
• 不存在“100%确认请求来自己方SPA”的技术手段，前端代码、客户端环境对用户完全透明，你能做到的是“只有己方SPA合法申请的令牌，才能通过后端校验”，不要在不可能实现的目标上浪费精力

仅靠校验client_id、redirect_uri、可信IdP列表完全不足以防范令牌冒用，必须补全以下校验逻辑，这些都是标准JWT/OAuth校验的必选项：

• 所有传入后端的Access Token必须先做完整的签名校验：后端要拉取对应身份提供商的公钥，确认令牌没有被篡改、确实是可信IdP签发的，之后依次校验iss（签发方）在你维护的可信IdP列表内、aud（受众）字段明确包含你后端服务的唯一标识、exp（过期时间）未失效，以上任何一项不匹配直接返回401
• 授权请求阶段固定resource参数：在SPA发起授权请求时，明确指定resource为你后端服务的标识，IdP签发的Access Token就会仅对你后端的aud生效，哪怕攻击者盗取了同个用户在其他第三方客户端下的有效令牌，也会因为aud不匹配被你的后端拦截
• redirect_uri的校验是IdP侧的责任，你不需要在后端重复做这层校验，只要保证在IdP后台配置的SPA回调地址是精确匹配、没有通配符即可，避免授权码被截获跳转到恶意站点

你担心的长有效期ID Token风险，本质是用错了ID Token的场景：ID Token只需要在前端完成登录初始化时使用一次，后续所有API请求完全不需要携带ID Token，自然不需要承担它被盗的风险。针对localStorage存储令牌的固有风险，落地以下措施即可把风险降到可控范围：

• Access Token有效期严格控制在15-30分钟，不要设置更长的有效期，即便令牌被盗，攻击者的可用窗口极短
• Refresh Token必须开启轮换+一次性使用机制：每次用Refresh Token换取新Access Token时，IdP必须同步返回新的Refresh Token，旧的Refresh Token直接作废；一旦检测到已经作废的Refresh Token被发起兑换请求，直接判定为令牌泄露，立刻吊销该用户名下所有有效令牌，强制用户重新登录
• 不要在JWT令牌内写入用户权限、角色等敏感鉴权信息：后端在首次校验Access Token合法后，可将用户ID与权限的映射存在服务端缓存中，令牌仅作为用户身份的索引，即便令牌被盗，攻击者也无法绕过服务端的权限校验获取高权限操作资格
• 补充低成本的基础防护：校验API请求的Origin、Referer头是否为你部署SPA的官方域名，这类校验虽然不能防住高级攻击者，但可以拦截绝大多数低水平的跨站盗用攻击；高敏感操作（支付、修改账号绑定信息等）不要只认令牌，增加二次密码/验证码校验环节
• 前端传递Access Token时统一放在Authorization: Bearer <token>请求头中，不要放在URL参数、POST表单字段里，避免被日志系统记录造成泄露

如果你的业务安全等级要求较高，可以评估将令牌存储在HttpOnly+Secure+SameSite=Strict属性的Cookie中，这种存储方式可以规避大部分XSS盗号风险，但需要配套做CSRF防护，可根据团队的安全运维能力选择存储方案。不要自研令牌加密、前端代码混淆这类“伪安全”措施，这类方案防君子不防小人，反而会提升后续维护成本，严格遵循OAuth2.0公共客户端的标准规范即可满足绝大多数业务场景的安全要求。

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