oauth-expert について
oauth-expertは、OAuth 2.0とOpenID Connectの認証・認可を設計する開発者向けスキルです。安全なフロー、トークン検証とライフサイクル管理、アプリ種別をまたぐID連携を扱います。
主な機能
- 01Authorization CodeとPKCE
- 02JWT検証の指針
- 03スコープと権限の設計
- 04トークンの保存、更新、失効
- 05OIDCとID連携のパターン
活用シーン
- 01SPAやモバイルアプリのログイン保護
- 02サーバー間認可の設定
- 03トークン更新とログアウトの管理
- 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 仕様を使用してください。
コメント
Markdown 対応