competition-oauth-oidc-chain

競技会 OAuth OIDC チェーン

このスキルは、$ctf-sandbox-orchestrator がすでに有効化され、サンドボックスの前提、ノードの所有権、および証拠の優先順位が確立された後の、下流の専門特化としてのみ使用してください。まだそれが行われていない場合は、まず $ctf-sandbox-orchestrator に戻ってください。

このスキルは、OAuth または OIDC フローがどのように形成され、交換され、最終的に受け入れられるかを証明することが難しい部分である場合に使用します。

ユーザーが明示的に英語を要求しない限り、簡体字中国語で回答してください。

クイックスタート

1. 認証チェーンを順番にマッピングします。エントリールート、リダイレクト、認可リクエスト、コールバック、トークン交換、リフレッシュ、および最終的な受け入れサービスです。
2. 何かを変更する前に、スコープ、state、nonce、PKCE マテリアル、リダイレクト URI、およびクレームを含むトークンを記録します。
3. トークンの所持と、実際のアイデンティティの受け入れを分離します。
4. ブラウザから見えるリダイレクトとバックエンドから見えるトークン交換を、1 つのコンパクトなチェーンにまとめます。
5. 決定的なアイデンティティのエッジを証明する、最小のリダイレクトから受け入れまでのフローを再現します。

ワークフロー

1. リダイレクトとトークンの経路をマッピングする

• issuer、クライアント ID、リダイレクト URI、認可パラメータ、コールバックパラメータ、トークンエンドポイント、およびリフレッシュ経路を記録します。
• どの値がユーザー制御、派生、キャッシュ、または検証済みであるかに注意します: state、nonce、PKCE ベリファイア、audience、scope、または prompt。
• ブラウザのリダイレクト、サーバー側の交換、および結果として生じるセッション状態を結び付けておきます。

2. トークンからアイデンティティへの受け入れを証明する

• コード、ID トークン、アクセストークン、またはリフレッシュトークンが、どのようにアプリのセッション、クレームのマッピング、テナントの選択、または受け入れられた権限になるかを示します。
• トークンのクレーム、有効期限、audience、subject、スコープ、および正確な受け入れアプリまたはバックエンドのエッジを記録します。
• UI のログイン成功とバックエンドの認可成功を区別します。

3. 決定的な OAuth チェーンまで絞り込む

• 結果を最小のシーケンスに圧縮します: エントリリクエスト -> リダイレクト -> コールバック -> トークンまたはクレームの受け入れ -> 結果として生じるケイパビリティ。
• パラメータの変更が重要である場合は、1 つの正規の正常フローと 1 つの最小の変更フローを保持します。
• タスクが認証チェーンの外にある一般的な Web ルーティングやストレージの動作へと広がった場合は、より広範な Web ランタイムスキルに切り替えてください。

このリファレンスを読む

• リダイレクトチェックリスト、トークンチェックリスト、および証拠のパッケージ化については、references/oauth-oidc-chain.md をロードしてください。
• 難しい部分が、発行後の JWT ヘッダーの解析、クレームの正規化、キーの検索、またはトークン検証の混同である場合は、$competition-jwt-claim-confusion を優先してください。

保持すべきもの

• リダイレクト URI、パラメータ、コード、トークンのクレーム、スコープ、および受け入れサービスまたはコールバック
• クレームまたはトークンが受け入れられたアプリアイデンティティになる正確なポイント
• 1 つの最小限の再現可能なリダイレクトから受け入れまでのシーケンス