OAuth 调试器

用于代码交换的证明密钥（PKCE，RFC 7636）最初是为无法安全存储客户端密钥的移动应用和原生应用而设计的。其工作原理是：客户端生成一个随机的 code_verifier，并由此推导出一个 code_challenge（SHA-256 + base64url），然后在授权请求中发送该挑战值。在用授权码换取令牌时，客户端会发送原始的 code_verifier。授权服务器会验证其是否与此前的挑战值匹配——从而证明令牌请求来自发起该流程的同一客户端。

即使对于机密客户端（拥有客户端密钥的服务端应用），OAuth 2.1 现在也建议使用 PKCE，以防御授权码拦截攻击。

隐式授权流程（response_type=token）最初是为单页应用设计的一种捷径，直接在 URL 片段中返回访问令牌。这带来了严重问题：URL 中的令牌会出现在浏览器历史记录、服务器日志和 referrer 头中，并且该流程容易受到令牌注入攻击。OAuth 2.0 安全最佳实践（RFC 9700）和 OAuth 2.1 已明确移除隐式授权流程，转而推荐使用授权码 + PKCE 方案，单页应用可以在无需客户端密钥的情况下安全使用该方案。

• 要求使用 PKCE：适用于所有授权码流程，包括机密客户端。
• 移除隐式授权流程——改用授权码 + PKCE。
• 移除资源所有者密码凭据（ROPC）——password 授权类型已被弃用。
• 要求公开客户端进行刷新令牌轮换——每次使用后必须签发新的刷新令牌。
• 要求重定向 URI 精确匹配——不允许模式匹配或通配符。

1. 生成 PKCE 对：创建一个随机的 code_verifier，并计算 code_challenge = BASE64URL(SHA256(code_verifier))。
2. 重定向到授权端点：包含 response_type=code、client_id、redirect_uri、scope、state、code_challenge 和 code_challenge_method=S256。
3. 用户在授权服务器进行身份验证并授予同意。
4. 在您的 redirect_uri 处接收授权码，同时收到回传的 state——请验证 state 与您发送的值一致。
5. 用授权码换取令牌：向令牌端点发送 POST 请求，包含 grant_type=authorization_code、code、redirect_uri、client_id 和 code_verifier。
6. 接收访问令牌（以及可选的 id_token 和 refresh_token），并使用它们调用 API。