OAuth PKCE 生成器
生成 RFC 7636 Verifier、S256 Challenge 和授权参数
可选：同时构建授权 URL
建议使用 S256：授权端点收到 challenge，Token 请求提交原始 verifier。plain 会直接暴露 verifier，仅在服务端明确要求时使用。
生成后显示 verifier、challenge 和可选授权 URL。
工具说明
使用浏览器加密 API 生成 43–128 字符的加密随机 code_verifier，以及 S256 或 plain code_challenge。S256 对 verifier 做 SHA-256 哈希并编码为无填充 Base64url，plain 则直接使用 verifier。可选端点与客户端字段用于构造待检查的授权 URL，不发送授权请求或交换 Token。结果不保存草稿，编辑字段会移除当前结果；实际 OAuth 客户端须保留自己的 verifier，直至授权码交换完成。
生产可用片段
RFC 7636 附录 B 的参考参数对
text
code_verifier:
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
code_challenge_method: S256
code_challenge:
E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
这是公开参考参数对。生成按钮会创建新的随机 verifier，界面不接受自定义 verifier。常见问题
S256 Challenge 是如何计算的？
计算 BASE64URL(SHA256(ASCII(code_verifier)))，末尾不带 = 填充。生成的 verifier 仅含字母、数字、连字符、点、下划线和波浪号，长度须为 43–128 的整数；随机字节先经拒绝采样，再映射到字符集。
何时应该选择 plain 而非 S256？
优先 S256。plain 将 code_challenge 直接设为 code_verifier，会在授权请求中暴露 verifier；仅在提供商明确要求并支持时使用，不能把它当作安全性等价的自动回退。
Verifier 和 Challenge 分别放在哪里？
授权请求携带 code_challenge 和 code_challenge_method，之后的 Token 请求将原始 code_verifier 与授权码一起提交。两次请求之间重新生成 verifier 会导致交换失败，实际客户端必须保留原值。
工具会发送授权请求或获取 Token 吗？
不会。它只构造参数与可选 URL。授权端点须为 HTTP(S)，不能包含用户名密码或片段；Client ID、Redirect URI、Scope、State 仍须符合提供商与应用配置，生成 URL 不代表这些值已经注册或会被接受。
授权端点原有查询参数如何处理？
无关查询参数会保留，response_type 设为 code，PKCE 字段会替换。client_id、redirect_uri、scope、state 使用对应输入值；字段留空会移除端点 URL 中已有的同名参数。State 不会自动随机生成。
结果会保存吗？编辑字段后会发生什么？
不保存草稿，生成过程中不上传 verifier。编辑或清空会使待完成的哈希失效，并移除旧结果，避免方法、Challenge 与 URL 悄悄来自不同输入。仅将参数复制到自己受控的测试客户端。
继续浏览