OAuth 2.0 Authorization Server Metadata

Abstract

概要

This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities.

本仕様は、OAuth 2.0 クライアントが OAuth 2.0 認可サーバーと対話するために必要な情報 (エンドポイントの所在や認可サーバーの機能を含む) を取得するのに使えるメタデータ形式を定義する。

1.Introduction

1.はじめに

This specification generalizes the metadata format defined by "OpenID Connect Discovery 1.0" [OpenID.Discovery] in a way that is compatible with OpenID Connect Discovery while being applicable to a wider set of OAuth 2.0 use cases. This is intentionally parallel to the way that "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591] generalized the dynamic client registration mechanisms defined by "OpenID Connect Dynamic Client Registration 1.0" [OpenID.Registration] in a way that is compatible with it.

本仕様は、「OpenID Connect Discovery 1.0」[OpenID.Discovery] で定義されたメタデータ形式を、OpenID Connect Discovery との互換性を保ちながら、より広い OAuth 2.0 のユースケースに適用できるように一般化したものである。これは、「OAuth 2.0 Dynamic Client Registration Protocol」[RFC7591] が「OpenID Connect Dynamic Client Registration 1.0」[OpenID.Registration] で定義された動的クライアント登録の仕組みを、互換性を保ったまま一般化したのと意図的に並行する関係にある。

The metadata for an authorization server is retrieved from a well- known location as a JSON [RFC8259] document, which declares its endpoint locations and authorization server capabilities. This process is described in Section 3.

認可サーバーのメタデータは、well-known な場所から JSON [RFC8259] ドキュメントとして取得され、そのエンドポイントの所在と認可サーバーの機能を宣言する。この手順は 3 節で説明する。

This metadata can be communicated either in a self-asserted fashion by the server origin via HTTPS or as a set of signed metadata values represented as claims in a JSON Web Token (JWT) [JWT]. In the JWT case, the issuer is vouching for the validity of the data about the authorization server. This is analogous to the role that the Software Statement plays in OAuth Dynamic Client Registration [RFC7591].

このメタデータは、サーバーのオリジンが HTTPS 経由で自己主張する形で伝えることも、JSON Web Token (JWT) [JWT] のクレームとして表現された署名付きメタデータ値の集合として伝えることもできる。JWT の場合、発行者が認可サーバーに関するデータの正当性を保証していることになる。これは OAuth Dynamic Client Registration [RFC7591] において Software Statement が果たす役割と類似している。

The means by which the client chooses an authorization server is out of scope. In some cases, its issuer identifier may be manually configured into the client. In other cases, it may be dynamically discovered, for instance, through the use of WebFinger [RFC7033], as described in Section 2 of "OpenID Connect Discovery 1.0" [OpenID.Discovery].

クライアントが認可サーバーを選択する手段は本仕様の範囲外である。場合によっては、その発行者識別子がクライアントに手動で設定されることもある。別の場合には、「OpenID Connect Discovery 1.0」[OpenID.Discovery] の 2 節に記述されているように、たとえば WebFinger [RFC7033] を用いて動的に発見されることもある。

1.1.Requirements Notation and Conventions

1.1.要件の表記と規約

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

本文書における「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「NOT RECOMMENDED」「MAY」「OPTIONAL」というキーワードは、ここに示すようにすべて大文字で現れる場合に限り、BCP 14 [RFC2119] [RFC8174] に記述されたとおりに解釈される。

All uses of JSON Web Signature (JWS) [JWS] and JSON Web Encryption (JWE) [JWE] data structures in this specification utilize the JWS Compact Serialization or the JWE Compact Serialization; the JWS JSON Serialization and the JWE JSON Serialization are not used.

本仕様における JSON Web Signature (JWS) [JWS] および JSON Web Encryption (JWE) [JWE] データ構造の利用はすべて、JWS Compact Serialization または JWE Compact Serialization を用いる。JWS JSON Serialization および JWE JSON Serialization は使用しない。

1.2.Terminology

1.2.用語

This specification uses the terms "Access Token", "Authorization Code", "Authorization Endpoint", "Authorization Grant", "Authorization Server", "Client", "Client Authentication", "Client Identifier", "Client Secret", "Grant Type", "Protected Resource", "Redirection URI", "Refresh Token", "Resource Owner", "Resource Server", "Response Type", and "Token Endpoint" defined by OAuth 2.0 [RFC6749]; the terms "Claim Name", "Claim Value", and "JSON Web Token (JWT)" defined by JSON Web Token (JWT) [JWT]; and the term "Response Mode" defined by "OAuth 2.0 Multiple Response Type Encoding Practices" [OAuth.Responses].

本仕様は、OAuth 2.0 [RFC6749] で定義された「Access Token」「Authorization Code」「Authorization Endpoint」「Authorization Grant」「Authorization Server」「Client」「Client Authentication」「Client Identifier」「Client Secret」「Grant Type」「Protected Resource」「Redirection URI」「Refresh Token」「Resource Owner」「Resource Server」「Response Type」「Token Endpoint」という用語、JSON Web Token (JWT) [JWT] で定義された「Claim Name」「Claim Value」「JSON Web Token (JWT)」という用語、および「OAuth 2.0 Multiple Response Type Encoding Practices」[OAuth.Responses] で定義された「Response Mode」という用語を使用する。

2.Authorization Server Metadata

2.認可サーバーメタデータ

Authorization servers can have metadata describing their configuration. The following authorization server metadata values are used by this specification and are registered in the IANA "OAuth Authorization Server Metadata" registry established in Section 7.1:

認可サーバーは、その設定を記述するメタデータを持つことができる。本仕様では以下の認可サーバーメタデータ値を使用し、これらは 7.1 節で設立する IANA「OAuth Authorization Server Metadata」レジストリに登録される。

issuer REQUIRED. The authorization server's issuer identifier, which is a URL that uses the "https" scheme and has no query or fragment components. Authorization server metadata is published at a location that is ".well-known" according to RFC 5785 [RFC5785] derived from this issuer identifier, as described in Section 3. The issuer identifier is used to prevent authorization server mix- up attacks, as described in "OAuth 2.0 Mix-Up Mitigation" [MIX-UP].

issuer REQUIRED。認可サーバーの発行者識別子。「https」スキームを使用し、クエリ部およびフラグメント部を持たない URL である。認可サーバーメタデータは、3 節に記述するとおり、この発行者識別子から導出される RFC 5785 [RFC5785] に従った「.well-known」な場所で公開される。発行者識別子は、「OAuth 2.0 Mix-Up Mitigation」[MIX-UP] に記述されている認可サーバーの mix-up 攻撃を防ぐために使用される。

authorization_endpoint URL of the authorization server's authorization endpoint [RFC6749]. This is REQUIRED unless no grant types are supported that use the authorization endpoint.

authorization_endpoint 認可サーバーの認可エンドポイント [RFC6749] の URL。認可エンドポイントを使用するグラントタイプを一切サポートしない場合を除き、これは REQUIRED である。

token_endpoint URL of the authorization server's token endpoint [RFC6749]. This is REQUIRED unless only the implicit grant type is supported.

token_endpoint 認可サーバーのトークンエンドポイント [RFC6749] の URL。インプリシットグラントタイプのみをサポートする場合を除き、これは REQUIRED である。

jwks_uri OPTIONAL. URL of the authorization server's JWK Set [JWK] document. The referenced document contains the signing key(s) the client uses to validate signatures from the authorization server. This URL MUST use the "https" scheme. The JWK Set MAY also contain the server's encryption key or keys, which are used by clients to encrypt requests to the server. When both signing and encryption keys are made available, a "use" (public key use) parameter value is REQUIRED for all keys in the referenced JWK Set to indicate each key's intended usage.

jwks_uri OPTIONAL。認可サーバーの JWK Set [JWK] ドキュメントの URL。参照されるドキュメントには、クライアントが認可サーバーからの署名を検証するのに使う署名鍵が含まれる。この URL は「https」スキームを使用しなければならない (MUST)。JWK Set には、クライアントがサーバーへのリクエストを暗号化するのに使うサーバーの暗号化鍵を含めてもよい (MAY)。署名鍵と暗号化鍵の両方を提供する場合、各鍵の用途を示すために、参照される JWK Set 内のすべての鍵に「use」(公開鍵の用途) パラメータ値が REQUIRED である。

registration_endpoint OPTIONAL. URL of the authorization server's OAuth 2.0 Dynamic Client Registration endpoint [RFC7591].

registration_endpoint OPTIONAL。認可サーバーの OAuth 2.0 Dynamic Client Registration エンドポイント [RFC7591] の URL。

scopes_supported RECOMMENDED. JSON array containing a list of the OAuth 2.0 [RFC6749] "scope" values that this authorization server supports. Servers MAY choose not to advertise some supported scope values even when this parameter is used.

scopes_supported RECOMMENDED。この認可サーバーがサポートする OAuth 2.0 [RFC6749] の「scope」値のリストを含む JSON 配列。このパラメータを使用する場合でも、サーバーはサポートするスコープ値の一部を公開しないことを選んでもよい (MAY)。

response_types_supported REQUIRED. JSON array containing a list of the OAuth 2.0 "response_type" values that this authorization server supports. The array values used are the same as those used with the "response_types" parameter defined by "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591].

response_types_supported REQUIRED。この認可サーバーがサポートする OAuth 2.0 の「response_type」値のリストを含む JSON 配列。配列の値は、「OAuth 2.0 Dynamic Client Registration Protocol」[RFC7591] で定義された「response_types」パラメータで使われるものと同じである。

response_modes_supported OPTIONAL. JSON array containing a list of the OAuth 2.0 "response_mode" values that this authorization server supports, as specified in "OAuth 2.0 Multiple Response Type Encoding Practices" [OAuth.Responses]. If omitted, the default is "["query", "fragment"]". The response mode value "form_post" is also defined in "OAuth 2.0 Form Post Response Mode" [OAuth.Post].

response_modes_supported OPTIONAL。「OAuth 2.0 Multiple Response Type Encoding Practices」[OAuth.Responses] で規定された、この認可サーバーがサポートする OAuth 2.0 の「response_mode」値のリストを含む JSON 配列。省略した場合のデフォルトは「["query", "fragment"]」である。レスポンスモード値「form_post」は「OAuth 2.0 Form Post Response Mode」[OAuth.Post] でも定義されている。

grant_types_supported OPTIONAL. JSON array containing a list of the OAuth 2.0 grant type values that this authorization server supports. The array values used are the same as those used with the "grant_types" parameter defined by "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591]. If omitted, the default value is "["authorization_code", "implicit"]".

grant_types_supported OPTIONAL。この認可サーバーがサポートする OAuth 2.0 グラントタイプ値のリストを含む JSON 配列。配列の値は、「OAuth 2.0 Dynamic Client Registration Protocol」[RFC7591] で定義された「grant_types」パラメータで使われるものと同じである。省略した場合のデフォルト値は「["authorization_code", "implicit"]」である。

token_endpoint_auth_methods_supported OPTIONAL. JSON array containing a list of client authentication methods supported by this token endpoint. Client authentication method values are used in the "token_endpoint_auth_method" parameter defined in Section 2 of [RFC7591]. If omitted, the default is "client_secret_basic" -- the HTTP Basic Authentication Scheme specified in Section 2.3.1 of OAuth 2.0 [RFC6749].

token_endpoint_auth_methods_supported OPTIONAL。このトークンエンドポイントがサポートするクライアント認証方式のリストを含む JSON 配列。クライアント認証方式の値は、[RFC7591] の 2 節で定義された「token_endpoint_auth_method」パラメータで使われるものである。省略した場合のデフォルトは「client_secret_basic」、すなわち OAuth 2.0 [RFC6749] の 2.3.1 節で規定された HTTP Basic 認証スキームである。

service_documentation OPTIONAL. URL of a page containing human-readable information that developers might want or need to know when using the authorization server. In particular, if the authorization server does not support Dynamic Client Registration, then information on how to register clients needs to be provided in this documentation.

service_documentation OPTIONAL。認可サーバーを利用する際に開発者が知りたい、あるいは知る必要があるかもしれない、人間が読める情報を含むページの URL。特に、認可サーバーが動的クライアント登録をサポートしていない場合は、クライアントの登録方法に関する情報をこの文書で提供する必要がある。

ui_locales_supported OPTIONAL. Languages and scripts supported for the user interface, represented as a JSON array of language tag values from BCP 47 [RFC5646]. If omitted, the set of supported languages and scripts is unspecified.

ui_locales_supported OPTIONAL。ユーザーインターフェースでサポートされる言語およびスクリプト。BCP 47 [RFC5646] の言語タグ値の JSON 配列として表現される。省略した場合、サポートされる言語およびスクリプトの集合は未規定である。

op_policy_uri OPTIONAL. URL that the authorization server provides to the person registering the client to read about the authorization server's requirements on how the client can use the data provided by the authorization server. The registration process SHOULD display this URL to the person registering the client if it is given. As described in Section 5, despite the identifier "op_policy_uri" appearing to be OpenID-specific, its usage in this specification is actually referring to a general OAuth 2.0 feature that is not specific to OpenID Connect.

op_policy_uri OPTIONAL。認可サーバーが提供するデータをクライアントがどのように使用できるかに関する認可サーバーの要件について読めるように、認可サーバーがクライアントを登録する人に提供する URL。登録手続きは、この URL が与えられている場合、クライアントを登録する人にこの URL を表示すべきである (SHOULD)。5 節に記述するとおり、識別子「op_policy_uri」は OpenID 固有に見えるが、本仕様におけるその用法は実際には OpenID Connect に固有ではない一般的な OAuth 2.0 の機能を指している。

op_tos_uri OPTIONAL. URL that the authorization server provides to the person registering the client to read about the authorization server's terms of service. The registration process SHOULD display this URL to the person registering the client if it is given. As described in Section 5, despite the identifier "op_tos_uri", appearing to be OpenID-specific, its usage in this specification is actually referring to a general OAuth 2.0 feature that is not specific to OpenID Connect.

op_tos_uri OPTIONAL。認可サーバーのサービス利用規約について読めるように、認可サーバーがクライアントを登録する人に提供する URL。登録手続きは、この URL が与えられている場合、クライアントを登録する人にこの URL を表示すべきである (SHOULD)。5 節に記述するとおり、識別子「op_tos_uri」は OpenID 固有に見えるが、本仕様におけるその用法は実際には OpenID Connect に固有ではない一般的な OAuth 2.0 の機能を指している。

revocation_endpoint OPTIONAL. URL of the authorization server's OAuth 2.0 revocation endpoint [RFC7009].

revocation_endpoint OPTIONAL。認可サーバーの OAuth 2.0 失効エンドポイント [RFC7009] の URL。

revocation_endpoint_auth_methods_supported OPTIONAL. JSON array containing a list of client authentication methods supported by this revocation endpoint. The valid client authentication method values are those registered in the IANA "OAuth Token Endpoint Authentication Methods" registry [IANA.OAuth.Parameters]. If omitted, the default is "client_secret_basic" -- the HTTP Basic Authentication Scheme specified in Section 2.3.1 of OAuth 2.0 [RFC6749].

revocation_endpoint_auth_methods_supported OPTIONAL。この失効エンドポイントがサポートするクライアント認証方式のリストを含む JSON 配列。有効なクライアント認証方式の値は、IANA「OAuth Token Endpoint Authentication Methods」レジストリ [IANA.OAuth.Parameters] に登録されているものである。省略した場合のデフォルトは「client_secret_basic」、すなわち OAuth 2.0 [RFC6749] の 2.3.1 節で規定された HTTP Basic 認証スキームである。

introspection_endpoint OPTIONAL. URL of the authorization server's OAuth 2.0 introspection endpoint [RFC7662].

introspection_endpoint OPTIONAL。認可サーバーの OAuth 2.0 イントロスペクションエンドポイント [RFC7662] の URL。

introspection_endpoint_auth_methods_supported OPTIONAL. JSON array containing a list of client authentication methods supported by this introspection endpoint. The valid client authentication method values are those registered in the IANA "OAuth Token Endpoint Authentication Methods" registry [IANA.OAuth.Parameters] or those registered in the IANA "OAuth Access Token Types" registry [IANA.OAuth.Parameters]. (These values are and will remain distinct, due to Section 7.2.) If omitted, the set of supported authentication methods MUST be determined by other means.

introspection_endpoint_auth_methods_supported OPTIONAL。このイントロスペクションエンドポイントがサポートするクライアント認証方式のリストを含む JSON 配列。有効なクライアント認証方式の値は、IANA「OAuth Token Endpoint Authentication Methods」レジストリ [IANA.OAuth.Parameters] に登録されているもの、または IANA「OAuth Access Token Types」レジストリ [IANA.OAuth.Parameters] に登録されているものである。(これらの値は 7.2 節により、現在もこれからも互いに重複しない。) 省略した場合、サポートされる認証方式の集合は他の手段で決定しなければならない (MUST)。

code_challenge_methods_supported OPTIONAL. JSON array containing a list of Proof Key for Code Exchange (PKCE) [RFC7636] code challenge methods supported by this authorization server. Code challenge method values are used in the "code_challenge_method" parameter defined in Section 4.3 of [RFC7636]. The valid code challenge method values are those registered in the IANA "PKCE Code Challenge Methods" registry [IANA.OAuth.Parameters]. If omitted, the authorization server does not support PKCE.

code_challenge_methods_supported OPTIONAL。この認可サーバーがサポートする Proof Key for Code Exchange (PKCE) [RFC7636] のコードチャレンジ方式のリストを含む JSON 配列。コードチャレンジ方式の値は、[RFC7636] の 4.3 節で定義された「code_challenge_method」パラメータで使われるものである。有効なコードチャレンジ方式の値は、IANA「PKCE Code Challenge Methods」レジストリ [IANA.OAuth.Parameters] に登録されているものである。省略した場合、認可サーバーは PKCE をサポートしない。

Additional authorization server metadata parameters MAY also be used. Some are defined by other specifications, such as OpenID Connect Discovery 1.0 [OpenID.Discovery].

追加の認可サーバーメタデータパラメータを使用してもよい (MAY)。一部は OpenID Connect Discovery 1.0 [OpenID.Discovery] など他の仕様で定義されている。

2.1.Signed Authorization Server Metadata

2.1.署名付き認可サーバーメタデータ

In addition to JSON elements, metadata values MAY also be provided as a "signed_metadata" value, which is a JSON Web Token (JWT) [JWT] that asserts metadata values about the authorization server as a bundle. A set of claims that can be used in signed metadata is defined in Section 2. The signed metadata MUST be digitally signed or MACed using JSON Web Signature (JWS) [JWS] and MUST contain an "iss" (issuer) claim denoting the party attesting to the claims in the signed metadata. Consumers of the metadata MAY ignore the signed metadata if they do not support this feature. If the consumer of the metadata supports signed metadata, metadata values conveyed in the signed metadata MUST take precedence over the corresponding values conveyed using plain JSON elements.

JSON 要素に加えて、メタデータ値は「signed_metadata」値として提供されてもよい (MAY)。これは認可サーバーに関するメタデータ値をひとまとめにして主張する JSON Web Token (JWT) [JWT] である。署名付きメタデータで使用できるクレームの集合は 2 節で定義する。署名付きメタデータは JSON Web Signature (JWS) [JWS] を用いてデジタル署名または MAC されなければならず (MUST)、署名付きメタデータ内のクレームを証明する当事者を示す「iss」(発行者) クレームを含まなければならない (MUST)。メタデータの消費者は、この機能をサポートしない場合、署名付きメタデータを無視してもよい (MAY)。メタデータの消費者が署名付きメタデータをサポートする場合、署名付きメタデータで伝えられるメタデータ値は、プレーンな JSON 要素で伝えられる対応する値より優先されなければならない (MUST)。

Signed metadata is included in the authorization server metadata JSON object using this OPTIONAL member:

署名付きメタデータは、以下の OPTIONAL なメンバーを用いて認可サーバーメタデータ JSON オブジェクトに含められる。

signed_metadata A JWT containing metadata values about the authorization server as claims. This is a string value consisting of the entire signed JWT. A "signed_metadata" metadata value SHOULD NOT appear as a claim in the JWT.

signed_metadata 認可サーバーに関するメタデータ値をクレームとして含む JWT。これは署名済み JWT 全体からなる文字列値である。「signed_metadata」メタデータ値は、JWT 内のクレームとして現れるべきではない (SHOULD NOT)。

3.Obtaining Authorization Server Metadata

3.認可サーバーメタデータの取得

Authorization servers supporting metadata MUST make a JSON document containing metadata as specified in Section 2 available at a path formed by inserting a well-known URI string into the authorization server's issuer identifier between the host component and the path component, if any. By default, the well-known URI string used is "/.well-known/oauth-authorization-server". This path MUST use the "https" scheme. The syntax and semantics of ".well-known" are defined in RFC 5785 [RFC5785]. The well-known URI suffix used MUST be registered in the IANA "Well-Known URIs" registry [IANA.well-known].

メタデータをサポートする認可サーバーは、2 節で規定するメタデータを含む JSON ドキュメントを、認可サーバーの発行者識別子のホスト部とパス部 (もしあれば) の間に well-known URI 文字列を挿入して形成されるパスで利用可能にしなければならない (MUST)。デフォルトで使用される well-known URI 文字列は「/.well-known/oauth-authorization-server」である。このパスは「https」スキームを使用しなければならない (MUST)。「.well-known」の構文と意味は RFC 5785 [RFC5785] で定義されている。使用する well-known URI サフィックスは IANA「Well-Known URIs」レジストリ [IANA.well-known] に登録されていなければならない (MUST)。

Different applications utilizing OAuth authorization servers in application-specific ways may define and register different well- known URI suffixes used to publish authorization server metadata as used by those applications. For instance, if the example application uses an OAuth authorization server in an example-specific way, and there are example-specific metadata values that it needs to publish, then it might register and use the "example-configuration" URI suffix and publish the metadata document at the path formed by inserting "/.well-known/example-configuration" between the host and path components of the authorization server's issuer identifier. Alternatively, many such applications will use the default well-known URI string "/.well-known/oauth-authorization-server", which is the right choice for general-purpose OAuth authorization servers, and not register an application-specific one.

OAuth 認可サーバーをアプリケーション固有の方法で利用するさまざまなアプリケーションは、それらのアプリケーションが用いる認可サーバーメタデータを公開するために、異なる well-known URI サフィックスを定義して登録してもよい。たとえば、example アプリケーションが OAuth 認可サーバーを example 固有の方法で利用し、公開する必要のある example 固有のメタデータ値がある場合、"example-configuration" という URI サフィックスを登録して用い、認可サーバーの発行者識別子のホスト部分とパス部分の間に "/.well-known/example-configuration" を挿入して形成されるパスでメタデータ文書を公開することが考えられる。あるいは、そのようなアプリケーションの多くは、汎用の OAuth 認可サーバーにとって適切な選択である既定の well-known URI 文字列 "/.well-known/oauth-authorization-server" を用い、アプリケーション固有のものは登録しないであろう。

An OAuth 2.0 application using this specification MUST specify what well-known URI suffix it will use for this purpose. The same authorization server MAY choose to publish its metadata at multiple well-known locations derived from its issuer identifier, for example, publishing metadata at both "/.well-known/example-configuration" and "/.well-known/oauth-authorization-server".

本仕様を使用する OAuth 2.0 アプリケーションは、この目的でどの well-known URI サフィックスを使用するかを規定しなければならない (MUST)。同一の認可サーバーは、その発行者識別子から導出される複数の well-known な場所でメタデータを公開することを選んでもよい (MAY)。たとえば「/.well-known/example-configuration」と「/.well-known/oauth-authorization-server」の両方でメタデータを公開することである。

Some OAuth applications will choose to use the well-known URI suffix "openid-configuration". As described in Section 5, despite the identifier "/.well-known/openid-configuration", appearing to be OpenID specific, its usage in this specification is actually referring to a general OAuth 2.0 feature that is not specific to OpenID Connect.

一部の OAuth アプリケーションは well-known URI サフィックス「openid-configuration」の使用を選ぶだろう。5 節に記述するとおり、識別子「/.well-known/openid-configuration」は OpenID 固有に見えるが、本仕様におけるその用法は実際には OpenID Connect に固有ではない一般的な OAuth 2.0 の機能を指している。

3.1.Authorization Server Metadata Request

3.1.認可サーバーメタデータリクエスト

An authorization server metadata document MUST be queried using an HTTP "GET" request at the previously specified path.

認可サーバーメタデータドキュメントは、前述のパスに対する HTTP「GET」リクエストを用いて照会されなければならない (MUST)。

The client would make the following request when the issuer identifier is "https://example.com" and the well-known URI suffix is "oauth-authorization-server" to obtain the metadata, since the issuer identifier contains no path component:

発行者識別子が「https://example.com」で well-known URI サフィックスが「oauth-authorization-server」の場合、発行者識別子にパス部が含まれないので、クライアントはメタデータを取得するために以下のリクエストを行う。

If the issuer identifier value contains a path component, any terminating "/" MUST be removed before inserting "/.well-known/" and the well-known URI suffix between the host component and the path component. The client would make the following request when the issuer identifier is "https://example.com/issuer1" and the well-known URI suffix is "oauth-authorization-server" to obtain the metadata, since the issuer identifier contains a path component:

発行者識別子の値にパス部が含まれる場合、ホスト部とパス部の間に「/.well-known/」と well-known URI サフィックスを挿入する前に、末尾の「/」をすべて取り除かなければならない (MUST)。発行者識別子が「https://example.com/issuer1」で well-known URI サフィックスが「oauth-authorization-server」の場合、発行者識別子にパス部が含まれるので、クライアントはメタデータを取得するために以下のリクエストを行う。

Using path components enables supporting multiple issuers per host. This is required in some multi-tenant hosting configurations. This use of ".well-known" is for supporting multiple issuers per host; unlike its use in RFC 5785 [RFC5785], it does not provide general information about the host.

パス部を使用することで、1 つのホストあたり複数の発行者をサポートできる。これは一部のマルチテナントホスティング構成で必要とされる。この「.well-known」の使用は 1 つのホストあたり複数の発行者をサポートするためのものであり、RFC 5785 [RFC5785] における使用とは異なり、ホストに関する一般的な情報を提供するものではない。

3.2.Authorization Server Metadata Response

3.2.認可サーバーメタデータレスポンス

The response is a set of claims about the authorization server's configuration, including all necessary endpoints and public key location information. A successful response MUST use the 200 OK HTTP status code and return a JSON object using the "application/json" content type that contains a set of claims as its members that are a subset of the metadata values defined in Section 2. Other claims MAY also be returned.

レスポンスは、必要なすべてのエンドポイントと公開鍵の所在情報を含む、認可サーバーの設定に関するクレームの集合である。成功レスポンスは 200 OK HTTP ステータスコードを使用し、「application/json」コンテンツタイプを用いて、2 節で定義したメタデータ値の部分集合であるクレームの集合をメンバーとして含む JSON オブジェクトを返さなければならない (MUST)。他のクレームを返してもよい (MAY)。

Claims that return multiple values are represented as JSON arrays. Claims with zero elements MUST be omitted from the response.

複数の値を返すクレームは JSON 配列として表現される。要素数がゼロのクレームはレスポンスから省略されなければならない (MUST)。

An error response uses the applicable HTTP status code value.

エラーレスポンスは該当する HTTP ステータスコード値を使用する。

The following is a non-normative example response:

以下は非規範的なレスポンスの例である。

3.3.Authorization Server Metadata Validation

3.3.認可サーバーメタデータの検証

The "issuer" value returned MUST be identical to the authorization server's issuer identifier value into which the well-known URI string was inserted to create the URL used to retrieve the metadata. If these values are not identical, the data contained in the response MUST NOT be used.

返された「issuer」値は、メタデータ取得に使用した URL を作るために well-known URI 文字列を挿入した認可サーバーの発行者識別子の値と同一でなければならない (MUST)。これらの値が同一でない場合、レスポンスに含まれるデータを使用してはならない (MUST NOT)。

4.String Operations

4.文字列操作

Processing some OAuth 2.0 messages requires comparing values in the messages to known values. For example, the member names in the metadata response might be compared to specific member names such as "issuer". Comparing Unicode [UNICODE] strings, however, has significant security implications.

一部の OAuth 2.0 メッセージの処理では、メッセージ内の値を既知の値と比較する必要がある。たとえば、メタデータレスポンス内のメンバー名は「issuer」のような特定のメンバー名と比較されることがある。しかし、Unicode [UNICODE] 文字列の比較にはセキュリティ上の重大な含意がある。

Therefore, comparisons between JSON strings and other Unicode strings MUST be performed as specified below:

したがって、JSON 文字列と他の Unicode 文字列との比較は、以下に規定するとおりに実行されなければならない (MUST)。

1. Remove any JSON-applied escaping to produce an array of Unicode code points.

1. JSON によるエスケープをすべて取り除き、Unicode コードポイントの配列を生成する。

2. Unicode Normalization [USA15] MUST NOT be applied at any point to either the JSON string or the string it is to be compared against.

2. Unicode 正規化 [USA15] を、JSON 文字列にも比較対象の文字列にも、いかなる時点でも適用してはならない (MUST NOT)。

3. Comparisons between the two strings MUST be performed as a Unicode code-point-to-code-point equality comparison.

3. 2 つの文字列の比較は、Unicode コードポイント対コードポイントの等価比較として実行されなければならない (MUST)。

Note that this is the same equality comparison procedure described in Section 8.3 of [RFC8259].

これは [RFC8259] の 8.3 節に記述されている等価比較手順と同じであることに注意すること。

5.Compatibility Notes

5.互換性に関する注記

The identifiers "/.well-known/openid-configuration", "op_policy_uri", and "op_tos_uri" contain strings referring to the OpenID Connect [OpenID.Core] family of specifications that were originally defined by "OpenID Connect Discovery 1.0" [OpenID.Discovery]. Despite the reuse of these identifiers that appear to be OpenID specific, their usage in this specification is actually referring to general OAuth 2.0 features that are not specific to OpenID Connect.

識別子「/.well-known/openid-configuration」「op_policy_uri」「op_tos_uri」には、もともと「OpenID Connect Discovery 1.0」[OpenID.Discovery] で定義された OpenID Connect [OpenID.Core] 仕様ファミリーを指す文字列が含まれている。OpenID 固有に見えるこれらの識別子を再利用しているが、本仕様におけるその用法は実際には OpenID Connect に固有ではない一般的な OAuth 2.0 の機能を指している。

The algorithm for transforming the issuer identifier to an authorization server metadata location defined in Section 3 is equivalent to the corresponding transformation defined in Section 4 of "OpenID Connect Discovery 1.0" [OpenID.Discovery], provided that the issuer identifier contains no path component. However, they are different when there is a path component, because OpenID Connect Discovery 1.0 specifies that the well-known URI string is appended to the issuer identifier (e.g., "https://example.com/issuer1/.well-known/openid-configuration"), whereas this specification specifies that the well-known URI string is inserted before the path component of the issuer identifier (e.g., "https://example.com/.well-known/openid-configuration/issuer1").

The algorithm for transforming the issuer identifier to an authorization server metadata location defined in Section 3 is equivalent to the corresponding transformation defined in Section 4 of "OpenID Connect Discovery 1.0" [OpenID.Discovery], provided that the issuer identifier contains no path component. However, they are different when there is a path component, because OpenID Connect Discovery 1.0 specifies that the well-known URI string is appended to the issuer identifier (e.g., "https://example.com/issuer1/.well-known/openid-configuration"), whereas this specification specifies that the well-known URI string is inserted before the path component of the issuer identifier (e.g., "https://example.com/.well-known/openid-configuration/issuer1").

Going forward, OAuth authorization server metadata locations should use the transformation defined in this specification. However, when deployed in legacy environments in which the OpenID Connect Discovery 1.0 transformation is already used, it may be necessary during a transition period to publish metadata for issuer identifiers containing a path component at both locations. During this transition period, applications should first apply the transformation defined in this specification and attempt to retrieve the authorization server metadata from the resulting location; only if the retrieval from that location fails should they fall back to attempting to retrieve it from the alternate location obtained using the transformation defined by OpenID Connect Discovery 1.0. This backwards-compatible behavior should only be necessary when the well- known URI suffix employed by the application is "openid- configuration".

今後、OAuth 認可サーバーメタデータの所在には本仕様で定義した変換を使用するべきである。しかし、OpenID Connect Discovery 1.0 の変換がすでに使われているレガシー環境に展開する場合、移行期間中はパス部を含む発行者識別子のメタデータを両方の場所で公開する必要があるかもしれない。この移行期間中、アプリケーションはまず本仕様で定義した変換を適用し、得られた場所から認可サーバーメタデータの取得を試みるべきであり、その場所からの取得が失敗した場合に限り、OpenID Connect Discovery 1.0 で定義された変換により得られる代替の場所からの取得にフォールバックするべきである。この後方互換の振る舞いは、アプリケーションが用いる well-known URI サフィックスが「openid-configuration」である場合にのみ必要となるはずである。

6.Security Considerations

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

6.1.TLS Requirements

6.1.TLS の要件

Implementations MUST support TLS. Which version(s) ought to be implemented will vary over time and depend on the widespread deployment and known security vulnerabilities at the time of implementation. The authorization server MUST support TLS version 1.2 [RFC5246] and MAY support additional TLS mechanisms meeting its security requirements. When using TLS, the client MUST perform a TLS/SSL server certificate check, per RFC 6125 [RFC6125]. Implementation security considerations can be found in "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)" [BCP195].

実装は TLS をサポートしなければならない (MUST)。どのバージョンを実装すべきかは時とともに変化し、実装時点での普及状況と既知のセキュリティ脆弱性に依存する。認可サーバーは TLS バージョン 1.2 [RFC5246] をサポートしなければならず (MUST)、そのセキュリティ要件を満たす追加の TLS 機構をサポートしてもよい (MAY)。TLS を使用する際、クライアントは RFC 6125 [RFC6125] に従って TLS/SSL サーバー証明書の検査を実行しなければならない (MUST)。実装上のセキュリティに関する考慮事項は「Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)」[BCP195] にある。

To protect against information disclosure and tampering, confidentiality protection MUST be applied using TLS with a ciphersuite that provides confidentiality and integrity protection.

情報漏洩と改ざんから保護するため、機密性と完全性の保護を提供する暗号スイートを用いた TLS により、機密性保護を適用しなければならない (MUST)。

6.2.Impersonation Attacks

6.2.なりすまし攻撃

TLS certificate checking MUST be performed by the client, as described in Section 6.1, when making an authorization server metadata request. Checking that the server certificate is valid for the issuer identifier URL prevents man-in-middle and DNS-based attacks. These attacks could cause a client to be tricked into using an attacker's keys and endpoints, which would enable impersonation of the legitimate authorization server. If an attacker can accomplish this, they can access the resources that the affected client has access to using the authorization server that they are impersonating.

認可サーバーメタデータリクエストを行う際、クライアントは 6.1 節で述べるとおり TLS 証明書の検査を実施しなければならない (MUST)。サーバー証明書が発行者識別子 URL に対して有効であることを確認することで、中間者攻撃や DNS ベースの攻撃を防ぐ。これらの攻撃により、クライアントが攻撃者の鍵とエンドポイントを使うよう騙され、正規の認可サーバーへのなりすましが可能になるおそれがある。攻撃者がこれを達成できれば、なりすました認可サーバーを用いて、影響を受けたクライアントがアクセスできるリソースにアクセスできる。

An attacker may also attempt to impersonate an authorization server by publishing a metadata document that contains an "issuer" claim using the issuer identifier URL of the authorization server being impersonated, but with its own endpoints and signing keys. This would enable it to impersonate that authorization server, if accepted by the client. To prevent this, the client MUST ensure that the issuer identifier URL it is using as the prefix for the metadata request exactly matches the value of the "issuer" metadata value in the authorization server metadata document received by the client.

攻撃者はまた、なりすまし対象の認可サーバーの発行者識別子 URL を用いた「issuer」クレームを含みつつ、自身のエンドポイントと署名鍵を持つメタデータドキュメントを公開することで、認可サーバーへのなりすましを試みるかもしれない。クライアントがこれを受け入れれば、その認可サーバーへのなりすましが可能になる。これを防ぐため、クライアントはメタデータリクエストのプレフィックスとして使用している発行者識別子 URL が、クライアントが受信した認可サーバーメタデータドキュメント内の「issuer」メタデータ値と正確に一致することを確実にしなければならない (MUST)。

6.3.Publishing Metadata in a Standard Format

6.3.標準形式でのメタデータの公開

Publishing information about the authorization server in a standard format makes it easier for both legitimate clients and attackers to use the authorization server. Whether an authorization server publishes its metadata in an ad hoc manner or in the standard format defined by this specification, the same defenses against attacks that might be mounted that use this information should be applied.

認可サーバーに関する情報を標準形式で公開することは、正当なクライアントにとっても攻撃者にとっても認可サーバーの利用を容易にする。認可サーバーがメタデータをアドホックな方法で公開するか本仕様で定義した標準形式で公開するかにかかわらず、この情報を用いて仕掛けられうる攻撃に対しては同じ防御を適用するべきである。

6.4.Protected Resources

6.4.保護リソース

Secure determination of appropriate protected resources to use with an authorization server for all use cases is out of scope of this specification. This specification assumes that the client has a means of determining appropriate protected resources to use with an authorization server and that the client is using the correct metadata for each authorization server. Implementers need to be aware that if an inappropriate protected resource is used by the client, that an attacker may be able to act as a man-in-the-middle proxy to a valid protected resource without it being detected by the authorization server or the client.

すべてのユースケースについて、認可サーバーと併用する適切な保護リソースを安全に決定することは、本仕様の範囲外である。本仕様は、クライアントが認可サーバーと併用する適切な保護リソースを決定する手段を持ち、各認可サーバーに対して正しいメタデータを使用していることを前提とする。実装者は、クライアントが不適切な保護リソースを使用した場合、認可サーバーにもクライアントにも検知されることなく、攻撃者が正当な保護リソースへの中間者プロキシとして振る舞える可能性があることを認識する必要がある。

The ways to determine the appropriate protected resources to use with an authorization server are, in general, application dependent. For instance, some authorization servers are used with a fixed protected resource or set of protected resources, the locations of which may be well known or could be published as metadata values by the authorization server. In other cases, the set of resources that can be used with an authorization server can be dynamically changed by administrative actions. Many other means of determining appropriate associations between authorization servers and protected resources are also possible.

認可サーバーと併用する適切な保護リソースを決定する方法は、一般にアプリケーションに依存する。たとえば、一部の認可サーバーは固定された保護リソースまたは保護リソースの集合とともに使用され、その所在は広く知られているか、認可サーバーがメタデータ値として公開しうる。別の場合には、認可サーバーと併用できるリソースの集合が管理操作によって動的に変更されることもある。認可サーバーと保護リソースの適切な関連付けを決定する他の多くの手段も可能である。

7.IANA Considerations

7.IANA に関する考慮事項

The following registration procedure is used for the registry established by this specification.

本仕様で設立するレジストリには、以下の登録手続きを用いる。

Values are registered on a Specification Required [RFC8126] basis after a two-week review period on the oauth-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published.

値は、oauth-ext-review@ietf.org メーリングリストでの 2 週間のレビュー期間の後、1 名以上の指定専門家 (Designated Expert) の助言に基づき、Specification Required [RFC8126] の方針で登録される。ただし、公開前の値の割り当てを可能にするため、指定専門家はそのような仕様が公開されると確信できた時点で登録を承認してもよい。

Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register OAuth Authorization Server Metadata: example").

レビューのためにメーリングリストへ送る登録リクエストは、適切な件名 (例:「Request to register OAuth Authorization Server Metadata: example」) を使用するべきである。

Within the review period, the Designated Experts will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@ietf.org mailing list) for resolution.

レビュー期間内に、指定専門家は登録リクエストを承認または却下し、その決定をレビューリストと IANA に伝える。却下には説明を含め、該当する場合はリクエストを成功させる方法についての提案も含めるべきである。21 日を超えて未決定のままの登録リクエストは、解決のために (iesg@ietf.org メーリングリストを用いて) IESG の注意を喚起することができる。

Criteria that should be applied by the Designated Experts include determining whether the proposed registration duplicates existing functionality, determining whether it is likely to be of general applicability or whether it is useful only for a single application, and whether the registration makes sense.

指定専門家が適用すべき基準には、提案された登録が既存の機能と重複していないか、一般的に適用可能である可能性が高いか、それとも単一のアプリケーションにしか有用でないか、および登録が理にかなっているかの判断が含まれる。

IANA must only accept registry updates from the Designated Experts and should direct all requests for registration to the review mailing list.

IANA は指定専門家からのレジストリ更新のみを受け付けなければならず、登録のすべてのリクエストをレビューメーリングリストへ誘導するべきである。

It is suggested that multiple Designated Experts be appointed who are able to represent the perspectives of different applications using this specification, in order to enable broadly-informed review of registration decisions. In cases where a registration decision could be perceived as creating a conflict of interest for a particular Designated Expert, that Designated Expert should defer to the judgment of the other Designated Experts.

登録決定について幅広い知見に基づくレビューを可能にするため、本仕様を使用する異なるアプリケーションの視点を代表できる複数の指定専門家を任命することが推奨される。登録決定が特定の指定専門家にとって利益相反を生むと受け取られうる場合、その指定専門家は他の指定専門家の判断に委ねるべきである。

7.1.OAuth Authorization Server Metadata Registry

7.1.OAuth 認可サーバーメタデータレジストリ

This specification establishes the IANA "OAuth Authorization Server Metadata" registry for OAuth 2.0 authorization server metadata names. The registry records the authorization server metadata member and a reference to the specification that defines it.

本仕様は、OAuth 2.0 認可サーバーメタデータ名のための IANA「OAuth Authorization Server Metadata」レジストリを設立する。このレジストリは、認可サーバーメタデータのメンバーと、それを定義する仕様への参照を記録する。

The Designated Experts must either:

指定専門家は以下のいずれかを行わなければならない。

(a) require that metadata names and values being registered use only printable ASCII characters excluding double quote ('"') and backslash ('\') (the Unicode characters with code points U+0021, U+0023 through U+005B, and U+005D through U+007E), or

(a) 登録されるメタデータ名と値が、二重引用符 ('"') とバックスラッシュ ('\') を除く印字可能な ASCII 文字 (コードポイント U+0021、U+0023 から U+005B、および U+005D から U+007E の Unicode 文字) のみを使用することを要求する。または、

(b) if new metadata members or values are defined that use other code points, require that their definitions specify the exact sequences of Unicode code points used to represent them. Furthermore, proposed registrations that use Unicode code points that can only be represented in JSON strings as escaped characters must not be accepted.

(b) 他のコードポイントを使用する新しいメタデータメンバーや値が定義される場合、その定義がそれらを表現するために使用する Unicode コードポイントの正確な並びを規定することを要求する。さらに、JSON 文字列中でエスケープ文字としてしか表現できない Unicode コードポイントを使用する登録の提案は、受け付けてはならない。

7.1.1.Registration Template

7.1.1.登録テンプレート

Metadata Name: The name requested (e.g., "issuer"). This name is case-sensitive. Names may not match other registered names in a case-insensitive manner (one that would cause a match if the Unicode toLowerCase() operation were applied to both strings) unless the Designated Experts state that there is a compelling reason to allow an exception.

Metadata Name: 要求する名前 (例:「issuer」)。この名前は大文字小文字を区別する。名前は、指定専門家が例外を認める説得力のある理由があると表明しない限り、他の登録済みの名前と大文字小文字を区別しない形で (両方の文字列に Unicode の toLowerCase() 操作を適用した場合に一致するような形で) 一致してはならない。

Metadata Description: Brief description of the metadata (e.g., "Issuer identifier URL").

Metadata Description: メタデータの簡潔な説明 (例:「Issuer identifier URL」)。

Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.

Change Controller: Standards Track の RFC の場合は「IESG」と記載する。それ以外の場合は責任を負う当事者の名前を記載する。その他の詳細 (例: 郵便住所、メールアドレス、ホームページ URI) を含めてもよい。

Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.

Specification Document(s): パラメータを規定する 1 つ以上の文書への参照。できれば文書のコピーを取得するのに使える URI を含める。関連する節の指示を含めてもよいが、必須ではない。

7.1.2.Initial Registry Contents

7.1.2.レジストリの初期内容

o Metadata Name: issuer

o メタデータ名: issuer

o Metadata Description: Authorization server's issuer identifier URL

o メタデータの説明: 認可サーバーの発行者識別子 URL

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): Section 2 of RFC 8414

o 仕様文書: RFC 8414 の 2 節

o Metadata Name: authorization_endpoint

o メタデータ名: authorization_endpoint

o Metadata Description: URL of the authorization server's authorization endpoint

o メタデータの説明: 認可サーバーの認可エンドポイントの URL

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): Section 2 of RFC 8414

o 仕様文書: RFC 8414 の 2 節

o Metadata Name: token_endpoint

o メタデータ名: token_endpoint

o Metadata Description: URL of the authorization server's token endpoint

o メタデータの説明: 認可サーバーのトークンエンドポイントの URL

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): Section 2 of RFC 8414

o 仕様文書: RFC 8414 の 2 節

o Metadata Name: jwks_uri

o メタデータ名: jwks_uri

o Metadata Description: URL of the authorization server's JWK Set document

o メタデータの説明: 認可サーバーの JWK Set 文書の URL

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): Section 2 of RFC 8414

o 仕様文書: RFC 8414 の 2 節

o Metadata Name: registration_endpoint

o メタデータ名: registration_endpoint

o Metadata Description: URL of the authorization server's OAuth 2.0 Dynamic Client Registration Endpoint

o メタデータの説明: 認可サーバーの OAuth 2.0 動的クライアント登録エンドポイントの URL

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): Section 2 of RFC 8414

o 仕様文書: RFC 8414 の 2 節

o Metadata Name: scopes_supported

o メタデータ名: scopes_supported

o Metadata Description: JSON array containing a list of the OAuth 2.0 "scope" values that this authorization server supports

o メタデータの説明: この認可サーバーがサポートする OAuth 2.0 の "scope" 値のリストを含む JSON 配列

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): Section 2 of RFC 8414

o 仕様文書: RFC 8414 の 2 節

o Metadata Name: response_types_supported

o メタデータ名: response_types_supported

o Metadata Description: JSON array containing a list of the OAuth 2.0 "response_type" values that this authorization server supports

o メタデータの説明: この認可サーバーがサポートする OAuth 2.0 の "response_type" 値のリストを含む JSON 配列

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): Section 2 of RFC 8414

o 仕様文書: RFC 8414 の 2 節

o Metadata Name: response_modes_supported

o メタデータ名: response_modes_supported

o Metadata Description: JSON array containing a list of the OAuth 2.0 "response_mode" values that this authorization server supports

o メタデータの説明: この認可サーバーがサポートする OAuth 2.0 の "response_mode" 値のリストを含む JSON 配列

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): Section 2 of RFC 8414

o 仕様文書: RFC 8414 の 2 節

o Metadata Name: grant_types_supported

o メタデータ名: grant_types_supported

o Metadata Description: JSON array containing a list of the OAuth 2.0 grant type values that this authorization server supports

o メタデータの説明: この認可サーバーがサポートする OAuth 2.0 グラントタイプ値のリストを含む JSON 配列

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): Section 2 of RFC 8414

o 仕様文書: RFC 8414 の 2 節

o Metadata Name: token_endpoint_auth_methods_supported

o メタデータ名: token_endpoint_auth_methods_supported

o Metadata Description: JSON array containing a list of client authentication methods supported by this token endpoint

o メタデータの説明: このトークンエンドポイントがサポートするクライアント認証方式のリストを含む JSON 配列

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): Section 2 of RFC 8414

o 仕様文書: RFC 8414 の 2 節

o Metadata Name: token_endpoint_auth_signing_alg_values_supported

o メタデータ名: token_endpoint_auth_signing_alg_values_supported

o Metadata Description: JSON array containing a list of the JWS signing algorithms supported by the token endpoint for the signature on the JWT used to authenticate the client at the token endpoint

o メタデータの説明: トークンエンドポイントでクライアントを認証するために用いる JWT の署名について、トークンエンドポイントがサポートする JWS 署名アルゴリズムのリストを含む JSON 配列

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): Section 2 of RFC 8414

o 仕様文書: RFC 8414 の 2 節

o Metadata Name: service_documentation

o メタデータ名: service_documentation

o Metadata Description: URL of a page containing human-readable information that developers might want or need to know when using the authorization server

o メタデータの説明: 認可サーバーを利用する際に開発者が知りたい、あるいは知る必要があるかもしれない、人間が読める情報を含むページの URL

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): Section 2 of RFC 8414

o 仕様文書: RFC 8414 の 2 節

o Metadata Name: ui_locales_supported

o メタデータ名: ui_locales_supported

o Metadata Description: Languages and scripts supported for the user interface, represented as a JSON array of language tag values from BCP 47

o メタデータの説明: ユーザーインターフェースがサポートする言語と文字体系。BCP 47 の言語タグ値の JSON 配列として表現する

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): Section 2 of RFC 8414

o 仕様文書: RFC 8414 の 2 節

o Metadata Name: op_policy_uri

o メタデータ名: op_policy_uri

o Metadata Description: URL that the authorization server provides to the person registering the client to read about the authorization server's requirements on how the client can use the data provided by the authorization server

o メタデータの説明: 認可サーバーが提供するデータをクライアントがどのように利用できるかに関する認可サーバーの要件を読めるように、認可サーバーがクライアントを登録する人に提供する URL

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): Section 2 of RFC 8414

o 仕様文書: RFC 8414 の 2 節

o Metadata Name: op_tos_uri

o メタデータ名: op_tos_uri

o Metadata Description: URL that the authorization server provides to the person registering the client to read about the authorization server's terms of service

o メタデータの説明: 認可サーバーのサービス利用規約を読めるように、認可サーバーがクライアントを登録する人に提供する URL

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): Section 2 of RFC 8414

o 仕様文書: RFC 8414 の 2 節

o Metadata Name: revocation_endpoint

o メタデータ名: revocation_endpoint

o Metadata Description: URL of the authorization server's OAuth 2.0 revocation endpoint

o メタデータの説明: 認可サーバーの OAuth 2.0 失効エンドポイントの URL

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): Section 2 of RFC 8414

o 仕様文書: RFC 8414 の 2 節

o Metadata Name: revocation_endpoint_auth_methods_supported

o メタデータ名: revocation_endpoint_auth_methods_supported

o Metadata Description: JSON array containing a list of client authentication methods supported by this revocation endpoint

o メタデータの説明: この失効エンドポイントがサポートするクライアント認証方式のリストを含む JSON 配列

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): Section 2 of RFC 8414

o 仕様文書: RFC 8414 の 2 節

o Metadata Name: revocation_endpoint_auth_signing_alg_values_supported

o メタデータ名: revocation_endpoint_auth_signing_alg_values_supported

o Metadata Description: JSON array containing a list of the JWS signing algorithms supported by the revocation endpoint for the signature on the JWT used to authenticate the client at the revocation endpoint

o メタデータの説明: 失効エンドポイントでクライアントを認証するために用いる JWT の署名について、失効エンドポイントがサポートする JWS 署名アルゴリズムのリストを含む JSON 配列

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): Section 2 of RFC 8414

o 仕様文書: RFC 8414 の 2 節

o Metadata Name: introspection_endpoint

o メタデータ名: introspection_endpoint

o Metadata Description: URL of the authorization server's OAuth 2.0 introspection endpoint

o メタデータの説明: 認可サーバーの OAuth 2.0 イントロスペクションエンドポイントの URL

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): Section 2 of RFC 8414

o 仕様文書: RFC 8414 の 2 節

o Metadata Name: introspection_endpoint_auth_methods_supported

o メタデータ名: introspection_endpoint_auth_methods_supported

o Metadata Description: JSON array containing a list of client authentication methods supported by this introspection endpoint

o メタデータの説明: このイントロスペクションエンドポイントがサポートするクライアント認証方式のリストを含む JSON 配列

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): Section 2 of RFC 8414

o 仕様文書: RFC 8414 の 2 節

o Metadata Name: introspection_endpoint_auth_signing_alg_values_supported

o メタデータ名: introspection_endpoint_auth_signing_alg_values_supported

o Metadata Description: JSON array containing a list of the JWS signing algorithms supported by the introspection endpoint for the signature on the JWT used to authenticate the client at the introspection endpoint

o メタデータの説明: イントロスペクションエンドポイントでクライアントを認証するために用いる JWT の署名について、イントロスペクションエンドポイントがサポートする JWS 署名アルゴリズムのリストを含む JSON 配列

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): Section 2 of RFC 8414

o 仕様文書: RFC 8414 の 2 節

o Metadata Name: code_challenge_methods_supported

o メタデータ名: code_challenge_methods_supported

o Metadata Description: PKCE code challenge methods supported by this authorization server

o メタデータの説明: この認可サーバーがサポートする PKCE コードチャレンジ方式

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): Section 2 of RFC 8414

o 仕様文書: RFC 8414 の 2 節

o Metadata Name: signed_metadata

o メタデータ名: signed_metadata

o Metadata Description: Signed JWT containing metadata values about the authorization server as claims

o メタデータの説明: 認可サーバーに関するメタデータ値をクレームとして含む署名付き JWT

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): Section 2.1 of RFC 8414

o 仕様文書: RFC 8414 の 2.1 節

7.2.Updated Registration Instructions

7.2.登録手順の更新

This specification adds to the instructions for the Designated Experts of the following IANA registries, both of which are in the "OAuth Parameters" registry [IANA.OAuth.Parameters]:

本仕様は、以下の IANA レジストリの指定専門家向け手順に追記する。いずれも「OAuth Parameters」レジストリ [IANA.OAuth.Parameters] に含まれる。

o OAuth Access Token Types

o OAuth アクセストークンタイプ

o OAuth Token Endpoint Authentication Methods

o OAuth トークンエンドポイント認証方式

IANA has added a link to this specification in the Reference sections of these registries.

IANA はこれらのレジストリの Reference 欄に本仕様へのリンクを追加した。

For these registries, the Designated Experts must reject registration requests in one registry for values already occurring in the other registry. This is necessary because the "introspection_endpoint_auth_methods_supported" parameter allows for the use of values from either registry. That way, because the values in the two registries will continue to be mutually exclusive, no ambiguities will arise.

これらのレジストリについて、指定専門家は、一方のレジストリにすでに存在する値をもう一方のレジストリに登録するリクエストを却下しなければならない。これは「introspection_endpoint_auth_methods_supported」パラメータがどちらのレジストリの値の使用も許すために必要である。こうして 2 つのレジストリの値が互いに排他的であり続けることで、曖昧さが生じない。

7.3.Well-Known URI Registry

7.3.Well-Known URI レジストリ

This specification registers the well-known URI defined in Section 3 in the IANA "Well-Known URIs" registry [IANA.well-known] established by RFC 5785 [RFC5785].

本仕様は、3 節で定義した well-known URI を、RFC 5785 [RFC5785] によって設立された IANA「Well-Known URIs」レジストリ [IANA.well-known] に登録する。

7.3.1.Registry Contents

7.3.1.レジストリの内容

o URI suffix: oauth-authorization-server

o URI サフィックス: oauth-authorization-server

o Change controller: IESG

o 変更管理者: IESG

o Specification document: Section 3 of RFC 8414

o 仕様文書: RFC 8414 の 3 節

o Related information: (none)

o 関連情報: (なし)

8.References

8.参考資料

8.1.Normative References

8.1.引用規格

8.2.Informative References

8.2.参考文献

Acknowledgements

謝辞

This specification is based on the OpenID Connect Discovery 1.0 specification, which was produced by the OpenID Connect working group of the OpenID Foundation. This specification standardizes the de facto usage of the metadata format defined by OpenID Connect Discovery to publish OAuth authorization server metadata.

本仕様は、OpenID Foundation の OpenID Connect ワーキンググループが作成した OpenID Connect Discovery 1.0 仕様に基づいている。本仕様は、OpenID Connect Discovery で定義されたメタデータ形式を OAuth 認可サーバーメタデータの公開に用いるという事実上の用法を標準化するものである。

The authors would like to thank the following people for their reviews of this specification: Shwetha Bhandari, Ben Campbell, Brian Campbell, Brian Carpenter, William Denniss, Vladimir Dzhuvinov, Donald Eastlake, Samuel Erdtman, George Fletcher, Dick Hardt, Phil Hunt, Alexey Melnikov, Tony Nadalin, Mark Nottingham, Eric Rescorla, Justin Richer, Adam Roach, Hannes Tschofenig, and Hans Zandbelt.

著者らは、本仕様をレビューしてくれた以下の方々に感謝する: Shwetha Bhandari、Ben Campbell、Brian Campbell、Brian Carpenter、William Denniss、Vladimir Dzhuvinov、Donald Eastlake、Samuel Erdtman、George Fletcher、Dick Hardt、Phil Hunt、Alexey Melnikov、Tony Nadalin、Mark Nottingham、Eric Rescorla、Justin Richer、Adam Roach、Hannes Tschofenig、Hans Zandbelt。