mcpField
O
oauth-expert

oauth-expert

github.com/rightnow-aiセキュリティ18.2k120 回インストール24 週間前に更新
リポジトリ

oauth-expert について

oauth-expertは、OAuth 2.0とOpenID Connectの認証・認可を設計する開発者向けスキルです。安全なフロー、トークン検証とライフサイクル管理、アプリ種別をまたぐID連携を扱います。

主な機能

  1. 01Authorization CodeとPKCE
  2. 02JWT検証の指針
  3. 03スコープと権限の設計
  4. 04トークンの保存、更新、失効
  5. 05OIDCとID連携のパターン

活用シーン

  1. 01SPAやモバイルアプリのログイン保護
  2. 02サーバー間認可の設定
  3. 03トークン更新とログアウトの管理
  4. 04複数のIDプロバイダーへの対応

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/rightnow-ai/openfang --skill oauth-expert

インストール後、Claude Code で/oauth-expertを入力して読み込まれたか確認します。

詳細

OAuth と OpenID Connect のエキスパート

OAuth 2.0、OpenID Connect、トークンベースの認証アーキテクチャに関する深い専門知識を持つ、アイデンティティおよびアクセス管理のスペシャリストです。このスキルでは、ウェブアプリ、モバイルアプリ、SPA、マシン間サービスにおける、安全な認可フロー、トークンのライフサイクル管理、アイデンティティ連携パターンの実装を支援します。

主な原則

  • パブリッククライアント(SPA、モバイルアプリ、CLI ツール)では、必ず PKCE を使用する認可コードフローを使用してください。インプリシットフローは非推奨であり、安全ではありません。
  • すべての JWT を徹底的に検証してください。内容を信頼する前に、署名アルゴリズム、発行者(iss)、対象者(aud)、有効期限(exp)、有効開始時刻(nbf)のクレームを確認してください。
  • スコープは広範なロールではなく、特定の権限(read:documents、write:orders)を表すように設計してください。きめ細かなスコープにより、最小権限でのアクセスが可能になります。
  • トークンは安全に保存してください。ウェブアプリでは HTTP のみでアクセス可能なセキュア Cookie、モバイルではセキュアなストレージ API、サーバーサイドサービスでは暗号化された認証情報ストアを使用してください。
  • リフレッシュトークンは機密性の高い認証情報として扱ってください。クライアントに紐付け、使用時にローテーションし、妥当な絶対有効期限を設定してください。

手法

  • 認可コード+PKCE を実装します。ランダムな code_verifier を生成し、S256 を使って code_challenge を導出します。認可リクエストでチャレンジを送信し、トークン交換時に検証子を送信します。
  • ユーザーコンテキストが不要なサーバー間認証には、クライアントクレデンシャルフローを使用します。発行されるトークンのスコープは必要最小限にしてください。
  • スライディングウィンドウ方式の有効期限でトークン更新を構成します。有効期間の短いアクセストークン(5~15 分)と、有効期間の長いリフレッシュトークン(数時間から数日)を発行し、使用のたびにリフレッシュトークンをローテーションします。
  • openid スコープを要求して OIDC を実装します。id_token の署名とクレームを検証し、追加のプロフィールデータには userinfo エンドポイントを使用します。
  • SPA 向けに Backend-for-Frontend(BFF)パターンを設定します。BFF サーバーが OAuth フローを処理し、トークンを HTTP のみでアクセス可能な Cookie に保存することで、トークンを JavaScript から完全に隔離します。
  • ログアウト時に失効エンドポイントを呼び出し、期限切れ前に無効化する必要がある JWT をサーバーサイドの拒否リストで管理して、トークン失効を実装します。

よくあるパターン

  • マルチテナントのアイデンティティ:発行者とテナントのクレームを使用して、トークンの検証先を適切なアイデンティティプロバイダーに振り分けます。顧客が独自の IdP を持ち込めるようにします。
  • ステップアップ認証:機密性の高い操作にアクセスする際、acr クレームを確認し、認証要素が不十分であれば新たな認証フローを開始して、追加の認証要素(MFA)を要求します。
  • トークン交換:OAuth 2.0 Token Exchange(RFC 8693)を使用してサービス間の委任を実現し、バックエンドが元のユーザーに代わってスコープを限定したトークンを取得できるようにします。
  • デバイス認可フロー:入力手段が限られたデバイス(テレビ、CLI ツール)では、ユーザーがブラウザーを備えた別のデバイスで認可するデバイスコードグラントを使用します。

避けるべき落とし穴

  • アクセストークンやリフレッシュトークンを localStorage に保存しないでください。XSS 攻撃に対して脆弱で、ページ上のあらゆる JavaScript からアクセスできてしまいます。
  • 認可リクエストで state パラメーターを省略しないでください。リクエストをユーザーセッションに紐付けることで、CSRF 攻撃を防ぎます。
  • audience クレームを検証せずにトークンを受け入れないでください。ある API 向けに発行されたトークンを、別の API が受け入れてはなりません。
  • 独自の暗号化トークン形式を実装しないでください。十分にテストされた JWT ライブラリと、標準の OAuth/OIDC 仕様を使用してください。

コメント