OAuth セキュリティ：開発者向けガイド

OAuth 2.0 は、委任された認可の業界標準です。これにより、サードパーティのアプリケーションは、ユーザーの資格情報を公開することなく、ユーザーに代わって制限されたリソースにアクセスできます。ただし、OAuth を安全に実装することは複雑です。このガイドでは、開発者向けの OAuth セキュリティのベストプラクティスについて詳しく説明し、一般的な脆弱性と軽減戦略について解説します。

重要なポイント 1 OAuth セキュリティは OAuth プロバイダーだけのものではありません。プロバイダー、クライアント アプリケーション、リソース サーバー間の共有の責任です。

重要なポイント 2 リダイレクト URI の適切な検証は、認可コード傍受攻撃を防ぐために非常に重要です。

重要なポイント 3 短寿命のアクセストークンを使用し、リフレッシュ トークンのローテーションを行うことで、トークンが侵害された場合の影響を大幅に軽減できます。

重要なポイント 4 OAuth 実装を定期的に監査し、セキュリティのベストプラクティスを常に最新の状態に保つことが不可欠です。

OAuth フローと脆弱性の理解

OAuth 2.0 は、さまざまなアプリケーションシナリオに適したいくつかの付与タイプを定義します。最も一般的なものは次のとおりです。

• 認可コード付与： クライアントがクライアント シークレットを安全に保存できる Web アプリケーションおよびモバイル アプリケーションで使用されます。
• 暗黙的な付与： (非推奨) シングルページ アプリケーション (SPA) で使用されますが、アクセストークンが URL で公開されるため、セキュリティが低くなります。
• リソース所有者のパスワード資格情報付与： (推奨されません) クライアントがユーザーのユーザー名とパスワードを収集する必要があり、セキュリティ上のリスクがあります。
• クライアント資格情報付与： ユーザー コンテキストが利用できないマシン間認証で使用されます。

OAuth フロー中に、いくつかの脆弱性が発生する可能性があります。

• 認可コード傍受： 攻撃者は、ユーザーを認可サーバーに似た悪意のあるサイトにリダイレクトし、認可コードを盗みます。
• リダイレクト URI の操作： 誤って構成されたリダイレクト URI を悪用して、認可コードを攻撃者が制御するサーバーに送信します。
• クロスサイト リクエストフォージェリ (CSRF)： 攻撃者は、ユーザーをだまして悪意のあるアプリケーションを承認させます。
• トークンの盗難： ストレージの脆弱性またはネットワーク傍受を通じて、アクセストークンまたはリフレッシュ トークンを侵害します。
• クライアントのなりすまし： 攻撃者が侵害されたクライアント ID とシークレットを使用してリソースにアクセスします。

OAuth 実装の保護

これらの脆弱性を軽減するには、多層的なアプローチが必要です。

1. リダイレクト URI の検証

リダイレクト URI を厳密に検証します。事前に登録され、明示的に定義されたリダイレクト URI のみを許可します。ホワイトリストのアプローチを実装し、ワイルドカード パターンを回避します。リダイレクト URI スキーム (http 対 https) も検証されていることを確認します。OAuth 2.0 RFC 6749 セクション 3.1.2 は、リダイレクト URI の検証の重要性を強調しています。

2. 状態パラメータと Nonce

CSRF 攻撃を防ぐために、state パラメータを使用します。認可サーバーにリダイレクトする前に暗号的にランダムな state 値を生成し、コールバックを受信したときにそれを検証します。追加のセキュリティのために、nonce パラメータの使用も検討してください。

3. PKCE (Proof Key for Code Exchange)

クライアント シークレットを安全に保存できないパブリック クライアント (例: モバイル アプリ、SPA) の場合は、PKCE を実装します。PKCE は、認可リクエストを開始したアプリケーションのみが認可コードをアクセストークンと交換できることを保証することにより、追加の保護レイヤーを追加します。

// PKCE コードの例 (簡略化)
// コード ベリファイアーを生成します
let codeVerifier = generateRandomString();
// コード ベリファイアーからコード チャレンジを生成します
let codeChallenge = generateCodeChallenge(codeVerifier);
// 認可リクエストに codeChallenge と codeChallengeMethod を含めます
// ...
// コード ベリファイアーを指定して、認可コードをアクセストークンと交換します
// ...

4. トークンの管理

短寿命のアクセストークンを使用して、トークンが侵害された場合の影響を最小限に抑えます。各アクセストークン更新時に新しいリフレッシュ トークンを発行し、前のリフレッシュ トークンを無効にする、リフレッシュ トークンのローテーションを実装します。トークンを暗号化とアクセス制御を使用して安全に保存します。クライアント側のコードにトークンを保存しないでください。

API セキュリティに関する考慮事項

API エンドポイントを保護することは、OAuth フローを保護するのと同じくらい重要です。これらのベストプラクティスを実装します。

• トークンの検証： リソースへのアクセスを許可する前に、アクセストークンを徹底的に検証します。トークンの署名、有効期限、および対象者 (aud クレーム) を検証します。
• スコープの検証： スコープの制限を適用します。アクセストークンが要求されたリソースにアクセスするために必要なスコープを持っていることを確認します。
• レート制限： 悪用やサービス拒否攻撃を防ぐために、レート制限を実装します。
• 入力検証： インジェクション攻撃を防ぐために、すべての API 入力を検証します。
• HTTPS のみ： すべての API 通信に HTTPS を強制します。

Didit がどのように役立つか

Didit は、OAuth セキュリティを補完する堅牢な ID 検証とリスク評価機能を提供します。Didit を OAuth フローに統合することで、次のことができます。

• アクセストークンを発行する前に、ユーザーの ID を検証します。
• 不正なアクティビティを検出し、不正アクセスを防ぎます。
• リスクベースのアクセス制御で API セキュリティを強化します。
• ID 検証と AML に関する規制要件に準拠します。

Didit の AML スクリーニング モジュールを統合して、OAuth プロセス中にユーザーをグローバル ウォッチリストに対してチェックし、セキュリティのレイヤーを追加できます。

開始する準備はできましたか？

堅牢な OAuth セキュリティを実装することは、アプリケーションとユーザーデータを保護するために不可欠です。このガイドで概説されているベストプラクティスに従うことで、OAuth 関連の脆弱性のリスクを大幅に軽減できます。

リソース：

• Didit の価格設定
• Didit のドキュメント
• OAuth 2.0 RFC 6749