OAuth PKCE 生成器
生成 RFC 7636 Verifier、S256 Challenge 和授权参数
安全与认证
🔒 100% 本地运行 — 你的数据不会离开当前页面由 ToolsKit 编辑团队维护•最近更新：2026年8月23日•最近复核：2026年8月23日
OAuth 2.0 PKCE
可选：同时构建授权 URL
Verifier 等同临时凭据：只发送 challenge 到授权端点，并在 Token 请求中提交原始 verifier。
生成结果
生成后显示 verifier、challenge 和可选授权 URL。
工具说明
OAuth PKCE 生成器会创建符合 RFC 7636 长度要求的加密随机 code_verifier，并派生推荐的 S256 code_challenge 或兼容用 plain 值。还可以填写授权端点、Client ID、Redirect URI、Scope 和 State，构建便于检查的完整授权 URL。随机数和 SHA-256 都使用浏览器加密 API，本地生成的 verifier 必须由客户端保留到授权码交换阶段。
场景配方
01
准备公共客户端授权请求
目标：生成新的 Verifier 对并检查完整授权 URL
- 保持 S256，并为本次授权生成新的 Verifier。
- 填写端点、Client ID、Redirect URI、Scope 和独立 State。
- 发起授权 URL，同时在客户端保留 Verifier 供 Token 交换。
结果：得到符合规范的 PKCE 授权请求和本地 Verifier。
常见问题
Verifier 应该使用多长？
RFC 7636 允许 43 到 128 个字符，64 个字符是实用且安全的默认值。
应该选择 S256 还是 plain？
授权服务器支持时应使用 S256；plain 会在授权请求中暴露等同 verifier 的值。
S256 Challenge 如何计算？
先对 ASCII code_verifier 计算 SHA-256，再做无填充 Base64url 编码。
Verifier 应发送到哪里？
授权阶段由客户端保存，只在使用授权码请求 Token 端点时提交。
PKCE 可以替代 OAuth State 吗？
不可以。PKCE 防止授权码截获，State 用于绑定响应并降低请求伪造风险。
生成的 PKCE 值会保存吗？
不会，所有值都在本地生成，重置或丢弃页面状态后即清除。
继续浏览