メインコンテンツまでスキップ

3. Obtaining Authorization Server Metadata (認可サーバーメタデータの取得)

メタデータをサポートする認可サーバーは、既知のURI文字列を認可サーバーの発行者識別子のホストコンポーネントとパスコンポーネント（存在する場合）の間に挿入することによって形成されたパスで、セクション2で指定されたメタデータを含むJSON文書を提供しなければなりません (MUST)。デフォルトで使用される既知のURI文字列は /.well-known/oauth-authorization-server です。このパスは "https" スキームを使用しなければなりません (MUST)。".well-known" の構文とセマンティクスは RFC 5785 [RFC5785] で定義されています。使用される既知のURIサフィックスは、IANA "Well-Known URIs" レジストリ [IANA.well-known] に登録されなければなりません (MUST)。

アプリケーション固有の方法で OAuth 認可サーバーを使用する異なるアプリケーションは、これらのアプリケーションで使用される認可サーバーメタデータを公開するために、異なる既知のURIサフィックスを定義および登録することができます (MAY)。例えば、サンプルアプリケーションがサンプル固有の方法でOAuth認可サーバーを使用し、サンプル固有のメタデータ値を公開する必要がある場合、"example-configuration" URIサフィックスを登録して使用し、認可サーバーの発行者識別子のホストとパスコンポーネントの間に /.well-known/example-configuration を挿入することでメタデータ文書を公開することができます。あるいは、多くのこのようなアプリケーションは、汎用のOAuth認可サーバーに適した選択である、デフォルトの既知のURI文字列 /.well-known/oauth-authorization-server を使用し、アプリケーション固有の文字列を登録しないでしょう。

本仕様を使用するOAuth 2.0アプリケーションは、この目的でどの既知のURIサフィックスを使用するかを指定しなければなりません (MUST)。同じ認可サーバーは、その発行者識別子から派生した複数の既知の場所でメタデータを公開することを選択してもよく (MAY)、例えば、/.well-known/example-configuration と /.well-known/oauth-authorization-server の両方で公開することができます。

一部のOAuthアプリケーションは、既知のURIサフィックス "openid-configuration" を使用することを選択します。セクション5で述べられているように、識別子 /.well-known/openid-configuration はOpenID固有のように見えますが、本仕様での使用は実際には一般的なOAuth 2.0機能を指しており、OpenID Connect固有のものではありません。

3.1. Authorization Server Metadata Request (認可サーバーメタデータリクエスト)​

認可サーバーメタデータ文書は、以前に指定されたパスで HTTP "GET" リクエストを使用して照会されなければなりません (MUST)。

発行者識別子が https://example.com で、既知のURIサフィックスが "oauth-authorization-server" の場合、発行者識別子にはパスコンポーネントが含まれていないため、クライアントはメタデータを取得するために次のリクエストを行います:

GET /.well-known/oauth-authorization-server HTTP/1.1
Host: example.com

発行者識別子の値にパスコンポーネントが含まれている場合、ホストコンポーネントとパスコンポーネントの間に /.well-known/ と既知のURIサフィックスを挿入する前に、末尾の "/" を削除しなければなりません (MUST)。発行者識別子が https://example.com/issuer1 で、既知のURIサフィックスが "oauth-authorization-server" の場合、発行者識別子にはパスコンポーネントが含まれているため、クライアントはメタデータを取得するために次のリクエストを行います:

GET /.well-known/oauth-authorization-server/issuer1 HTTP/1.1
Host: example.com

パスコンポーネントの使用により、ホストごとに複数の発行者をサポートすることができます。これは、一部のマルチテナントホスティング構成で必要です。この ".well-known" の使用は、ホストごとに複数の発行者をサポートするためのものです。RFC 5785 [RFC5785] での使用とは異なり、ホストに関する一般的な情報を提供するものではありません。

3.2. Authorization Server Metadata Response (認可サーバーメタデータレスポンス)​

レスポンスは、すべての必要なエンドポイントと公開鍵の場所情報を含む、認可サーバーの構成に関するクレームのセットです。成功したレスポンスは、200 OK HTTPステータスコードを使用しなければならず (MUST)、"application/json" コンテンツタイプを使用するJSON オブジェクトを返さなければなりません (MUST)。このオブジェクトには、セクション2で定義されたメタデータ値のサブセットであるクレームのセットがそのメンバーとして含まれます。他のクレームも返されてもよい (MAY) です。

複数の値を返すクレームは、JSON配列として表されます。ゼロ個の要素を持つクレームは、レスポンスから省略されなければなりません (MUST)。

エラーレスポンスは、適用可能なHTTPステータスコード値を使用します。

以下は、非規範的なサンプルレスポンスです:

HTTP/1.1 200 OK
Content-Type: application/json

{
 "issuer":
   "https://server.example.com",
 "authorization_endpoint":
   "https://server.example.com/authorize",
 "token_endpoint":
   "https://server.example.com/token",
 "token_endpoint_auth_methods_supported":
   ["client_secret_basic", "private_key_jwt"],
 "token_endpoint_auth_signing_alg_values_supported":
   ["RS256", "ES256"],
 "userinfo_endpoint":
   "https://server.example.com/userinfo",
 "jwks_uri":
   "https://server.example.com/jwks.json",
 "registration_endpoint":
   "https://server.example.com/register",
 "scopes_supported":
   ["openid", "profile", "email", "address",
    "phone", "offline_access"],
 "response_types_supported":
   ["code", "code token"],
 "service_documentation":
   "http://server.example.com/service_documentation.html",
 "ui_locales_supported":
   ["en-US", "en-GB", "en-CA", "fr-FR", "fr-CA"]
}

3.3. Authorization Server Metadata Validation (認可サーバーメタデータの検証)​

返された "issuer" 値は、メタデータを取得するために使用されるURLを作成するために既知のURI文字列が挿入された認可サーバーの発行者識別子の値と完全に同じでなければなりません (MUST)。これらの値が完全に同じでない場合、レスポンスに含まれるデータを使用してはなりません (MUST NOT)。

に最終更新