关于首次请求后PKCE代码质询重新生成的疑问

1. 仅靠access token和auth code无法重新生成code challenge #

PKCE的code_challenge是由客户端本地随机生成的code_verifier通过SHA256哈希（或plain模式）生成的，服务器端不会存储code_verifier，也不会在auth code或access token中嵌入任何与code_verifier/code_challenge相关的信息。

auth code的作用只是一次性换取access token，而access token是用于后续API请求的身份凭证，两者都不包含生成code_challenge所需的原始code_verifier。所以仅靠这两个值，根本反向不出code_challenge，更别说重新生成合法的质询对。

2. 同一登录会话的后续请求不需要重新生成code challenge #

你可能混淆了“同一登录会话”的流程：

• 首次授权后，客户端已经拿到了access token（和refresh token），后续的API请求直接用access token做身份验证即可，不需要再走授权码流程，自然不需要生成新的code_challenge。
• 如果access token过期，你应该用refresh token去请求新的access token，这个刷新流程通常不需要PKCE（部分服务商可能要求，但核心是用refresh token而非重新发起授权）。只有当你需要重新发起完整的授权流程（比如用户重新登录、权限变更）时，才需要重新生成新的code_verifier和code_challenge。

3. 关于恶意用户利用泄露token/code的防御 #

首先要明确几个边界：

• auth code是一次性的：授权服务器在你用auth code换取access token后，会立即作废该auth code，所以即使泄露，恶意用户也无法重复使用它来获取token。
• PKCE的作用是防止授权码拦截攻击：也就是在授权码从授权服务器返回客户端的过程中，防止第三方拦截auth code后冒充客户端去换token——因为攻击者没有客户端本地的code_verifier，无法通过服务器的code_challenge验证。但PKCE不负责保护已经泄露的access token。
• access token泄露的防御：如果access token泄露，恶意用户确实可以直接用它调用API，但这属于token泄露的安全问题，需要通过这些手段防御：
  • 给access token设置较短的有效期，配合refresh token使用
  • 强制所有请求使用HTTPS传输，防止token在网络中被拦截
  • 部分服务商支持token绑定机制（比如绑定客户端IP、User-Agent），限制token的使用场景
  • 妥善存储refresh token，比如用HttpOnly、Secure的Cookie存储，防止前端XSS窃取

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