01
登録したURIをそのまま入力
リダイレクトURIはポート、パス、末尾スラッシュ、既存クエリまで確認します。URI全体を事前にエンコードしないでください。追加パラメーターは生のkey=valueを一行ずつ入力し、値の中の&もそのまま指定できます。
OAuthの実装と検証
OAuth認可URLとコールバック解析
公開サンプルで要求と応答の対応を確認してから、自分の値に置き換えてください。
OAuth認可URL
要求の入力
生の値を入力してください。登録したリダイレクトURIはそのまま保持します。
結果
このタブ内で処理します。入力の送信や保存は行いません。
オプション
response_type=code・認可コードフロー
verifierはトークン要求用に保持します。URLにはチャレンジだけを入れ、レポートにはverifierを含めません。
追加項目は生のkey=valueを一行ずつ。事前エンコードと予約項目の再指定は不要です。
値を入力するかサンプルを読み込んでください。
リダイレクト先の末尾スラッシュや、state内のプラス記号が原因でログインが失敗することがあります。OAuth認可URLを完成形とデコード済みの表で見比べると、アプリが意図した値と実際のパラメーターの違いを追いやすくなります。
テストで受け取ったコールバックは、解析画面に貼り付けて調べられます。期待するstateは別に入力します。同じ名前を持つ行も残すため、先頭の値だけを採用するクライアントが見落とす問題を確認できます。
OAuth認可URLを確認する理由
verifierを送信先のURLに含めない
OAuth認可URLの作成では入力したverifierからS256チャレンジを導出します。要求に入るのはチャレンジと方式だけです。verifierは入力欄に残り、後のトークン要求用に個別コピーできます。レポートにもverifierを含めません。
同じstateを一行にまとめない
クエリとフラグメントの両方にstateがある場合も、出現順と取得元を保って表示します。同じ値が二つあっても曖昧と判定し、たまたま一致する一行によって重複を隠しません。
要求と応答を取り違えないために
02
乱数を更新する時点を決める
生成ボタンはstateとverifierにそれぞれ32ランダムバイトを使います。scopeにopenidがある場合だけnonceも更新します。変更数と候補を確認して適用し、同じトランザクションのverifierを保持してください。
03
自動更新と手動実行を使い分ける
自動時は編集が止まってから350ミリ秒後に処理します。オフなら実行ボタンとCtrl/Cmd+Enterが使えます。古い結果はコピーも保存もできません。画面を切り替えても入力は残りますが、期待するstateは独立した欄です。
エンコードと状態を見える形に
二重エンコードを切り分ける
認可URL生成では内側のコールバック全体を一つの値として扱います。既存の端点クエリは厳密にデコードしてから再構築します。追加値の+は%2Bとなり、フォーム形式のクエリでは空白を+で表します。
入力と同じバイトからS256を計算
verifierは43〜128文字の許可文字列を受け付けます。前後の空白除去やBase64の事前デコードはしません。PKCEをオフにすると要求のチャレンジを外しますが、入力したverifierは保持します。
クエリとフラグメントの取得元を表示
完全なURL、?query、#fragment、クエリ文字列だけの入力に対応します。%252Fは%2Fまで、%2Bは+までの一回のデコードです。空の値、空の名前、重複行をオブジェクトにまとめて失うことはありません。
比較していない状態も明記
stateパラメーターがない、空、複数、期待値未指定、一致、不一致を区別します。codeとerrorの混在も確認できます。表は最初の50行から表示し、エクスポートには全パラメーターが入ります。
対応範囲と入力の制限
- 認可コードフローに限定
- response_typeはcode固定です。implicit、hybrid、plain PKCEは扱いません。このフォームではnonceの指定にopenid scopeが必要です。nonceの検証はIDトークンを検証するアプリ側で行います。
- URIの検査は登録確認ではない
- 認可端点はHTTPSを使います。ローカルのlocalhost、127.0.0.1、[::1]のみHTTPも許可します。リダイレクト先はcom.example.app:/cbのような逆ドメイン形式の私有スキームにも対応。認証情報、フラグメント、生の空白、不正なエスケープは拒否します。
- 予約項目を上書きしない
- 端点クエリと追加行の重複名や、フォームが管理する項目の再指定はエラーです。秘密鍵、verifier、トークン、requestオブジェクト、response_modeも追加できません。提供者プリセット、Discovery、JAR/PAR、form_post受信は対象外です。
- ログインやトークン検証は行わない
- URLを開いたり、実際のコールバックを受けたり、コードをトークンへ交換したりしません。通常のアンカーやハッシュルーターも対象外です。state一致だけでは発行者、署名、セッションとの対応、時刻や認可の正当性は証明できません。
- 入力と保持期間の上限
- 構築用入力の合計は32,768文字まで。コールバックと期待するstateもそれぞれ同じ上限で、結果は100パラメーターまでです。履歴や下書きは保存しません。サンプル、乱数更新、消去はプレビュー後に適用し、一度取り消すと入力と結果が戻ります。
OAuth認可URLのよくある質問
リダイレクトURIを完全一致させるのはなぜですか？
スキーム、ポート、パス、末尾スラッシュの差が別の受信先を指すことがあるためです。提供者に実際のURIを登録してください。本ツールは入力文字列をパラメーターとして保ちますが、登録内容にはアクセスできません。
stateとnonceの役割はどう違いますか？
stateはコールバックのパラメーターとして戻り、保存したトランザクション値と比較します。nonceはIDトークンに結び付けられ、トークンの検証後に確認します。コールバック欄のnonceを見つけても、その検証の代わりにはなりません。
クライアントシークレットがあってもPKCEは必要ですか？
シークレットはトークン端点でのクライアント認証に使います。PKCEは認可コードを元のverifierに結び付ける追加の役割を持ち、現在の推奨事項は機密クライアントにも利用を勧めています。提供者のS256対応も確認してください。
クライアントIDをURLに載せてもよいですか？
はい、公開の識別子です。client_secretやcode_verifierとは用途が違います。この二つの名前は認可クエリに追加できず、verifierは専用ボタンでコピーします。
OAuthとOpenID Connectはどう違いますか？
OAuthはリソースへのアクセスを認可します。OpenID Connectはユーザー認証とIDトークンを追加します。要求を準備するときはopenid scopeを含め、提供者の条件に応じてnonceを指定します。返されたIDトークンの検証はアプリの責任です。
計算や入力判定に問題がありましたか？