search

Found

info 概要

OAuth 2.0 PKCE (RFC 7636) の code_verifier と S256 code_challenge を生成。長さ 43〜128 文字対応、/authorize と /token の例つき。

📘 使い方

  1. スライダーで verifier の長さを 43〜128 文字の範囲で決める
  2. 再生成ボタンで code_verifier と S256 code_challenge を新しい組に切り替える
  3. リクエスト例を見て /authorize と /token への組み込み位置を確認する

PKCE code_verifier ジェネレーター

コピーしました!
コピーしました!

        

          
          
コピーしました!

        

      

    

  




            


            
            

            

            
            

                

                    grid_view 関連ツール
                

                
            


        


        
        
    


    
    
    

        
        

            

            Article
            

        


        
        

            
PKCE code_verifier ジェネレーター | OAuth 2.0 PKCE のテストペア発行


OAuth 2.0 の PKCE フロー (RFC 7636) で必要な code_verifier と S256 方式の code_challenge を、43〜128 文字の範囲でブラウザだけで生成します。/authorize と /token に挿し込むリクエスト例も同時に出力されるので、SPA・モバイル・CLI などの public client の動作確認に直接そのまま使えます。


💡 このツールについて


PKCE は public client (秘密鍵を持てない SPA / iOS / Android / CLI) が認可コード横取り (authorization code interception) を防ぐ仕組みで、Authorization Code フローに code_verifier と code_challenge を 1 組ずつ追加します。仕様 (RFC 7636) は verifier に [A-Z][a-z][0-9]-._~ の 43〜128 文字、challenge は verifier を SHA-256 にかけた値の base64url 表現と定義していますが、自前で crypto.getRandomValues を呼び出して 1 回 1 回ペアを作るのは検証時に煩雑です。


このツールはスライダーで長さを決めるたびに crypto API でランダムバイトを取り、base64url 化した文字列を verifier として保持、SHA-256 → base64url を通した challenge と一緒に表示します。出力欄の下にある「リクエスト例」には次のような形がそのまま並びます:


GET /authorize?response_type=code&client_id=...&code_challenge=...&code_challenge_method=S256&redirect_uri=...&state=...
POST /token (form): grant_type=authorization_code&code=...&code_verifier=...



自前実装が RFC のテキスト通りに組めているか・Postman や curl で叩く文字列が正しいかを並べて見比べられます。サーバーには一切送信されないので、社内 IdP のステージング検証や CTF・セキュリティ研修にも使えます。


🧐 よくある質問


Q. verifier の長さはいくつにすればよいですか?
A. RFC 7636 では 43〜128 文字なら何でも有効です。一般的なライブラリ (Auth0 SDK / MSAL.js / AppAuth 系) は 43〜64 文字を既定値にしていることが多いため、64 を試して動けばその長さで問題ありません。ログ容量が気になるときは 43、より広い乱数空間が欲しいときは 128 に倒すと良いでしょう。


Q. plain 方式 (code_challenge_method=plain) は使えないのですか?
A. 仕様上は許可されていますが、RFC 7636 §4.2 が S256 を「MUST support」、plain を「only if can't S256」と定義しており、現在ではほぼ全ての認可サーバーが S256 を前提にしています。本ツールも S256 だけを出力する設計です。


Q. ブラウザの SubtleCrypto が無い古い環境でも動きますか?
A. SubtleCrypto.digest('SHA-256') は IE 11 以前を除く全ての主要ブラウザで動作します。実装上 crypto.subtle が無い場合は計算ができないので、対象環境を Edge / Chrome / Firefox / Safari の現行版で確認してください。


Q. 生成した verifier / challenge は保存されますか?
A. 保存されません。ページを閉じたりリロードするたびに別ペアが生成されます。テストごとに使い捨てる前提なので、本番の code_verifier をこのツールで再利用しないでください。


Q. リクエスト例にある state パラメータは何を入れるべきですか?
A. state は CSRF 対策のためにクライアントが任意に生成するランダム文字列で、callback で同じ値が返ってきたか検証する用途です。本ツールは PKCE ペアの生成が目的なので例文では RANDOM_STATE のプレースホルダのまま表示しています。実装時はセッションごとに別の乱数を入れてください。


📚 豆知識


PKCE が初めて RFC として公開されたのは 2015 年 (RFC 7636) で、当時は「ネイティブアプリ向けの追加仕様」という位置付けでした。それが 2019 年の OAuth 2.1 ドラフトで「全 client が常時利用すべき」へと格上げされ、2024 年以降は SPA・サーバーサイド web app を含めた全フローで実質必須になっています。とくに Spotify Web API・Twitch API・X (旧 Twitter) API などは PKCE 必須化を機に Implicit Grant を廃止しました。code_challenge_method に S256 ではなく SHA-1 を選ばせる初期実装はほぼ全て撤去されており、現在の検証用ツールでは S256 を出すだけで十分です。