configuring-oauth2-authorization-flow

OAuth 2.0 認可フローの設定

概要

Authorization Code with PKCE、Client Credentials、Device Authorization Grant など、安全な OAuth 2.0 認可フローを設定します。このスキルでは、フローの選択、PKCE の実装、トークンのライフサイクル管理、スコープの設計、OAuth 2.1 のセキュリティ要件への準拠について説明します。

使用する場面

• 環境に OAuth2 認可フロー機能をデプロイまたは設定する場合
• コンプライアンス要件に準拠したセキュリティ制御を確立する場合
• この分野のセキュリティアーキテクチャを構築または改善する場合
• この実装を必要とするセキュリティ評価を実施する場合

前提条件

• アイデンティティおよびアクセス管理の概念とツールに関する知識
• 安全に実行できるテスト環境またはラボ環境へのアクセス
• 必要な依存関係をインストールした Python 3.8+
• テスト活動に必要な適切な権限

目標

• パブリッククライアントと機密クライアント向けに Authorization Code フローと PKCE を実装する
• マシン間通信向けに Client Credentials フローを設定する
• 最小権限のスコープ階層を設計する
• トークンの安全な保存、更新、失効を実装する
• OAuth 2.1 のベストプラクティスと RFC 9700 のセキュリティ推奨事項を適用する
• トークンの完全性を検証し、一般的な OAuth 攻撃を防ぐ

主な概念

OAuth 2.0 のグラントタイプ

1. Authorization Code + PKCE：すべての種類のクライアント（Web、モバイル、SPA）に推奨されます。OAuth 2.1 では PKCE が必須です。
2. Client Credentials：ユーザーのコンテキストを介さないマシン間認証です。
3. Device Authorization Grant (RFC 8628)：入力が制限されたデバイス（スマートテレビ、CLI ツール）向けです。
4. Refresh Token：再認証せずに新しいアクセストークンを取得するための長期間有効なトークンです。

PKCE（Proof Key for Code Exchange）

PKCE（RFC 7636）は、認可コードの傍受攻撃を防ぎます。

1. クライアントがランダムな code_verifier を生成します（43～128 文字、非予約 URI 文字）。
2. クライアントが code_challenge = BASE64URL(SHA256(code_verifier)) を計算します。
3. 認可リクエストに code_challenge と code_challenge_method=S256 を含めます。
4. トークンリクエストに元の code_verifier を含めます。
5. サーバーが SHA256(code_verifier) と保存されている code_challenge が一致することを検証します。

トークンの種類

• アクセストークン：有効期間が短いトークン（5～60 分）。ベアラートークンまたは DPoP にバインドされたトークンです。
• リフレッシュトークン：有効期間が長く、ローテーションにより単回使用となるトークンです。
• ID Token (OIDC)：ユーザーの ID クレームを含む JWT です。

ワークフロー

ステップ 1：PKCE を使用した Authorization Code フロー

1. 暗号学的に安全なランダムな code_verifier を生成します（43 文字以上）。
2. S256 メソッドを使用して code_challenge を計算します。
3. 次のパラメーターを指定して、ユーザーを認可エンドポイントにリダイレクトします。
   • response_type=code
   • client_id, redirect_uri, scope, state
   • code_challenge, code_challenge_method=S256
4. ユーザーが認証し、同意します。
5. 認可サーバーが認可コードを付けてリダイレクトします。
6. トークンエンドポイントで、認可コードと code_verifier をトークンに交換します。
7. state パラメーターが元の値と一致することを検証します。

ステップ 2：スコープの設計

• 粒度の細かいスコープを定義します：read:users、write:orders、admin:settings
• 最小権限の原則に従い、必要最小限のスコープをリクエストします。
• リソースサーバーでスコープを検証します。
• スコープ階層と同意要件を文書化します。

ステップ 3：トークンのセキュリティ

• トークンを安全に保存します（Web では httpOnly Cookie、モバイルではキーチェーン）。
• ローテーションを伴うトークン更新を実装します（リフレッシュトークンは単回使用）。
• 適切な有効期限を設定します：アクセストークンは 5～15 分、リフレッシュトークンは 8～24 時間です。
• 送信者制約付きトークンに DPoP（Demonstration of Proof-of-Possession）を有効にします。
• トークン失効エンドポイントを実装します。

ステップ 4：Client Credentials フロー

1. client_id と client_secret を使用してサービスクライアントを登録します。
2. grant_type=client_credentials を指定し、POST /oauth/token でトークンをリクエストします。
3. 必要な権限のスコープを含めます。
4. client_secret を安全に保存します（Vault、環境変数など。コードには保存しません）。
5. より高い保証レベルが必要な場合は、証明書ベースのクライアント認証を実装します。

ステップ 5：セキュリティの強化

• すべての認可コードフローで PKCE を必須にします
• リダイレクト URI を完全一致で照合します（ワイルドカードは使用しません）
• state パラメーターを使用して CSRF 対策を実装します
• リフレッシュトークンのローテーションを有効にし、再利用を検知した場合は失効させます
• RFC 9700 のセキュリティに関するベストプラクティスを適用します
• 暗黙的グラントと ROPC をブロックします（OAuth 2.1 で削除されています）

セキュリティ制御

制御	NIST 800-53	説明
アクセス制御	AC-3	トークンベースのアクセス制御
認証	IA-5	クライアント認証情報の管理
セッション管理	SC-23	トークンライフサイクルの管理
監査	AU-3	すべてのトークン発行と失効を記録します
暗号化による保護	SC-13	PKCE とトークン署名

よくある落とし穴

• 認可コード + PKCE の代わりに暗黙的グラントを使用する（OAuth 2.1 で削除されています）
• httpOnly Cookie の代わりにトークンを localStorage に保存する（XSS に対して脆弱です）
• state パラメーターを検証せず、CSRF 攻撃を可能にしてしまう
• ワイルドカードのリダイレクト URI を使用し、オープンリダイレクト攻撃を許してしまう
• リフレッシュトークンのローテーションを実装せず、トークン窃取が継続可能な状態になる

検証

• 認可コード + PKCE フローが正常に完了する
• トークンエンドポイントで PKCE の code_challenge が検証される
• state パラメーターによって CSRF が防止される
• アクセストークンが設定された有効期間内に期限切れになる
• リフレッシュトークンのローテーションにより、使用ごとに新しいリフレッシュトークンが発行される
• トークンを失効させると、アクセストークンとリフレッシュトークンの両方が無効になる
• クライアント認証情報フローがサービス間通信で機能する
• リソースサーバーでスコープが正しく適用される