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

クライアント登録エンドポイントへのリクエストは（HTTP リクエストおよびレスポンスでの）クリアテキストの資格情報の送信をもたらすため、認可サーバーは、登録エンドポイントにリクエストを送信する際にトランスポート層セキュリティメカニズムの使用を要求しなければなりません（MUST）。サーバーは TLS 1.2 [RFC5246] をサポートしなければならず（MUST）、セキュリティ要件を満たす追加のトランスポート層セキュリティメカニズムをサポートしてもかまいません（MAY）。TLS を使用する場合、クライアントは、RFC 6125 [RFC6125] に従って、TLS/SSL サーバー証明書チェックを実行しなければなりません（MUST）。実装のセキュリティに関する考慮事項は、TLS および DTLS の安全な使用に関する推奨事項 [BCP195] に記載されています。

"authorization_code" や "implicit" などのリダイレクトベースのグラントタイプを使用するクライアントの場合、認可サーバーはクライアントにリダイレクト URI 値を登録するよう要求しなければなりません（MUST）。これは、不正な攻撃者が有効に登録されたクライアントになりすまし、無効なリダイレクト URI またはオープンリダイレクトを介して認可コードまたはトークンを傍受する攻撃を軽減するのに役立ちます。さらに、リダイレクトの戻り値の乗っ取りを防ぐために、登録されたリダイレクト URI 値は次のいずれかでなければなりません（MUST）。

TLS で保護されたリモート Web サイト（例：https://client.example.com/oauth_redirect）
HTTP URI を使用してローカルマシンでホストされている Web サイト（例：http://localhost:8080/oauth_redirect）
クライアントアプリケーションのみが利用できる非 HTTP アプリケーション固有の URL （例：exampleapp://oauth_redirect）

パブリッククライアントは、認可サーバーのポリシーが許可している場合、このプロトコルを使用して認可サーバーに登録できます（MAY）。パブリッククライアントは、"token_endpoint_auth_method" メタデータフィールドに "none" 値を使用し、通常は "implicit" グラントタイプで使用されます。多くの場合、これらのクライアントは、ユーザーのリソースへのアクセスを要求する短命のブラウザ内アプリケーションであり、アクセスは認可サーバーでのユーザーのアクティブなセッションに関連付けられています。このようなクライアントは長期的なストレージを持たないことが多いため、ブラウザアプリケーションがロードされるたびに再登録する必要がある可能性があります。結果として生じる無効なクライアント識別子の急増を避けるために、認可サーバーは、一定期間が経過した後、特定の基準を満たす既存のクライアントの登録を期限切れにすることを決定する場合があります（MAY）。あるいは、このようなクライアントは、ブラウザ内アプリケーションのコードが提供されるサーバーに登録でき、クライアントの構成をコードとともにブラウザにプッシュできます。

異なる OAuth 2.0 グラントタイプには異なるセキュリティと使用特性があるため、認可サーバーは、複数のグラントタイプをサポートするためにソフトウェアの一部に個別の登録を要求する場合があります（MAY）。たとえば、認可サーバーは、"authorization_code" グラントタイプを使用するすべてのクライアントに "token_endpoint_auth_method" のクライアントシークレットの使用を要求する一方で、"implicit" グラントタイプを使用するクライアントにはトークンエンドポイントでの認証を使用しないよう要求する場合があります。このような状況では、サーバーは、クライアントが "authorization_code" グラントタイプと "implicit" グラントタイプの両方を同時に登録することを許可しない場合があります（MAY）。同様に、"authorization_code" グラントタイプはエンドユーザーに代わってアクセスを表すために使用されますが、"client_credentials" グラントタイプはクライアント自体に代わってアクセスを表します。セキュリティ上の理由から、認可サーバーは、これらの異なるユースケースに異なるスコープを使用することを要求する可能性があり、その結果、同じクライアントによってこれら 2 つのグラントタイプが一緒に登録されることを許可しない場合があります（MAY）。これらすべてのケースにおいて、認可サーバーは "invalid_client_metadata" エラーレスポンスで応答します。

ソフトウェアステートメントでクレームとして使用されない限り、認可サーバーはすべてのクライアントメタデータを自己主張として扱わなければなりません（MUST）。たとえば、不正なクライアントは、なりすまそうとしている正当なクライアントの名前とロゴを使用する可能性があります。さらに、不正なクライアントは、正当なクライアントのソフトウェア識別子またはソフトウェアバージョンを使用して、認可サーバー上で正当なクライアントのインスタンスと自分自身を関連付けようとする可能性があります。これに対抗するために、認可サーバーは、登録リクエスト全体とクライアント構成を確認することにより、このリスクを軽減するための適切な手順を講じなければなりません（MUST）。たとえば、認可サーバーは、ロゴのドメイン/サイトがリダイレクト URI のドメイン/サイトと一致しない場合に警告を発行できます。認可サーバーは、異なるリダイレクト URI または異なるクライアント URI を要求している既知のソフトウェア識別子からの登録リクエストを拒否することもできます。認可サーバーはまた、すべての場合において、特にそのようなクライアントが最近登録された場合や、以前に認可サーバーのどのユーザーによっても信頼されていない場合に、動的に登録されたクライアントについてエンドユーザーに警告メッセージを表示することもできます。

認可サーバーがオープンクライアント登録をサポートしている状況では、ユーザーに表示されるクライアントによって提供される URL（"logo_uri"、"tos_uri"、"client_uri"、"policy_uri" など）には細心の注意を払う必要があります。たとえば、不正なクライアントは、"policy_uri" にドライブバイダウンロードへの参照を含む登録リクエストを指定し、認可中にユーザーにそれをクリックさせようとする可能性があります。認可サーバーは、"logo_uri"、"tos_uri"、"client_uri"、および "policy_uri" が "redirect_uris" の配列で定義されたものと同じホストとスキームを持っているかどうか、およびこれらすべての URI が有効な Web ページに解決されるかどうかを確認する必要があります（SHOULD）。これらの URI 値は認可ページでユーザーに表示されることを意図しているため、認可サーバーは可能であれば、URL でホストされている悪意のあるコンテンツからユーザーを保護する必要があります（SHOULD）。たとえば、認可ページで URL をユーザーに提示する前に、認可サーバーは URL でホストされているコンテンツをダウンロードし、マルウェアスキャナーとブラックリストフィルターに対してコンテンツを確認し、URL に安全なコンテンツと安全でないコンテンツが混在しているかどうかを判断し、その他の可能なサーバー側の緩和策を講じることができます。これらの URL のコンテンツはいつでも変更される可能性があり、認可サーバーは URL の安全性に完全な信頼を提供することはできませんが、これらのプラクティスは役立つ可能性があることに注意してください。この種の脅威をさらに軽減するために、認可サーバーは、URL リンクがサードパーティによって提供されたものであり、注意して扱う必要があり、認可サーバー自体によってホストされていないことをユーザーに警告することもできます。たとえば、HTML アンカーでリンクを直接提供する代わりに、認可サーバーは、ユーザーがターゲット URL に進むことを許可する前に、ユーザーをインタースティシャル警告ページに誘導できます。

クライアントは、登録リクエストの一部としてクライアントメタデータを認可サーバーに提示するために、直接 JSON オブジェクトと JWT エンコードされたソフトウェアステートメントの両方を使用できます（MAY）。ソフトウェアステートメントは暗号化によって保護されており、ステートメントの発行者によって行われたクレームを表しますが、JSON オブジェクトはクライアントまたは開発者によって直接行われた自己主張のクレームを表します。ソフトウェアステートメントが有効であり、許容できる機関（ソフトウェア API パブリッシャーなど）によって署名されている場合、ソフトウェアステートメント内のクライアントメタデータの値は、プレーンな JSON オブジェクトで提示されたメタデータ値（傍受および変更された可能性がある）よりも優先されなければなりません（MUST）。

すべてのメタデータ値と同様に、ソフトウェアステートメントの内容がソフトウェアステートメントの発行者によってデジタル署名または MAC 処理されている場合でも、ソフトウェアステートメントはクライアントによって自己主張される項目です。そのため、ソフトウェアステートメントの提示は、ほとんどの場合、クライアントソフトウェアを完全に識別するには不十分です。対照的に、初期アクセストークンは、特定のクライアントソフトウェアに関する情報を必ずしも含んでいるわけではありませんが、登録エンドポイントを使用する権限を表します。認可サーバーは、特定の登録リクエストを受け入れるかどうかを決定する際に、ソフトウェアステートメント、初期アクセストークン、および JSON クライアントメタデータ値を含む完全な登録リクエストを考慮しなければなりません（MUST）。

認可サーバーが、複数のインスタンスを同時に登録することを意図していないクライアントの登録リクエストを受信し、認可サーバーが登録の重複を推測できる場合（たとえば、別の既存のクライアントと同じ "software_id" および "software_version" 値を使用している）、サーバーは新しい登録を疑わしいものとして扱い、登録を拒否する必要があります（SHOULD）。新しいクライアントが既存のクライアントになりすましてユーザーをだまして認可させようとしているか、元の登録がもはや有効ではない可能性があります。この状況の管理の詳細は、認可サーバーの展開に固有であり、この仕様の範囲外です。

クライアント識別子は、認可エンドポイントでクライアントになりすますために使用できるパブリック値であるため、登録されたクライアントの複数のインスタンスに同じクライアント識別子を発行することを決定した認可サーバーは、これが発生する状況について非常に慎重である必要があります。たとえば、認可サーバーは、特定のクライアント識別子を、同じリダイレクトベースのフローと同じリダイレクト URI を使用するクライアントに制限できます。認可サーバーは、同じクライアント識別子が発行されたとしても、登録されたクライアントの複数のインスタンスに同じクライアントシークレットを発行すべきではありません（SHOULD NOT）。そうしないと、クライアントシークレットが漏洩し、悪意のある詐欺師が機密クライアントになりすますことが可能になります。