ZeroTool Workbench

PKCE ジェネレーター

OAuth 2.0 / 2.1 認可コードフロー向けの PKCE code_verifier と code_challenge を暗号学的に安全に生成。SHA-256（S256）と plain 方式に対応、100% ブラウザ完結。

100% クライアントサイド データはブラウザ外に出ません 無料 · 登録不要
0 43–128 chars · [A-Z a-z 0-9 -._~]

Challenge Method

Code Challenge
—
Authorization URL preview paste & tweak for your provider
—
Token exchange (cURL) send verifier on /token 
—

All randomness, hashing and URL preview happens in your browser. Nothing is uploaded.

関連ツール

JWT デコーダー JWTのヘッダー・ペイロード・署名を解析・表示。有効期限ハイライト付き。 JWT ジェネレーター / 署名ツール ブラウザ内でJWTトークンを生成・署名（HS256/HS384/HS512）。ヘッダー・ペイロードJSONを編集し、秘密鍵を設定してトークンをコピー。完全クライアントサイド。 ハッシュジェネレーター テキストからMD5・SHA-1・SHA-256・SHA-384・SHA-512ハッシュを生成。 Basic Auth Header ジェネレーター HTTP Basic Authentication ヘッダーをブラウザで生成・デコード。Authorization header、token、cURL、Fetch 例をアップロードなしでコピー。 パスワードジェネレーター 暗号学的に安全なパスワードを生成。長さと文字セットをカスタマイズ可能。エントロピー計測付き。 RSA 鍵ペアジェネレーター RSA鍵ペア（2048/4096ビット）をPEM/JWK形式でブラウザ内生成。鍵はブラウザ外に出ません。

使い方

  1. ページ読み込み時に 64 文字の code_verifier が自動生成される。
  2. 再生成 ボタンで新しいランダム verifier を取得、または独自の値を貼り付け。
  3. Challenge メソッド を選択 — 明確な理由がない限り S256 のまま。
  4. code_challenge はリアルタイムで更新。/authorize リクエストにコピー。
  5. 認可 URL プレビュー を展開してエンドポイント・client_id・redirect_uri を入力。
  6. トークン交換（cURL） を展開すれば、/token への即実行可能なコマンドが手に入る。

主な用途

  • ローカル OAuth デバッグ：verifier/challenge ペアを生成し、認可 URL をブラウザに貼って code を取得、curl プレビューで /token 交換を再現。
  • モバイル・デスクトップクライアント：バックエンドを立てずに iOS / Android / デスクトップアプリのテストフローを手動で実行。
  • 新規プロバイダー対応：コードを書く前にプロバイダーが S256 を受け入れること、client_id 設定が正しいことを検証。
  • セキュリティレビュー：仕様書を開かずにライブツールで verifier の文字セットと長さが RFC 7636 に準拠しているか確認。

仕組み

  1. crypto.getRandomValues で 32 バイトの乱数を取得し、base64url エンコード後に目的の長さに切り詰める。
  2. S256 では、verifier を UTF-8 エンコードしてから crypto.subtle.digest(‘SHA-256’, …) でハッシュ計算。
  3. 32 バイトのハッシュを base64url エンコード（+ を -、/ を _、= パディングを除去）して 43 文字の challenge を生成。
  4. plain モードでは challenge は verifier と同一。互換性のためだけに残されている。

FAQ

PKCE とは何か、なぜ必要なのか？

PKCE は Proof Key for Code Exchange（RFC 7636）の略で、OAuth フロー中に認可コードが横取りされるのを防ぐ仕組み。client_secret を安全に保管できないパブリッククライアント（モバイルアプリ、SPA、CLI、デスクトップアプリ）で特に重要。OAuth 2.1 では公共クライアントだけでなくすべてのクライアントに必須。

S256 と plain、どちらを選ぶ？

本番では常に S256。plain は SHA-256 を計算できない歴史的クライアント向けに残されたメソッドで、現代では実質的に不要。RFC 7636 も S256 を明確に推奨し、主要な OAuth プロバイダーは plain をデフォルトで拒否する。

このツールは verifier を外部に送信する？

送信しない。乱数は crypto.getRandomValues、ハッシュは crypto.subtle.digest、URL プレビューは単純な文字列連結で、すべてブラウザ内で完結。verifier は localStorage にも保存されず、リロードのたびに新規生成される。

verifier の長さは？

RFC 7636 で 43〜128 文字、文字セットは [A-Z a-z 0-9 - . _ ~]。デフォルトの 64 文字はブルートフォース耐性と URL 長のバランス点。プロバイダーが 128 文字を受け入れる場合は最大化してもよい。

自分の OAuth フローにどう組み込む？

クライアント側で code_verifier を安全に保管（ブラウザは localStorage、ネイティブは安全ストレージ）。/authorize リダイレクト時に code_challenge と code_challenge_method=S256 をクエリパラメータで送信し、/token で認可コードと交換する際に元の code_verifier を返却すれば、サーバーが再ハッシュして照合する。