无状态后端如何使用OAuth Authorization Code Flow with PKCE？

针对无状态后端无法存储code verifier的问题，有几种安全合规的解决思路，完全不需要硬编码code verifier：

1. 将code verifier加密后嵌入state参数 #

state参数原本用于防范CSRF攻击，我们可以复用它来安全传递code verifier：

• 生成随机的code verifier，再据此生成code challenge
• 用后端持有的对称加密密钥（比如AES-256-GCM）加密code verifier
• 把加密后的code verifier与随机生成的CSRF串拼接（或合并成一个加密块），作为state参数随授权请求发送给OAuth提供商
• 回调时，从请求中取出state，解密得到原始code verifier
• 携带code verifier和授权码向OAuth提供商请求令牌

注意：加密密钥必须由后端严格保管，防止code verifier被窃取或篡改。

2. 用加密的HTTP-only Cookie存储code verifier #

利用客户端Cookie存储加密后的code verifier，后端无需在服务器端保存任何数据：

• 生成code verifier和code challenge
• 用后端密钥加密code verifier，设置成HTTP-only、Secure、SameSite=Strict的Cookie（避免XSS和CSRF风险）
• 发起授权请求时携带code challenge等参数
• 回调时，从Cookie中取出加密的code verifier，解密后用于令牌请求
• 令牌请求完成后，可立即删除该Cookie，减少暴露风险

注意：Cookie的有效期要设置得足够短（比如15分钟，匹配授权码的有效期），避免长期留存敏感数据。

3. 用JWT封装code verifier作为state #

通过JWT的签名机制保证code verifier的完整性和真实性：

• 生成code verifier和code challenge
• 创建JWT，将code verifier放入payload，用后端的密钥（对称或非对称）对JWT进行签名
• 将JWT作为state参数发起授权请求
• 回调时，验证JWT的签名有效性，解码payload得到code verifier
• 使用code verifier请求令牌

注意：JWT的有效期要与授权码的有效期匹配，避免过期后无法使用；同时要确保签名密钥不泄露，防止JWT被篡改。

为什么不能硬编码code verifier？ #

硬编码固定的code verifier完全违背了PKCE的设计初衷——PKCE通过随机生成的code verifier，防止攻击者拦截授权码后直接请求令牌。如果code verifier固定，攻击者拿到授权码就能用相同的verifier获取令牌，PKCE的安全防护等于失效。

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