OAuth 2.0 PKCE 生成器
PKCE(Proof Key for Code Exchange,RFC 7636)是推荐用于所有公开客户端 — SPA、移动应用、无法安全保存 client_secret 的桌面应用 — 的现代 OAuth 2.0 流程。本工具生成密码学随机的 `code_verifier`(unreserved URI 字符集 43-128 字符),派生 `code_challenge`(S256 使用 SHA-256 的 base64url 编码,plain 直接用 verifier),并构建包含 CSRF 防护 `state` 的完整 authorization URL。附带的 `curl` 示例展示令牌交换步骤,所有参数已就位 — 只需粘贴回调返回的 `code`。
使用方法
- 设置 verifier 长度(默认 64,最小 43,最大 128)。
- 选择 S256(始终推荐)或 plain(仅用于旧服务器)。
- 填写 `client_id`、`redirect_uri`、`scope` 和 OAuth 端点。
- 将用户引导至 authorization URL。回调返回 `?code=...` 后,运行 curl 用该 code 换取令牌。
常见问题
- S256 vs plain,该用哪个?
- 始终用 S256。plain 直接将 verifier 作为 challenge 发送,authorization 请求若被拦截就毫无保护。S256 只发送 verifier 的 SHA-256,verifier 本身在步骤 1 不出现,大大增加了拦截攻击难度。RFC 7636 规定支持 S256 时客户端应拒绝 plain。
- 为什么 verifier 用这些字符?
- RFC 7636 规定 verifier 字母表为 `[A-Z][a-z][0-9]-._~` — 来自 RFC 3986 的 URI 未保留字符。这使其在 URL、头部、表单体中均可安全使用,无需转义。
- `state` 是做什么的?
- 客户端按请求生成、在回调中验证的不透明随机字符串。防 CSRF:若攻击者诱使用户点击恶意 authorization 重定向,`state` 与应用记录的不匹配,响应会被拒绝。务必使用。
- 在哪里运行?
- 完全在浏览器中。Verifier 来自 `crypto.getRandomValues()`,SHA-256 来自 `crypto.subtle.digest()` — 都是 Web Crypto API。不会传输任何数据。
相关工具
HTTP Basic 认证编码器/解码器
把 `用户名:密码` 编码成 Base64 `Authorization: Basic` 头 —— 或粘贴一个现有头查看里面是谁。
CAA 记录构建器 (DNS 证书颁发机构授权)
生成 DNS CAA (Certificate Authority Authorization) 记录,让只有你信任的 CA 才能为你的域名签发 TLS 证书。生成 BIND 格式记录和控制面板用的 tag/value 分行格式,并附常见 CA (Let's Encrypt、DigiCert、Google、Amazon…) 一键添加。
mailto: 链接构建器
构建包含收件人、抄送、密送、主题和正文的 mailto: URL — 按 RFC 6068 进行百分号编码,可直接放入 <a> 标签。
URI 模板展开器 (RFC 6570)
用你自己的变量展开 RFC 6570 URI 模板 — 支持全部四个级别:路径、查询、片段、标签与路径风格运算符,含 explode 与前缀修饰符,全部在浏览器内完成。
HTTP 状态码参考
可搜索的全部 HTTP 状态码(1xx-5xx)参考 — 含概要、RFC、使用时机与常见陷阱。
二维码生成
用任意文本或网址生成自定义二维码并下载。
随机创作提示生成器
为绘画、写作、摄影、编程副项目或虚构世界构建生成新鲜的创作提示。点击重摇获得一批新提示,打破创作瓶颈。