セキュリティ推奨事項

リソース

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

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

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

• JSON Webトークン

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

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

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

暗号化

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

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

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

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

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

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

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

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

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

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

管理

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

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

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

• アプリケーションにわかりやすい名前と説明を入力します

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

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

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

  有効範囲の説明は承諾ページに表示されます。ユーザーが権限を付与しようとしているスコープをわかりやすい方法で説明すると、ユーザーが認可時にエラーが発生しなくなり、監査レポートが向上します。

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

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

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

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

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

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

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

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

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

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

• ユーザー認識

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

アプリケーション開発

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

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

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

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

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

• リダイレクトURLの保護

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

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

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

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

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

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

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

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

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

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

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

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

• JWTトークンの検証

  アクセス・トークン(JWT)を任意のパーティから受信する場合(アプリケーションからの直接のリクエストでアイデンティティ・ドメイン・サーバーを除く)、OAuth 2.0クライアント認証および認可付与のJWTプロファイルおよびJWT RFCに従ってJWTを検証します。

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

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

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

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

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

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

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

• クリックジャッキングの防止

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

  古いブラウザでは、JavaScriptのフレーム・バスト技術を使用できますが、すべてのブラウザで有効になる可能性はありません。

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

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

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

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

  移行の理由以外は、この権限付与タイプの使用は避けてください。

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

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

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

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

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