authenticated-session-acquisition

認証済みセッションの取得

金融系およびマルチテナントの対象では、ログインに SMS OTP／TOTP MFA が要求されるため、自律実行では対応できません。その結果、認証後の領域（実データ API に対する BOLA／IDOR／一括割り当て／インジェクション、セッション管理、API のピボット）がひそかに認証前の調査結果だけに縮小されます。このスキルの目的は限定的かつ具体的です。**正当な認証済みセッションを 1 つ取得し、再利用可能な成果物として実行担当に渡します。**認証の仕組み自体を攻撃するものではありません。その場合は authentication を参照してください。

成果物の仕様（セッションを実行担当に渡す方法）

エンゲージメントの OUTPUT_DIR に両方を出力し、名前で参照します（シークレットを直接記載しないでください。詳細は credential-loading.md を参照してください）。

• OUTPUT_DIR/<asset>/session/storageState.json — ブラウザーを使った認証後テスト用の Playwright ストレージ状態（Cookie + localStorage）。
• OUTPUT_DIR/<asset>/session/bearer.txt — 直接 API を再実行するための生のアクセス／ID トークン（expires_at も含む）。

実行担当は、環境変数から読み込むシークレットと同じようにこれらを使用します。スコープファイルの creds_env でレルムを指定し、セッションのパスはファイル参照として渡すため、トークンがプロンプト、experiments.md、attack-chain.md に書き込まれることはありません。トークンの有効期限が切れたら、このスキルを再実行してください（expires_at を記録し、リフレッシュトークンがある場合は再ログインではなく更新してください）。

モード（クライアントが提供できる情報に応じて選択）

モード	使用する状況	方法
シードからの TOTP	クライアントがテストアカウントの TOTP シークレット（Base32 シード）を共有した場合	tools/totp_now.py <BASE32_SEED> で現在のコードを決定論的に生成し、ログインフローで送信します。完全に自動化でき、繰り返し実行できます。
明示的な OTP	実行時にオペレーターがワンタイムコード（SMS／メール／認証アプリ）を確認できる場合	ログインを OTP の入力画面まで進め、オペレーターからコードを一度受け取って続行します。
ヒューマン・イン・ザ・ループでの再開	OTP が別経路で届き、実行を一時停止する必要がある場合	OTP 入力前のブラウザーコンテキストを保存して一時停止します。オペレーターがチャレンジを完了した後、再開して storageState を取得します。

プロバイダー別の手順

IdP ごとの詳細なフローは reference/session-acquisition.md に記載されています。対象は Auth0、Okta、Amazon Cognito（SRP 認証 + UNSIGNED 未認証ポスチャチェック）、Descope です。各手順では最後に、上記の仕様に沿って storageState.json + bearer.txt をエクスポートします。

セッションを取得できない場合 — 正直に保留し、捏造しない

テストアカウントや OTP シードがなく、OTP を中継できない場合、そのレルムの認証後の領域はテスターに落ち度がなく、テストできません。捏造した NA や、見落としたままにするのではなく、正直に記録してください。

1. reports/client-input-requests/CIR-NNN.md にクライアント入力リクエストを作成し、必要なものを具体的に記載します（「<realm> 用のテストアカウント／OTP シード／許可リストが必要」）。
2. attack-chain.md にレルム単位の BLOCKED_REASON を設定します。
3. coverage-matrix.md を参照し、そのレルムの認証後のカバレッジ項目を status:"deferred" に設定します。各項目には deferral_reason + client_input_request（CIR のパス）を含めます。これにより、決定論的ゲートは保留された領域をレポートで開示し、裏付けのある保留としてエンゲージメントを確定できるのは親オーケストレーター（coverage_gate.py --accept-deferrals を使用）のみとなります。スコープ全体が認証によってブロックされている場合、エンゲージメントを完了することはできません。

この処理を開始するのは、事前チェックの認証情報到達性プローブ（preflight-checklist.md、Phase-1 ゲート）です。認証情報が存在することと、使えることは同じではありません。認証後の実行担当を起動する前に、レルムごとに到達性を確認してください。

ワークフロー

1. スコープを確認します。creds_env に含まれるレルム／テナント、それらの背後にあるアセット、テストテナントの roe.reversible_writes を確認します。
2. IdP を特定します（ログインリダイレクト先のホスト／/.well-known/openid-configuration／SDK バンドル）→ 適切なレシピを選びます。
3. 適切なモードでセッションを取得します → storageState.json と bearer.txt に書き出します。
4. 確認します。最小限の認証済みリクエストで、認可された応答が返ることを確認します（401／403／ログインへのリダイレクトではないこと）。
5. アーティファクトのパスを認証後の実行バッチに渡します。失敗した場合は、上記の延期手順を実行します。

アンチパターン

• トークン、シード、Cookie をプロンプト、experiments.md、attack-chain.md、または tools/*.md に貼り付けないでください。アーティファクトファイルのパスのみを参照してください。
• ここで OTP／MFA チャレンジを総当たりしたり回避したりしないでください。これはセッション取得ではなく、authentication の検出事項です。
• MFA によってブロックされたセルを covered／NA としてマークしないでください。deferred とマークし、CIR を提出して、ゲートで開示されるようにしてください。
• 指定された認証済みテナントの範囲外でテストを行わず、roe.reversible_writes を遵守してください（作成後の削除は、自分のテストテナント内でのみ行ってください）。

参考資料

• reference/session-acquisition.md — IdP ごとの取得レシピ（Auth0／Okta／Cognito／Descope）と storageState／Bearer のエクスポート。
• tools/totp_now.py — 標準ライブラリを使った RFC-6238 TOTP 生成ツール（TOTP-from-seed モード）。