NAT.Consulting

nat@nat.consulting https://nat.sakimura.org/

Yubico

ve7jtb@ve7jtb.com http://www.thread-safe.com/

Microsoft

mbj@microsoft.com https://self-issued.info/

OpenID Connect Working Group OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. This specification defines how an OpenID Connect Relying Party can dynamically register with the End-User's OpenID Provider, providing information about itself to the OpenID Provider, and obtaining information needed to use it, including the OAuth 2.0 Client ID for this Relying Party.

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner. In order for an OpenID Connect Relying Party to utilize OpenID Connect services for an End-User, the RP needs to register with the OpenID Provider to provide the OP information about itself and to obtain information needed to use it, including an OAuth 2.0 Client ID. This document describes how an RP can register with an OP, and how registration information for the RP can be retrieved.

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 RFC 2119. In the .txt version of this document, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes MUST NOT be used as part of the value. In the HTML version of this document, values to be taken literally are indicated by the use of this fixed-width font. All uses of JSON Web Signature (JWS) and JSON Web Encryption (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.

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, the terms "JSON Web Token (JWT)" and "Nested JWT" defined by JSON Web Token (JWT), the term "Base64url Encoding" defined by JSON Web Signature (JWS), and the terms defined by OpenID Connect Core 1.0. This specification defines the following additional terms: OAuth 2.0 Protected Resource through which a Client can be registered at an Authorization Server. OAuth 2.0 Endpoint through which registration information for a registered Client can be managed. This URL for this endpoint is returned by the Authorization Server in the Client Information Response. OAuth 2.0 Bearer Token issued by the Authorization Server through the Client Registration Endpoint that is used to authenticate the caller when accessing the Client's registration information at the Client Configuration Endpoint. This Access Token is associated with a particular registered Client. OAuth 2.0 Access Token optionally issued by an Authorization Server granting access to its Client Registration Endpoint. The contents of this token are service specific and are out of scope for this specification. The means by which the Authorization Server issues this token and the means by which the Registration Endpoint validates it are also out of scope. IMPORTANT NOTE TO READERS: The terminology definitions in this section are a normative portion of this specification, imposing requirements upon implementations. All the capitalized words in the text of this specification, such as "Client Registration Endpoint", reference these defined terms. Whenever the reader encounters them, their definitions found in this section must be followed.

Clients have metadata associated with their unique Client Identifier at the Authorization Server. These can range from human-facing display strings, such as a Client name, to items that impact the security of the protocol, such as the list of valid redirect URIs. The Client Metadata values are used in two ways: as input values to registration requests, and as output values in registration responses and read responses. These Client Metadata values are used by OpenID Connect: REQUIRED. Array of Redirection URI values used by the Client. One of these registered Redirection URI values MUST exactly match the redirect_uri parameter value used in each Authorization Request, with the matching performed as described in Section 6.2.1 of (Simple String Comparison). OPTIONAL. JSON array containing a list of the OAuth 2.0 response_type values that the Client is declaring that it will restrict itself to using. If omitted, the default is that the Client will use only the code Response Type. OPTIONAL. JSON array containing a list of the OAuth 2.0 Grant Types that the Client is declaring that it will restrict itself to using. The Grant Type values used by OpenID Connect are: authorization_code: The Authorization Code Grant Type described in OAuth 2.0 Section 4.1. implicit: The Implicit Grant Type described in OAuth 2.0 Section 4.2. refresh_token: The Refresh Token Grant Type described in OAuth 2.0 Section 6. The following table lists the correspondence between response_type values that the Client will use and grant_type values that MUST be included in the registered grant_types list: code: authorization_code id_token: implicit id_token token: implicit code id_token: authorization_code, implicit code token: authorization_code, implicit code id_token token: authorization_code, implicit If omitted, the default is that the Client will use only the authorization_code Grant Type. OPTIONAL. Kind of the application. The default, if omitted, is web. The defined values are native or web. Web Clients using the OAuth Implicit Grant Type MUST only register URLs using the https scheme as redirect_uris; they MUST NOT use localhost as the hostname. Native Clients MUST only register redirect_uris using custom URI schemes or URLs using the http: scheme with localhost as the hostname. Authorization Servers MAY place additional constraints on Native Clients. Authorization Servers MAY reject Redirection URI values using the http scheme, other than the localhost case for Native Clients. The Authorization Server MUST verify that all the registered redirect_uris conform to these constraints. This prevents sharing a Client ID across different types of Clients. OPTIONAL. Array of e-mail addresses of people responsible for this Client. This might be used by some providers to enable a Web user interface to modify the Client information. OPTIONAL. Name of the Client to be presented to the End-User. If desired, representation of this Claim in different languages and scripts is represented as described in . OPTIONAL. URL that references a logo for the Client application. If present, the server SHOULD display this image to the End-User during approval. The value of this field MUST point to a valid image file. If desired, representation of this Claim in different languages and scripts is represented as described in . OPTIONAL. URL of the home page of the Client. The value of this field MUST point to a valid Web page. If present, the server SHOULD display this URL to the End-User in a followable fashion. If desired, representation of this Claim in different languages and scripts is represented as described in . OPTIONAL. URL that the Relying Party Client provides to the End-User to read about how the profile data will be used. The value of this field MUST point to a valid web page. The OpenID Provider SHOULD display this URL to the End-User if it is given. If desired, representation of this Claim in different languages and scripts is represented as described in . OPTIONAL. URL that the Relying Party Client provides to the End-User to read about the Relying Party's terms of service. The value of this field MUST point to a valid web page. The OpenID Provider SHOULD display this URL to the End-User if it is given. If desired, representation of this Claim in different languages and scripts is represented as described in . OPTIONAL. URL for the Client's JWK Set document, which MUST use the https scheme. If the Client signs requests to the Server, it contains the signing key(s) the Server uses to validate signatures from the Client. The JWK Set MAY also contain the Client's encryption keys(s), which are used by the Server to encrypt responses to the Client. 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. Although some algorithms allow the same key to be used for both signatures and encryption, doing so is NOT RECOMMENDED, as it is less secure. The JWK x5c parameter MAY be used to provide X.509 representations of keys provided. When used, the bare key values MUST still be present and MUST match those in the certificate. The JWK Set MUST NOT contain private or symmetric key values. OPTIONAL. Client's JWK Set document, passed by value. The semantics of the jwks parameter are the same as the jwks_uri parameter, other than that the JWK Set is passed by value, rather than by reference. This parameter is intended only to be used by Clients that, for some reason, are unable to use the jwks_uri parameter, for instance, by native applications that might not have a location to host the contents of the JWK Set. If a Client can use jwks_uri, it MUST NOT use jwks. One significant downside of jwks is that it does not enable key rotation (which jwks_uri does, as described in Section 10 of OpenID Connect Core 1.0). The jwks_uri and jwks parameters MUST NOT be used together. The JWK Set MUST NOT contain private or symmetric key values. OPTIONAL. URL using the https scheme to be used in calculating Pseudonymous Identifiers by the OP. The URL references a file with a single JSON array of redirect_uri values. Please see . Providers that use pairwise sub (subject) values SHOULD utilize the sector_identifier_uri value provided in the Subject Identifier calculation for pairwise identifiers. OPTIONAL. subject_type requested for responses to this Client. The subject_types_supported discovery parameter contains a list of the supported subject_type values for the OP. Valid types include pairwise and public. OPTIONAL. JWS alg algorithm REQUIRED for signing the ID Token issued to this Client. The value none MUST NOT be used as the ID Token alg value unless the Client uses only Response Types that return no ID Token from the Authorization Endpoint (such as when only using the Authorization Code Flow). The default, if omitted, is RS256. The public key for validating the signature is provided by retrieving the JWK Set referenced by the jwks_uri element from OpenID Connect Discovery 1.0. OPTIONAL. JWE alg algorithm REQUIRED for encrypting the ID Token issued to this Client. If this is requested, the response will be signed then encrypted, with the result being a Nested JWT, as defined in . The default, if omitted, is that no encryption is performed. OPTIONAL. JWE enc algorithm REQUIRED for encrypting the ID Token issued to this Client. If id_token_encrypted_response_alg is specified, the default id_token_encrypted_response_enc value is A128CBC-HS256. When id_token_encrypted_response_enc is included, id_token_encrypted_response_alg MUST also be provided. OPTIONAL. JWS alg algorithm REQUIRED for signing UserInfo Responses. If this is specified, the response will be JWT serialized, and signed using JWS. The default, if omitted, is for the UserInfo Response to return the Claims as a UTF-8 encoded JSON object using the application/json content-type. OPTIONAL. JWE alg algorithm REQUIRED for encrypting UserInfo Responses. If both signing and encryption are requested, the response will be signed then encrypted, with the result being a Nested JWT, as defined in . The default, if omitted, is that no encryption is performed. OPTIONAL. JWE enc algorithm REQUIRED for encrypting UserInfo Responses. If userinfo_encrypted_response_alg is specified, the default userinfo_encrypted_response_enc value is A128CBC-HS256. When userinfo_encrypted_response_enc is included, userinfo_encrypted_response_alg MUST also be provided. OPTIONAL. JWS alg algorithm that MUST be used for signing Request Objects sent to the OP. All Request Objects from this Client MUST be rejected, if not signed with this algorithm. Request Objects are described in Section 6.1 of OpenID Connect Core 1.0. This algorithm MUST be used both when the Request Object is passed by value (using the request parameter) and when it is passed by reference (using the request_uri parameter). Servers SHOULD support RS256. The value none MAY be used. The default, if omitted, is that any algorithm supported by the OP and the RP MAY be used. OPTIONAL. JWE alg algorithm the RP is declaring that it may use for encrypting Request Objects sent to the OP. This parameter SHOULD be included when symmetric encryption will be used, since this signals to the OP that a client_secret value needs to be returned from which the symmetric key will be derived, that might not otherwise be returned. The RP MAY still use other supported encryption algorithms or send unencrypted Request Objects, even when this parameter is present. If both signing and encryption are requested, the Request Object will be signed then encrypted, with the result being a Nested JWT, as defined in . The default, if omitted, is that the RP is not declaring whether it might encrypt any Request Objects. OPTIONAL. JWE enc algorithm the RP is declaring that it may use for encrypting Request Objects sent to the OP. If request_object_encryption_alg is specified, the default request_object_encryption_enc value is A128CBC-HS256. When request_object_encryption_enc is included, request_object_encryption_alg MUST also be provided. OPTIONAL. Requested Client Authentication method for the Token Endpoint. The options are client_secret_post, client_secret_basic, client_secret_jwt, private_key_jwt, and none, as described in Section 9 of OpenID Connect Core 1.0. Other authentication methods MAY be defined by extensions. If omitted, the default is client_secret_basic -- the HTTP Basic Authentication Scheme specified in Section 2.3.1 of OAuth 2.0. OPTIONAL. JWS alg algorithm that MUST be used for signing the JWT used to authenticate the Client at the Token Endpoint for the private_key_jwt and client_secret_jwt authentication methods. All Token Requests using these authentication methods from this Client MUST be rejected, if the JWT is not signed with this algorithm. Servers SHOULD support RS256. The value none MUST NOT be used. The default, if omitted, is that any algorithm supported by the OP and the RP MAY be used. OPTIONAL. Default Maximum Authentication Age. Specifies that the End-User MUST be actively authenticated if the End-User was authenticated longer ago than the specified number of seconds. The max_age request parameter overrides this default value. If omitted, no default Maximum Authentication Age is specified. OPTIONAL. Boolean value specifying whether the auth_time Claim in the ID Token is REQUIRED. It is REQUIRED when the value is true. (If this is false, the auth_time Claim can still be dynamically requested as an individual Claim for the ID Token using the claims request parameter described in Section 5.5.1 of OpenID Connect Core 1.0.) If omitted, the default value is false. OPTIONAL. Default requested Authentication Context Class Reference values. Array of strings that specifies the default acr values that the OP is being requested to use for processing requests from this Client, with the values appearing in order of preference. The Authentication Context Class satisfied by the authentication performed is returned as the acr Claim Value in the issued ID Token. The acr Claim is requested as a Voluntary Claim by this parameter. The acr_values_supported discovery element contains a list of the supported acr values supported by the OP. Values specified in the acr_values request parameter or an individual acr Claim request override these default values. OPTIONAL. URI using the https scheme that a third party can use to initiate a login by the RP, as specified in Section 4 of OpenID Connect Core 1.0. The URI MUST accept requests via both GET and POST. The Client MUST understand the login_hint and iss parameters and SHOULD support the target_link_uri parameter. OPTIONAL. Array of request_uri values that are pre-registered by the RP for use at the OP. These URLs MUST use the https scheme unless the target Request Object is signed in a way that is verifiable by the OP. Servers MAY cache the contents of the files referenced by these URIs and not retrieve them at the time they are used in a request. OPs can require that request_uri values used be pre-registered with the require_request_uri_registration discovery parameter. If the contents of the request file could ever change, these URI values SHOULD include the base64url-encoded SHA-256 hash value of the file contents referenced by the URI as the value of the URI fragment. If the fragment value used for a URI changes, that signals the server that its cached value for that URI with the old fragment value is no longer valid. Additional Client Metadata parameters MAY also be used. Some are defined by other specifications, such as OpenID Connect RP-Initiated Logout 1.0.

Human-readable Client Metadata values and Client Metadata values that reference human-readable values MAY be represented in multiple languages and scripts. For example, values such as client_name, tos_uri, policy_uri, logo_uri, and client_uri might have multiple locale-specific values in some Client registrations. To specify the languages and scripts, BCP47 language tags are added to Client Metadata member names, delimited by a # character. The same syntax is used for representing languages and scripts for Client Metadata as is used for Claims, as described in Section 5.2 (Claims Languages and Scripts) of OpenID Connect Core 1.0. If such a human-readable field is sent without a language tag, parties using it MUST NOT make any assumptions about the language, character set, or script of the string value, and the string value MUST be used as-is wherever it is presented in a user interface. To facilitate interoperability, it is RECOMMENDED that any human-readable fields sent without language tags contain values suitable for display on a wide variety of systems.

The Client Registration Endpoint is an OAuth 2.0 Protected Resource through which a new Client registration can be requested. The OpenID Provider MAY require an Initial Access Token that is provisioned out-of-band (in a manner that is out of scope for this specification) to restrict registration requests to only authorized Clients or developers. The Client Registration Endpoint SHOULD support the use of Cross-Origin Resource Sharing (CORS) and/or other methods as appropriate to enable Java Script Clients to access it. To support open Dynamic Registration, the Client Registration Endpoint SHOULD accept registration requests without OAuth 2.0 Access Tokens. These requests MAY be rate-limited or otherwise limited to prevent a denial-of-service attack on the Client Registration Endpoint. If an Initial Access Token is required for Client registration, the Client Registration Endpoint MUST be able to accept these Access Tokens in the manner described in the OAuth 2.0 Bearer Token Usage specification.

To register a new Client at the Authorization Server, the Client sends an HTTP POST message to the Client Registration Endpoint with any Client Metadata parameters that the Client chooses to specify for itself during the registration. The Authorization Server assigns this Client a unique Client Identifier, optionally assigns a Client Secret, and associates the Metadata given in the request with the issued Client Identifier. The Authorization Server MAY provision default values for any items omitted in the Client Metadata. The Client sends an HTTP POST to the Client Registration Endpoint with a content type of application/json with the parameters represented as top-level members of the root JSON object.

The following is a non-normative example registration request (with line wraps within values for display purposes only):

Upon successful registration, the Client Registration Endpoint returns the newly-created Client Identifier and, if applicable, a Client Secret, along with all registered Metadata about this Client, including any fields provisioned by the Authorization Server itself. The Authorization Server MAY reject or replace any of the Client's requested field values, other than the redirect_uris value, and substitute them with suitable values. If this happens, the Authorization Server MUST include these fields in the response to the Client. An Authorization Server MAY ignore values provided by the client, and MUST ignore any fields sent by the Client that it does not understand. The response MAY contain a Registration Access Token that can be used by the Client to perform subsequent operations upon the resulting Client registration. A successful response SHOULD use the HTTP 201 Created status code and return a JSON document using the application/json content type with the following fields and the Client Metadata parameters as top-level members of the root JSON object: REQUIRED. Unique Client Identifier. It MUST NOT be currently valid for any other registered Client. OPTIONAL. Client Secret. The same Client Secret value MUST NOT be assigned to multiple Clients. This value is used by Confidential Clients to authenticate to the Token Endpoint, as described in Section 2.3.1 of OAuth 2.0, and for the derivation of symmetric encryption key values, as described in Section 10.2 of OpenID Connect Core 1.0. It is not needed for Clients selecting a token_endpoint_auth_method of private_key_jwt unless symmetric encryption will be used. OPTIONAL. Registration Access Token that can be used at the Client Configuration Endpoint to perform subsequent operations upon the Client registration. OPTIONAL. Location of the Client Configuration Endpoint where the Registration Access Token can be used to perform subsequent operations upon the resulting Client registration. This URL MUST use the https scheme. Implementations MUST either return both a Client Configuration Endpoint and a Registration Access Token or neither of them. OPTIONAL. Time at which the Client Identifier was issued. Its value is a JSON number representing the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time. REQUIRED if client_secret is issued. Time at which the client_secret will expire or 0 if it will not expire. Its value is a JSON number representing the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time.

The following is a non-normative example registration response (with line wraps within values for display purposes only):

When an OAuth error condition occurs, the Client Registration Endpoint returns an Error Response as defined in Section 3 of the OAuth 2.0 Bearer Token Usage specification. When a registration error condition occurs, the Client Registration Endpoint returns a HTTP 400 Bad Request status code including a JSON object describing the error in the response body. The JSON object describing the error contains two members: Error code. Additional text description of the error for debugging. Other members MAY also be used. This specification defines the following error codes: The value of one or more redirect_uris is invalid. The value of one of the Client Metadata fields is invalid and the server has rejected this request. Note that an Authorization Server MAY choose to substitute a valid value for any requested parameter of a Client's Metadata. Other error codes MAY also be used.

The following is a non-normative example error response:

The Client Configuration Endpoint is an OAuth 2.0 Protected Resource that MAY be provisioned by the server for a specific Client to be able to view and update its registered information. The Client MUST use its Registration Access Token in all calls to this endpoint as an OAuth 2.0 Bearer Token . The Client Configuration Endpoint SHOULD support the use of Cross-Origin Resource Sharing (CORS) and/or other methods as appropriate to enable Java Script Clients to access it. Operations on this endpoint are switched through the use of different HTTP methods . The only method defined for use at this endpoint by this specification is the HTTP GET method.

If a Client Configuration Endpoint and a Registration Access Token are returned by the initial registration of the Client, the Authorization Server MUST provide the Client with the fully qualified URL in the registration_client_uri element of the Client Registration Response, per . The Authorization Server MUST NOT expect the Client to construct or discover this URL on its own. The Client MUST use the URL as given by the server and MUST NOT construct this URL from component pieces. Depending on deployment characteristics, the Client Configuration Endpoint URL can take any number of forms. It is RECOMMENDED that this endpoint URL be formed through the use of a server-constructed URL string which combines the Client Registration Endpoint's URL and the issued Client ID for this Client, with the latter as either a path parameter or a query parameter. For example, a Client with the Client ID s6BhdRkqt3 could be given a Client Configuration Endpoint URL of https://server.example.com/register/s6BhdRkqt3 (path parameter) or of https://server.example.com/register?client_id=s6BhdRkqt3 (query parameter). In both of these cases, the Client simply uses the URL as given. These common patterns can help the Server to more easily determine the Client to which the request pertains, which MUST be matched against the Client to which the Registration Access Token was issued. If desired, the Server MAY simply return the Client Registration Endpoint URL as the Client Configuration Endpoint URL and change behavior based on the authentication context provided by the Registration Access Token.

If the initial registration of the Client returned a Client Configuration Endpoint and a Registration Access Token, the current configuration of the Client on the Authorization Server can be read by making an HTTP GET request to the Client Configuration Endpoint with the Registration Access Token. This operation SHOULD be idempotent -- not causing changes to the Client configuration.

The following is a non-normative example read request:

Upon a successful read operation, the Authorization Server SHOULD return all registered Metadata about this Client, including any fields provisioned by the Authorization Server itself. Note that some values, including the client_secret value, might have been updated since the initial registration. The mechanisms for such updates are beyond the scope of this specification. However, since Read operations are intended to be idempotent, the Client Read Request itself SHOULD NOT cause changes to the Client's registered Metadata values. The Authorization Server need not include the registration_access_token or registration_client_uri value in this response unless they have been updated. A successful response SHOULD use the HTTP 200 OK status code and return a JSON document using the application/json content type with the Client Metadata values as top-level members of the root JSON object.

The following is a non-normative example read response (with line wraps within values for display purposes only):

If the Registration Access Token used to make this request is not valid, the server MUST respond with an error as described in OAuth Bearer Token Usage. If the Client does not exist on this server, the Client is invalid, or the Registration Access Token used is invalid, the server MUST respond with the HTTP 401 Unauthorized status code. If the Client does not have permission to read its record, the server MUST return an HTTP 403 Forbidden. Note that for security reasons, to inhibit brute force attacks, endpoints MUST NOT return the HTTP 404 Not Found status code.

The following is a non-normative example error response:

The sector identifier list provides a way for a group of Web sites under single administrative control to have consistent pairwise sub values, independent of their domain names, as described in Section 8.1 of OpenID Connect Core 1.0. It also provides a way for Clients to change redirect_uri domains without having to re-register all of their users. The value of the sector_identifier_uri MUST be a URL using the https scheme that references a JSON file containing an array of redirect_uri values. The values registered in redirect_uris MUST be included in the elements of the array, or registration MUST fail. This MUST be validated at registration time; there is no requirement for the OP to retain the contents of this JSON file or to retrieve or revalidate its contents in the future.

The following is a non-normative example request to and reply from a sector_identifier_uri:

Processing some OpenID Connect messages requires comparing values in the messages to known values. For example, the member names in the Client registration response might be compared to specific member names such as client_id. Comparing Unicode strings, however, has significant security implications. Therefore, comparisons between JSON strings and other Unicode strings MUST be performed as specified below: Remove any JSON applied escaping to produce an array of Unicode code points. Unicode Normalization MUST NOT be applied at any point to either the JSON string or to the string it is to be compared against. Comparisons between the two strings MUST be performed as a Unicode code point to code point equality comparison.

If any of the validation procedures defined in this specification fail, any operations requiring the information that failed to correctly validate MUST be aborted and the information that failed to validate MUST NOT be used.

This specification defines features used by both Relying Parties and OpenID Providers that choose to implement Dynamic Client Registration. All of these Relying Parties and OpenID Providers MUST implement the features that are listed in this specification as being "REQUIRED" or are described with a "MUST". This specification is compatible with the OAuth 2.0 Dynamic Client Registration Protocol. Implementations MAY use additional Client Metadata values defined by , such as software_statement, should they facilitate their use cases. Implementations wanting to support additional operations defined in OAuth 2.0 Dynamic Client Registration Management Protocol, such as Update, can do so using that specification, while being mindful that the specification is experimental.

NOTE: Potential compatibility issues that were previously described in the original version of this specification have since been addressed.

In some deployments, it is advantageous to enable Clients to obtain the information necessary to interact with the Authorization Server, such as a Client Identifier, without the requirement that state about the Client be stored at the Authorization Server. The interfaces defined by this specification can be used for stateless dynamic client registration. One means of doing this is to encode necessary registration information about the Client into the client_id value returned by the initial registration of the Client. This has the effect of having the Client store this information, rather than the Authorization Server. The particular encodings used by different Authorization Servers will differ. When stateless dynamic client registration is used by the Authorization Server, read operations are likely to not be possible, because issuing a Registration Access Token might require per-Client state at the Authorization Server. In that case, no Client Configuration Endpoint or Registration Access Token will be returned by the initial registration of the Client.

Since requests to the Client Registration Endpoint result in the transmission of clear-text credentials (in the HTTP request and response), all communication with the Registration Endpoint MUST utilize TLS. See for more information on using TLS.

A rogue RP might use the logo for the legitimate RP, which it is trying to impersonate. An OP needs to take steps to mitigate this phishing risk, since the logo could confuse users into thinking they are logging in to the legitimate RP. An OP could also warn if the domain/site of the logo does not match the domain/site of registered Redirection URIs. An OP can also make warnings against untrusted RPs in all cases, especially if they are dynamically registered, have not been trusted by any users at the OP before, and want to use the logo feature. In a situation where the Authorization Server is supporting open Client registration, it needs to be extremely careful with any URL provided by the Client that will be displayed to the End-User (e.g. logo_uri and policy_uri). A rogue Client could specify a registration request with a reference to a drive-by download in the policy_uri. The Authorization Server SHOULD check to see if the logo_uri and policy_uri have the same host as the hosts defined in the array of redirect_uris.

Implementers should be aware that on iOS, information is returned to native applications using custom URI schemes, but multiple applications can register the same URI scheme. In this case, it is nondeterministic which application receives the information. This can result in an Authorization Code being leaked to the wrong application. Several possible solutions to this have been proposed and are being discussed in the IETF OAuth working group. It is expected that a standard solution to this problem will be developed there. At that point, an extension to OpenID Connect may be published describing how to apply that solution to OpenID Connect.

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. At the time of this writing, TLS version 1.2 is the most recent version, but has very limited actual deployment, and might not be readily available in implementation toolkits. TLS version 1.0 is the most widely deployed version, and will give the broadest interoperability. To protect against information disclosure and tampering, confidentiality protection MUST be applied using TLS with a ciphersuite that provides confidentiality and integrity protection. Whenever TLS is used, a TLS server certificate check MUST be performed, per RFC 6125.

This specification registers the following client metadata definitions in the IANA "OAuth Dynamic Client Registration Metadata" registry established by .

Client Metadata Name: application_type Client Metadata Description: Kind of the application -- "native" or "web" Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net Specification Document(s): of this document Client Metadata Name: sector_identifier_uri Client Metadata Description: URL using the https scheme to be used in calculating Pseudonymous Identifiers by the OP Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net Specification Document(s): of this document Client Metadata Name: subject_type Client Metadata Description: subject_type requested for responses to this Client -- "pairwise" or "public" Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net Specification Document(s): of this document Client Metadata Name: id_token_signed_response_alg Client Metadata Description: JWS alg algorithm REQUIRED for signing the ID Token issued to this Client Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net Specification Document(s): of this document Client Metadata Name: id_token_encrypted_response_alg Client Metadata Description: JWE alg algorithm REQUIRED for encrypting the ID Token issued to this Client Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net Specification Document(s): of this document Client Metadata Name: id_token_encrypted_response_enc Client Metadata Description: JWE enc algorithm REQUIRED for encrypting the ID Token issued to this Client Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net Specification Document(s): of this document Client Metadata Name: userinfo_signed_response_alg Client Metadata Description: JWS alg algorithm REQUIRED for signing UserInfo Responses Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net Specification Document(s): of this document Client Metadata Name: userinfo_encrypted_response_alg Client Metadata Description: JWE alg algorithm REQUIRED for encrypting UserInfo Responses Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net Specification Document(s): of this document Client Metadata Name: userinfo_encrypted_response_enc Client Metadata Description: JWE enc algorithm REQUIRED for encrypting UserInfo Responses Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net Specification Document(s): of this document Client Metadata Name: request_object_signing_alg Client Metadata Description: JWS alg algorithm that MUST be used for signing Request Objects sent to the OP Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net Specification Document(s): of this document Client Metadata Name: request_object_encryption_alg Client Metadata Description: JWE alg algorithm the RP is declaring that it may use for encrypting Request Objects sent to the OP Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net Specification Document(s): of this document Client Metadata Name: request_object_encryption_enc Client Metadata Description: JWE enc algorithm the RP is declaring that it may use for encrypting Request Objects sent to the OP Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net Specification Document(s): of this document Client Metadata Name: token_endpoint_auth_signing_alg Client Metadata Description: JWS alg algorithm that MUST be used for signing the JWT used to authenticate the Client at the Token Endpoint for the private_key_jwt and client_secret_jwt authentication methods Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net Specification Document(s): of this document Client Metadata Name: default_max_age Client Metadata Description: Default Maximum Authentication Age Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net Specification Document(s): of this document Client Metadata Name: require_auth_time Client Metadata Description: Boolean value specifying whether the auth_time Claim in the ID Token is REQUIRED Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net Specification Document(s): of this document Client Metadata Name: default_acr_values Client Metadata Description: Default requested Authentication Context Class Reference values Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net Specification Document(s): of this document Client Metadata Name: initiate_login_uri Client Metadata Description: URI using the https scheme that a third party can use to initiate a login by the RP Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net Specification Document(s): of this document Client Metadata Name: request_uris Client Metadata Description: Array of request_uri values that are pre-registered by the RP for use at the OP Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net Specification Document(s): of this document

This specification registers the following token endpoint authentication methods in the IANA "OAuth Token Endpoint Authentication Methods" registry established by :

Token Endpoint Authentication Method Name: client_secret_jwt Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net Specification Document(s): Section 9 of OpenID Connect Core 1.0 Token Endpoint Authentication Method Name: private_key_jwt Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net Specification Document(s): Section 9 of OpenID Connect Core 1.0

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies Version 1.0 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This memo provides information for the Internet community. This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions. [STANDARDS-TRACK] The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK] JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.

markdavis@google.com

ken@unicode.org

NAT.Consulting Yubico Microsoft Google Disney NAT.Consulting Yubico Microsoft Illumila Microsoft Microsoft Ping Identity Nomura Research Institute, Ltd. Microsoft Ping Identity Nomura Research Institute, Ltd. Microsoft RTFM, Inc. Cisco Systems, Inc. Microsoft The Unicode Consortium

IANA Opera Software ASA This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. This specification defines methods for management of OAuth 2.0 dynamic client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Not all authorization servers supporting dynamic client registration will support these management methods. Microsoft Google Microsoft NAT.Consulting Yubico

The OpenID Community would like to thank the following people for their contributions to this specification: Amanda Anganes (aanganes@mitre.org), MITRE John Bradley (ve7jtb@ve7jtb.com), Yubico (was at Ping Identity) Brian Campbell (bcampbell@pingidentity.com), Ping Identity Vladimir Dzhuvinov (vladimir@connect2id.com), Connect2id (was at Nimbus Directory Services) George Fletcher (gffletch@aol.com), Capital One (was at AOL) Roland Hedberg (roland@catalogix.se), Independent (was at University of Umeå) Edmund Jay (ejay@mgi1.com), Illumila Michael B. Jones (mbj@microsoft.com), Microsoft Torsten Lodderstedt (torsten@lodderstedt.net), yes.com (was at Deutsche Telekom) Justin Richer (justin@bspk.io), Bespoke Engineering (was at MITRE) Nat Sakimura (nat@nat.consulting), NAT.Consulting (was at NRI)

Copyright (c) 2022 The OpenID Foundation. The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF. The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.

[[ To be removed from the approved errata ]] -35 Fixed #1251 - Referenced JWS definition of Base64url Encoding. Fixed #980 - Specified the use of CORS at additional endpoints. -34 Updated logout spec references. Updated contributor affiliations. -33 Updated contributor affiliations. Updated many spec URLs from http to https. -32 Replaced Session Management example with RP-Initiated Logout, since Session Management no longer registers client metadata. Updated affiliations and acknowledgements. -31 Fixed #995 - Editorial Issue: description of policy_uri in DynReg. Fixed #1007 - jwks / jwks_uri must not contain private key material. Fixed #1016 - Specified that the server cannot change the redirect_uris value. -30 Specified that some URLs MUST use the https scheme. Replaced token id_token with id_token token. -29 Referenced completed RFCs. Added missing URLs in references. Fixed issue #971 - Clarified default *_encrypted_response_enc and request_object_encryption_enc values. Changed to use "Cache-Control: no-cache, no-store" and "Pragma: no-cache" in examples. Tracked terminology changes made in the referenced IETF specs since errata set 1. Updated the RFC 2616 reference to RFC 7231. Registered the client metadata definitions and token endpoint authentication methods not registered by RFC 7591 in the registries established by RFC 7591. -28 Final specification incorporating errata set 1.