セキュリティの推奨事項

リソース

OAuthのセキュリティの詳細は、次のリンクを参照してください。

• OAuth 2.0認可フレームワーク

• OAuth 2.0脅威モデルおよびセキュリティに関する考慮事項

• JSON Webトークン(JWT)

• OAuth 2.0クライアント認証および認可権限のJSON Webトークン(JWT)プロファイル

セキュリティ推奨チェックリスト

このページには、最も関連性の高いセキュリティ推奨事項がチェックリストとして記載されている。これにより、アプリケーションのセキュリティを検証し、期待通りにセキュリティ項目に対処できます。

暗号化キー

• クライアントおよびリソース・サーバー・アプリケーションでのTLSの使用

  すべてのアプリケーションでTLSを使用すると、アイデンティティ・ドメイン、リソース所有者、クライアント・アプリケーションおよびリソース・サーバー・アプリケーション間の通信に機密性が提供されます。これにより、認可コード、アクセス・トークンの送信時の盗聴、リフレッシュ・トークン、クライアント資格証明およびユーザー資格証明の盗聴を防止し、リプレイ攻撃を防止します。

• サーバー認証(信頼できるCA検証を使用したHTTPS)の確立

  サーバー認証により、クライアント、リソース・サーバーおよびリソース所有者は、信頼できるCAに対してパブリック証明書を検証した後で、彼ら同士の間の通信を確立できます。

  サーバーが信頼できる証明書(信頼できるCAと一致するホスト名により提供される)を提供できない場合、通信はman-in-the-middle攻撃とみなされます。

  サーバー認証は、スプーフィング、プロキシ設定、man-in-the-middleおよびフィッシング攻撃を防いで、認証コード、アクセス・トークン、クライアントの資格証明およびユーザーの資格証明を取得します。

• アイデンティティ・ドメインでの信頼できるアサーションの使用の検討

  重要なセキュリティ・クライアントは、認証にクライアント・アサーションを使用できます(クライアント・シークレットのかわりに)。

• HTTPSと信頼できるCA検証を使用したリダイレクトURIの保護

  HTTPSと信頼できるCA検証の使用により、認可"コード"のフィッシングとユーザー・セッションのなりすましを防止できます。

管理

• 最小権限の原則に準拠したアプリケーションの構成

  アプリケーションはアイデンティティ・ドメインで、操作に必要な最低限の権限のみを使用して構成する必要があります。

  スコープ、フロー、権限付与タイプおよび操作に絞り込むことで、セキュリティの姿勢が向上し、脆弱なアプリケーションへの影響は軽減されます。

• アプリケーションへのわかりやすい名前と説明の提供

  アプリケーション情報は、「My Apps」および承諾ページの下に表示されます。

  わかりやすいアプリケーション名と説明を使用すると、ユーザーが承諾の認可中に間違いが起きるのを妨げ、監査レポートの向上にも役立ちます。

• スコープに対するわかりやすい説明の提供

  スコープの説明は承諾ページに表示されます。ユーザーが権限を付与しようとしているスコープをわかりやすい方法で説明すると、ユーザーが認可する際に間違いが起きるのを防ぎ、監査レポートの向上にも役立ちます。

• 承諾なしに提供されるスコープの回避

  透過性を活用してリソース所有者を頼りにするには、スコープが必須の場合にのみ権限のないスコープを提供して、そのスコープがユーザーが拒否できないようにする必要があります。

• アクセス・トークンのタイム・アウトの短縮とリフレッシュ・トークンの使用

  アイデンティティ・ドメインは、アイデンティティ・ドメインでのトークンのチェックなしに、リソース・サーバーで検証可能なアクセス・トークンであるJWTをサポートしています。そのため、アクセス・トークンの持続期間は長く、簡単には失効させることができません。

  適切なタイミングでの失効を実装するために、短い存続期間でアクセス・トークンを構成して、新しいアクセス・トークンのリクエストにはリフレッシュ・トークンを使用できます。適切なタイミングでの失効を実行するには、リフレッシュ・トークンを失効させる必要があります。

• アプリケーションのクライアント・シークレットのローテーション

  セキュリティが重要な実装では、クライアント・シークレットのローテーションを実施します。これにより、危険にさらされたクライアント・シークレットを探し出されるリスクが低減します。

リソース所有者(ユーザー)

• リソース所有者への通知の維持

  承諾によるスコープの使用により、リソース所有者に透過性を提供し、不要なスコープをアプリケーションがリクエストしないようにします。

• ユーザー認識

  ユーザーの資格証明を保護する方法と、クライアント、リソース・サーバー・アプリケーションおよびアイデンティティ・ドメインの正当性を識別する方法(特に、認証および承諾ページが表示されたとき)について指導します。これにより、フィッシング攻撃やユーザー資格証明のセキュリティ侵害のリスクが低減します。

アプリケーション開発

• コード、アクセス・トークン、リフレッシュ・トークンおよびクライアント資格証明の保護

  アプリケーションは、コード、アクセス・トークン、リフレッシュ・トークンおよびクライアント資格証明の機密性を確保する必要があります。アプリケーションの開発時には、次に示す対策について考慮してください(特に、アプリケーションのセキュリティ対策について)。

  • コードを保存しない(実行時にアクセス・トークンを取得するときにのみコードを使用)

  • アクセス・トークンは一時メモリーに保持し、その権限付与を制限します

  • リフレッシュ・トークンとクライアント資格証明は、アプリケーションのみがアクセス可能な安全な場所に保存します

• リダイレクトURLの保護

  リダイレクトURL (アイデンティティ・ドメインが認可コードを取得する場所)は、OAuthセキュリティの重要なコンポーネントとみなされます。このURLは、Cross Site Request ForgeryやDenial of Serviceなどの脅威を回避するように慎重に定義してください。

• ネイティブ・アプリケーション・ファイル・システムからのトークンの読取り

  攻撃者は、悪質なアプリケーションを使用してデバイスのファイル・システムへのアクセスを取得し、リフレッシュ・トークンを読み取ろうとします。このリスクを低減するには、シークレットを安全なストレージに保管して、不正なデバイス・アクセスを防止するためにデバイスのロックを使用します。

• ネイティブ・アプリケーションが付属する複製および盗難されたデバイスに対する制御の実装

  ネイティブ・アプリケーションが付属するデバイスが複製または盗難されたときのリスクを低減するには、デバイスのロックを使用して不正なアクセスを防止し、リフレッシュ・トークンを失効させます。

• 公開前のアプリケーションのセキュリティ検証

  脆弱性を減らすために、アプリケーションの公開前に、アプリケーションとアプリケーションをホストする環境のセキュリティをテストしてください。アプリケーションのホスティングと開発に関連する脅威は、アイデンティティ・ドメインでは対処されません。これらの脅威には、アプリケーション・データベースとストレージへの間接アクセス、選択ジャック、クロスサイト・スクリプテーション、スクリプト/SQLインジェクション、アプリケーションでの情報機密性の流出などがありますが、これらに限定されません。

• スコープ・リクエスト時の最小権限の適用

  クライアント・アプリケーションは、使用する可能性のあるスコープまたは実際に使用するスコープのみを含むトークンをリクエストする必要があります。

  urn:opc:idm:__myscopes__ scopeは便利に使用できますが、クライアント・アプリケーションが必要とするものよりも多くのトークンを取得することがあります。

  トークンに広範なスコープが含まれていると、トークンが危険にさらされたときのセキュリティへの影響を大きくすることになります。

  scopeパラメータおよびアクセス・トークンを使用してアイデンティティ・ドメインに様々なレベルのアクセス権を付与する方法の詳細は、スコープを参照してください。

• JWTトークンの検証

  アクセス・トークン(JWT)は、どのパーティから受け取ったものであっても、RFCの「JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants」および「JWT」RFCに従ってJWTを検証してください(ただし、アプリケーションからの直接のリクエストでJWTから受け取ったものを除きます)。

  トークンの検証方法の詳細は、「トークン検証」を参照してください。

  ノート
  
  リソース・サーバーは、JWT検証全体が実行された後でのみ、情報を処理する必要があります。

• JWTトークンの適切な受け取り

  リソース・サーバー・アプリケーションは、Authorization: bearer <token>ヘッダーを使用することでのみアクセス・トークンを受け取る必要があります。これにより、パラメータ・キャッシングに関連する脅威を回避します。

• クライアントとリソース・サーバー・アプリケーションの間の2方向TLSの実装

  セキュリティが重要なアプリケーションの場合は、クライアントとリソース・サーバー・アプリケーションの間に2方向のTLSを実装できます。これにより、DoS (denial of service)攻撃と、なりすまし攻撃のリスクを低減できます。

  認証情報をユーザーから直接収集するアプリケーションを記述しないでください。

• 選択ジャックを防止

  最新のブラウザの場合、X-FRAME-OPTIONSヘッダーの使用を強制することで、認可時のiFramesを回避します。

  旧式のブラウザの場合は、JavaScriptのフレームバースティングの手法が使用されることもありますが、すべてのブラウザで有効になる可能性はありません。

• リソース所有者のパスワード資格証明の使用の回避

  リソース所有者のフローでは、エンド・ユーザーのID、パスワードおよびクライアント所有の資格証明を使用したアクセス・トークンのリクエストがクライアントに許容されています。この権限付与タイプは、次に示す理由から、高いリスクが存在します。

  • クライアント・アプリケーションがユーザー資格証明の収集を管理することになります(UID/パスワードのアンチパターンを維持します)。

  • スコープ・リクエストに対する承諾画面を提示していません。

  移行が理由の場合を除いて、この権限付与タイプの使用は避けてください。

• Cache-Control="no-store"ヘッダーの使用

  このヘッダーは、HTTPプロキシで認証済コンテンツが保護されなくなることや機密データが漏えいすることによるリスクを最小限に抑えます。

• URLパラメータを使用して送信される機密情報のリクエストの回避

  URLパラメータ(GETリクエストで使用されるパラメータ)は、アプリケーション間のあらゆるコンポーネント(アプリケーションのログ、プロキシ・サーバー、ファイアウォール、ネットワーク・エッジ・コンポーネントなど)に記録される可能性があります。

  アイデンティティ・ドメインは、このリスクに対処するPOSTを使用して、代替の検索RESTエンドポイントを実装します。詳細は、「問合せパラメータ」ページを参照してください。