← 返回工具箱

OAUTH / RFC 7636 / LOCAL ONLY

PKCE 生成器

生成 code_verifier 与 S256 code_challenge，并把 client_id、回调地址、scope、state 和 nonce 组装为可检查的 OAuth 授权请求。

不要把 verifier 放进授权 URL：授权阶段只发送 challenge；拿到 code 后，客户端才把原始 verifier 交给 Token 端点。state 和 verifier 都应按一次授权请求生成并临时保存。

已载入 RFC 7636 的 S256 示例，可直接核对已知结果。

PROOF KEY

1. 生成或检查 Verifier

43 字符 · 格式有效

AUTHORIZATION REQUEST

2. 填写 OAuth 参数

Verifier 留在客户端

授权 URL 只包含 challenge。原始 verifier 需要与当前登录尝试绑定，并在回调换 Token 时原样发送。

state 不是装饰

回调收到的 state 必须与授权前保存的随机值一致；nonce 则用于 OIDC ID Token 的重放检查，两者职责不同。

回调地址必须精确

协议、主机、路径、端口和尾部斜杠都可能参与匹配。生成 URL 前先照授权服务器后台的登记值填写。

RELATED TOOLS

接着处理

查看全部工具 →
JWT 解码器检查 OAuth 或 OIDC 返回的 Token Header、Payload 与时间字段。JWT 时间检查核对 exp、nbf、iat、时钟偏差和有效期。URL 解析器拆解回调 URL、查询参数和编码结果。随机 ID 生成生成一次性测试 ID、令牌与 Base64URL 随机串。

USE & REVIEW

PKCE 生成器与 OAuth 请求构建常见问题

查看全部工具指南 →

code_verifier 和 code_challenge 分别在什么时候使用？

客户端先生成并临时保存随机 code_verifier，再把由它派生的 code_challenge 放进授权请求。用户完成登录并拿到 authorization code 后，客户端向 Token 端点提交原始 verifier；授权服务器重新计算并与最初的 challenge 比较。授权 URL 不应包含 verifier。

S256 和 plain 应该选择哪个？

新流程应选择 S256，它对 verifier 做 SHA-256 后再用无填充 Base64URL 编码，避免授权请求里直接暴露 verifier。plain 只用于授权服务器确实不支持 S256 的遗留兼容；如果服务端声明支持 S256，客户端不应静默降级。

为什么 verifier 必须是 43–128 个字符？

RFC 7636 规定 code_verifier 长度为 43–128 个字符，并限制为 A-Z、a-z、0-9、-、.、_、~。工具用浏览器安全随机源和拒绝采样生成这些字符，不使用 Math.random；手动输入超长、过短或包含空格都会被拒绝。

OAuth 的 state 和 OIDC 的 nonce 是一回事吗？

不是。state 用来把回调绑定到当前浏览器发起的授权尝试，并抵御登录 CSRF；nonce 通常写入 OIDC 请求并在 ID Token 中返回，用于绑定和防止 Token 重放。两者都应每次随机生成、按会话保存并在回调阶段精确核对。

使用 PKCE 后，前端应用还需要保存 client_secret 吗？

浏览器单页应用、桌面和移动端属于无法可靠保密的 public client，不应把 client_secret 打包进前端；PKCE 用于证明换 Token 的客户端与发起授权的是同一方。能安全保存凭据的后端 confidential client 仍应按授权服务器要求认证，PKCE 也不能替代 redirect_uri、state、issuer 等检查。

生成的 verifier、state、nonce 和 OAuth 参数会上传吗？

不会。随机数、SHA-256、Base64URL、URLSearchParams 和下载 JSON 都在当前浏览器完成。报告会包含 verifier，适合调试但仍属于临时凭证材料；不要发到日志、分析平台或公开工单，真实登录完成后也应及时清理。