jpskill.com
📦 その他 コミュニティ

auth-flow-operator

ログインや登録、セッション管理、役割に応じたアクセス検証を通じて、認証されたテストアクセスを確立・検証するSkill。

📜 元の英語説明(参考)

Establish and validate authenticated test access through login, registration, session lifecycle, and role context checks.

🇯🇵 日本人クリエイター向け解説

一言でいうと

ログインや登録、セッション管理、役割に応じたアクセス検証を通じて、認証されたテストアクセスを確立・検証するSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-17
取得日時
2026-05-17
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

[Skill 名] auth-flow-operator

Auth Flow Operator

目的

ダウンストリームのセキュリティテストのために、信頼性の高い認証済みコンテキストを安全に取得することです。

入力

  • target_url
  • known_credentials (任意)
  • auth_notes (MFA、メール認証、SSO、CAPTCHA)
  • allowed_test_accounts ポリシー

ワークフロー

フェーズ 1: ルート発見

  1. ログイン、登録、パスワードリセット、トークン更新、ログアウトのパスを特定します。
  2. 認証モード(ローカル認証情報、SSO、OTP、マジックリンク、APIトークン)を決定します。

フェーズ 2: ログインパス

  1. 定義された順序で既知の認証情報を試行します。
  2. UIの推測ではなく、認証済みのみのアクションを通じて成功を検証します。
  3. セッションアーティファクトと有効期限の動作を記録します。

フェーズ 3: 登録パス

  1. 許可されている場合、専用のテストアカウントを作成します。
  2. 検証の依存関係を捕捉します。
  3. ロール割り当てとデフォルトの権限を検証します。

フェーズ 4: セッションライフサイクル

  1. ログアウトによる無効化をテストします。
  2. 権限変更後のトークン/クッキーのローテーションをテストします。
  3. 同時セッションの動作をテストします。

フェーズ 5: アクセス検証

  1. 保護されたルートのゲートを検証します。
  2. ロールに依存する機能の違いを検証します。
  3. アカウント間の分離を検証します。

アンチパターン

  • UIのテキストのみからログイン状態を仮定すること。
  • 古いトークンを検証せずに再利用すること。
  • 1つの証拠ストリームでアカウントのIDを混在させること。

出力契約

{
  "working_auth_paths": [],
  "accounts": [],
  "session_lifecycle": [],
  "role_validation": [],
  "blockers": []
}

制約

  • ブルートフォース攻撃は行いません。
  • アカウント作成およびクリーンアップのルールを尊重します。
  • ログ内のPIIおよび認証情報を最小限に抑えます。

品質チェックリスト

  • [ ] 少なくとも1つの安定した認証パスが確立されていること。
  • [ ] セッションの動作が推測ではなくテストされていること。
  • [ ] ロールの境界がアクションレベルのチェックで検証されていること。

詳細なオペレーターノート

セッション検証テスト

  • ログイン後およびトークン更新後に認証済みアクセスを確認します。
  • ログアウトが以前のセッショントークン/クッキーを無効にすることを確認します。
  • パスワードリセットが期待通りに古いセッションを無効にすることを確認します。

ロール検証テスト

  • ロール固有のUIおよびAPIの動作が期待通りに異なることを確認します。
  • 権限昇格にサーバーサイドの強制が必要であることを確認します。
  • トークン内のロールクレームがバックエンドのチェックと一致することを確認します。

一般的な失敗パターン

  • UIは変更されるがAPIは認証されないままの部分的なログイン成功。
  • 古いクッキーと新しいトークンによる混在したID状態。
  • 意図したよりも広い権限を付与する登録のデフォルト設定。

レポートルール

  • アカウントごとに1つのIDタイムラインを保持します。
  • アカウントの出所(providedまたはcreated)と意図されたロールを記録します。
  • 認証設定が失敗した場合、正確なブロック原因を記録します。

クイックシナリオ

シナリオ A: 認可のドリフト

  • 所有リソースでベースラインを設定します。
  • 外部リソース識別子でリプレイします。
  • ロール変更と新しいセッションで繰り返します。
  • 読み取り/書き込み/削除の違いを確認します。

シナリオ B: 入力処理の弱点

  • 構文的に有効な制御ペイロードを送信します。
  • 意味的に悪意のあるバリアントを送信します。
  • パーサーまたは実行の副作用を検証します。
  • コンテンツタイプを変更して再テストします。

シナリオ C: ワークフローのバイパス

  • 期待される状態シーケンスを実行します。
  • 順序外の遷移を試行します。
  • 繰り返しのアクションリプレイを試行します。
  • サーバーサイドの状態強制を確認します。

条件付き決定マトリックス

条件 アクション 証拠要件
認証情報がUIでは成功するがAPIでは失敗する トークンのオーディエンス/セッションバインディングを検証する エンドポイントレベルの認証証明
登録にメール認証が必要な場合 認証状態の遷移を捕捉する 状態を含むアカウントタイムライン
一部のフローでMFAが任意の場合 MFAの有無による保護されたアクションへのアクセスを比較する ロール/アクションの差異
ログアウトが成功したように見えるがトークンが機能する場合 ログアウト/リセット後のトークン再利用をテストする ログアウト後のリプレイ証明
ロールがUIにのみ表示される場合 特権アクションでバックエンドの認可を検証する サーバーサイドの拒否/許可トレース

高度なカバレッジ拡張

  1. ログイン前後の状態におけるセッション固定をテストします。
  2. パスワード変更後の並行セッション失効動作をテストします。
  3. 権限変更後のロールダウングレードの永続性をテストします。
  4. 不正なアカウントリンクに対するアカウント回復パスをテストします。
  5. ローカル認証バイパスのためのSSOフォールバックパスをテストします。
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Auth Flow Operator

Purpose

Securely obtain reliable authenticated context for downstream security testing.

Inputs

  • target_url
  • known_credentials (optional)
  • auth_notes (MFA, email verification, SSO, CAPTCHA)
  • allowed_test_accounts policy

Workflow

Phase 1: Route Discovery

  1. Identify login, registration, password reset, token refresh, logout paths.
  2. Determine auth mode: local creds, SSO, OTP, magic link, API token.

Phase 2: Login Path

  1. Attempt known credentials in defined order.
  2. Validate success via authenticated-only action, not UI guess.
  3. Record session artifacts and expiry behavior.

Phase 3: Registration Path

  1. Create dedicated test accounts when permitted.
  2. Capture verification dependencies.
  3. Validate role assignment and default permissions.

Phase 4: Session Lifecycle

  1. Test logout invalidation.
  2. Test token/cookie rotation after privilege change.
  3. Test concurrent session behavior.

Phase 5: Access Validation

  1. Confirm protected route gating.
  2. Confirm role-sensitive feature differences.
  3. Confirm cross-account isolation.

Anti-Patterns

  • Assuming logged-in state from UI text only.
  • Reusing stale tokens without validation.
  • Mixing account identities in one evidence stream.

Output Contract

{
  "working_auth_paths": [],
  "accounts": [],
  "session_lifecycle": [],
  "role_validation": [],
  "blockers": []
}

Constraints

  • No brute force.
  • Respect account-creation and cleanup rules.
  • Keep PII and credentials minimized in logs.

Quality Checklist

  • [ ] At least one stable auth path established.
  • [ ] Session behavior tested, not inferred.
  • [ ] Role boundaries verified with action-level checks.

Detailed Operator Notes

Session Validation Tests

  • Confirm authenticated access after login and after token refresh.
  • Confirm logout invalidates prior session tokens/cookies.
  • Confirm password reset invalidates old sessions when expected.

Role Validation Tests

  • Confirm role-specific UI and API behavior differ as expected.
  • Confirm privilege elevation requires server-side enforcement.
  • Confirm role claims in token align with backend checks.

Common Failure Patterns

  • Partial login success where UI changes but API remains unauthenticated.
  • Mixed identity state from stale cookies and new tokens.
  • Registration defaults granting broader permissions than intended.

Reporting Rules

  • Keep one identity timeline per account.
  • Record account origin (provided or created) and intended role.
  • Record exact blocker cause when auth setup fails.

Quick Scenarios

Scenario A: Authorization Drift

  • Baseline with owned resource.
  • Replay with foreign resource identifier.
  • Repeat with role shift and fresh session.
  • Confirm read/write/delete differences.

Scenario B: Input Handling Weakness

  • Send syntactically valid control payload.
  • Send semantically malicious variant.
  • Verify parser or execution side effect.
  • Re-test with content-type variation.

Scenario C: Workflow Bypass

  • Execute expected state sequence.
  • Attempt out-of-order transition.
  • Attempt repeated action replay.
  • Confirm server-side state enforcement.

Conditional Decision Matrix

Condition Action Evidence Requirement
Credentials succeed in UI but fail in API validate token audience/session binding endpoint-level auth proof
Registration requires email verification capture verification state transitions account timeline with states
MFA optional for some flows compare protected action access with/without MFA role/action differential
Logout appears successful but token works test token reuse after logout/reset post-logout replay proof
Role appears in UI only validate backend authorization with privileged actions server-side denial/allow traces

Advanced Coverage Extensions

  1. Test session fixation across pre- and post-login states.
  2. Test parallel session revocation behavior after password change.
  3. Test role downgrade persistence after privilege changes.
  4. Test account recovery path for unauthorized account linking.
  5. Test SSO fallback paths for local-auth bypass.