OAuth 2.0授权码流程实现内部JWT签发方案合规性与可行性咨询

问题1：流程合理性与合规性、缺陷说明 #

• 整体流程框架是合理的，符合OAuth 2.0授权码模式的核心要求，自研JWT解耦第三方IdP的设计也能满足内部自定义声明、统一权限管控的需求，但存在几个明显的安全和逻辑缺陷：
  1. JWT存储风险：你把JWT存在local/session storage里，会面临XSS攻击风险，一旦站点存在XSS漏洞，攻击者可以直接读取到JWT冒充用户身份。
  2. 授权码模式的安全校验缺失：你跳转第三方IdP登录URL的时候没有携带state参数，OAuth 2.0规范要求授权码流程必须携带不可预测的state参数来防范CSRF攻击，现在的流程会有CSRF风险，攻击者可以构造恶意授权回调，诱导用户触发后绑定攻击者的账号。
  3. JWT校验逻辑冗余：如果你的JWT用非对称加密签名（比如RS256），前端或者API网关可以直接验签，不需要每次都调用api.acme.com/authorize接口校验，只会增加不必要的接口开销；如果用对称加密签名的话，校验接口的设计是合理的，但要注意接口的限流防暴力破解。
  4. 第三方令牌的处理风险：你自研服务拿到第三方IdP的访问令牌后，要注意及时销毁，不要存在日志或者持久化存储里，避免泄漏后被滥用。

问题2：重定向携带JWT的实现方案 #

• 重定向响应的body确实会被浏览器忽略，但你可以把JWT放到重定向目标URL的查询参数或者hash片段里，前端可以直接读取：
  1. hash片段方案（更推荐）：你自研身份服务重定向的时候，把JWT放到URL的#后面，比如重定向到https://web.acme.com/callback#token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.xxx，hash片段不会传到服务端，只会留在浏览器本地，比查询参数更安全，避免JWT被服务器日志、CDN日志记录泄漏。前端React应用在/callback路由里直接读取window.location.hash解析出JWT，存到storage之后，删掉hash里的token字段再跳转到用户原本要访问的页面即可。
  2. 查询参数方案：如果用查询参数的话，比如https://web.acme.com/callback?token=xxx，要注意配置后端日志规则，过滤掉token参数避免泄漏，而且JWT要设置较短的有效期，降低泄漏后的风险。
• 额外注意：拿到JWT存完之后一定要做一次有效性校验，再给用户放行，避免被注入伪造的JWT。

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