PKCE增强授权码流程中code_verifier安全保护最佳实践咨询

存储位置选择优先级 #

优先按以下顺序选择code_verifier的存储方案，安全优先级从高到低：

• 内存变量存储：如果你的应用在跳转回回调路由时不会触发页面全量刷新（绝大多数SPA应用都满足），直接将生成的code_verifier存在全局变量、闭包或前端框架的状态管理里即可，完全不落地到持久化存储，风险最低。
• sessionStorage：如果应用是多页应用、或者跳转后会触发页面刷新，再选择sessionStorage存储。它天然是单标签页隔离的，关闭标签后会自动清除，不会跨会话留存，是落地存储的最优选择。
• 禁止使用localStorage、普通Cookie存储：localStorage持久化存在、跨标签页共享，泄露风险更高；Cookie会被自动附带在各类请求中，存在CSRF风险，完全不适用于存储code_verifier。

sessionStorage存储的XSS风险说明 #

这种风险是真实存在的：如果应用存在XSS漏洞，或者用户安装了拥有当前站点读写权限的恶意扩展，确实可以同时读取到sessionStorage中的code_verifier和回调URL中的code，二者结合即可兑换Access Token。

落地风险防范措施 #

可以按以下方案逐层加固，降低泄露风险：

1. 前置加固XSS防护：所有用户输入、URL参数、接口返回的富文本内容都做严格转义，开启站点CSP策略限制未授权脚本执行，从根源上减少XSS漏洞出现的可能。
2. 缩短敏感信息有效期：code_verifier的有效时长控制在5-10分钟即可，同时要求授权服务器对回调返回的code做严格的有效期限制，通常code有效期不超过1分钟，就算数据泄露，过期后也无法使用。
3. 绑定state校验逻辑：发起授权请求时同步生成随机state参数，和code_verifier存在同一存储位置，回调后首先校验返回的state和存储的是否匹配，不匹配直接终止流程，攻击者就算拿到code也无法完成后续兑换。
4. 及时清理敏感信息：在拿到Access Token、或者授权流程失败/中断后，立刻删除存储中的code_verifier和state，不要长期留存。主流的OIDC SDK（包括你提到的okta-oidc-js）已经默认做了这个处理，不需要额外修改。
5. 高安全场景用后端中转：如果业务安全要求极高，可以将code_verifier存在后端session中，前端拿到回调code后传给后端，由后端完成Token兑换，前端全程接触不到code_verifier，从根本上避免前端泄露风险，只是会增加后端开发量。

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