OAuth 2.0 PKCE ジェネレーター
ネットワーク
PKCE(Proof Key for Code Exchange、RFC 7636)は client_secret を安全に保管できないすべてのパブリッククライアント(SPA、モバイル、デスクトップアプリ)に推奨される現代の 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 実行でトークン取得。
よくある質問
- S256 vs plain、どっちを使う?
- 常に S256。plain は verifier をそのまま challenge として送るので、authorization リクエストが傍受されると保護効果がありません。S256 は SHA-256 結果のみ送り、verifier 自体はステップ1で露出しないため傍受攻撃が遥かに困難に。RFC 7636 も S256 利用可能なら plain を拒否すべきと規定。
- Verifier の文字集合がなぜこれ?
- RFC 7636 が verifier アルファベットを `[A-Z][a-z][0-9]-._~`(RFC 3986 の unreserved URI 文字)と規定。これにより URL・ヘッダ・フォームボディどこでもエスケープなしで安全に使えます。
- `state` とは?
- クライアントがリクエスト毎に生成しコールバックで検証する不透明な乱数文字列。CSRF 防御 — 攻撃者がユーザーを悪意ある authorization リダイレクトに誘導しても、アプリが記憶する `state` と一致せず応答を拒否できます。必ず使用を。
- どこで実行される?
- 完全にブラウザ内。Verifier は `crypto.getRandomValues()`、SHA-256 は `crypto.subtle.digest()` — どちらも Web Crypto API。外部送信なし。
関連ツール
IP アドレス インスペクター
IPv4 または IPv6 アドレスを入力すると、クラス、スコープ（プライベート / パブリック / ループバック / リンクローカル）、10 進数値、2 進数、逆引き DNS 表記、/32 CIDR を表示。
ポート番号リファレンス
約 60 個の標準 TCP / UDP ポート番号の検索可能なチートシート — 22 (SSH)、80 (HTTP) から 6379 (Redis)、27017 (MongoDB) まで。
DNS レコードリファレンス
DNS レコードタイプの検索可能なチートシート — A・AAAA・CNAME・MX・TXT・NS・SOA・PTR・SRV・CAA・DNSSEC・SVCB / HTTPS — 例付き。
サブネット計算機（IPv4 / CIDR）
IPv4 CIDR をネットワークアドレス・ブロードキャスト・ネットマスク・ワイルドカード・ホスト範囲・クラスにパース。バイナリ内訳とプライベート/パブリック判定。
User Agent パーサー
User-Agent 文字列をブラウザ・エンジン・OS・デバイス・CPU に解析。GPTBot・ClaudeBot・PerplexityBot を含む 20 以上のボットを検出。
HTTP ステータスコード リファレンス
1xx-5xx の全 HTTP ステータスコードを検索 — 概要・RFC・使い時・よくある落とし穴付き。