OAuth 2.0 Client ID Scheme

3.1. Syntax

In the client_id Authorization Request parameter and other places where the Client Identifier is used, the Client Identifier Schemes are prefixed to the usual Client Identifier, separated by a : (colon) character:¶

<client_id_scheme>:<orig_client_id>

Here, <client_id_scheme> is the Client Identifier Scheme and <orig_client_id> is an identifier for the Client within the namespace of that scheme. See Section 3.4 for Client Identifier Schemes defined by this specification.¶

Authorization Servers MUST use the presence of a : (colon) character to determine whether a Client Identifier Scheme is used. If a : character is present, the Authorization Server MUST interpret the Client Identifier according to the Client Identifier Scheme, here defined as the string before the (first) : character. If the Authorization Server does not support the Client Identifier Scheme, the Authorization Server MUST refuse the request.¶

For example, an Authorization Request might contain client_id=client_attestation:example-client to indicate that the client_attestation Client Identifier Scheme is to be used and that within this scheme, the Client can be identified by the string example-client. The presentation would contain the full client_attestation:example-client string as the audience (intended receiver) and the same full string would be used as the Client Identifier anywhere in the OAuth flow.¶

Note that the Client needs to determine which Client Identifier Schemes the Authorization Server supports prior to sending the Authorization Request in order to choose a supported scheme.¶

3.2. Pre-Registered Clients

If a : character is not present in the Client Identifier, the Authorization Server MUST treat the Client Identifier as referencing a pre-registered client. This is equivalent to the [RFC6749] default behavior, i.e., the Client Identifier needs to be known to the Authorization Server in advance of the Authorization Request. The Client metadata is pre-registered using [RFC7591] or through out-of-band mechanisms.¶

For example, if an Authorization Request contains client_id=example-client, the Authorization Server would interprete the Client Identifier as referring to a pre-registered client.¶

From this definition, it follows that pre-registered clients MUST NOT contain a : character in their Client Identifier.¶

3.3. Pre-Existing Ecosystems using https

Existing deployments that use https URLs as client IDs and that have only one way to resolve client metadata from the URL, MAY use full https URL as the client ID. If there is only one way to resolve client metadata then there is no ambiguity.¶

For example, an authorization server using only the Client ID Metadata Document [I-D.draft-parecki-oauth-client-id-metadata-document] method to retrieve client metadata MAY accept client IDs such as:¶

https://client.example.com/metadata.json

This results in this non-normative example of an authorization request:¶

GET /authorize?
  response_type=code
  &client_id=https%3A%2F%2Fclient.example.org%2Fmetadata.json
  &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcallback
  &code_challenge=GdE4nqBrwRxQfN2Y8fq3rrYk_kkpwg6tQ74J94-2nHw
  &code_challenge_method=S256
  &scope=write

3.4. Defined Client Identifier Schemes

This specification defines the following Client Identifier Schemes, followed by the examples where applicable:¶

• redirect_uri: This value indicates that the Client Identifier (without the prefix redirect_uri:) is the Client's Redirect URI (or Response URI when Response Mode direct_post is used). The Authorization Request MUST NOT be signed. The Client MAY omit the redirect_uri Authorization Request parameter. Example Client Identifier: redirect_uri:https%3A%2F%2Fclient.example.org%2Fcb.¶

• federation: This value indicates that the Client Identifier is an Entity Identifier defined in OpenID Federation [OpenID.Federation]. Since the Entity Identifier is already defined to start with federation:, this Client Identifier Scheme MUST NOT be prefixed additionally. Processing rules given in [OpenID.Federation] MUST be followed. Automatic Registration as defined in [OpenID.Federation] MUST be used. The Authorization Request MAY also contain a trust_chain parameter. The final Client metadata is obtained from the Trust Chain after applying the policies, according to [OpenID.Federation]. Example Client Identifier: federation:https://federation-client.example.com.¶

• did: This value indicates that the Client Identifier is a DID defined in [DID-Core]. Since the DID URI is already defined to start with did:, this Client Identifier Scheme MUST NOT be prefixed additionally. The request MUST be signed with a private key associated with the DID. A public key to verify the signature MUST be obtained from the verificationMethod property of a DID Document. Since DID Document may include multiple public keys, a particular public key used to sign the request in question MUST be identified by the kid in the JOSE Header. To obtain the DID Document, the Authorization Server MUST use DID Resolution defined by the DID method used by the Client. Example Client Identifier: did:example:123#1.¶

• client_attestation: This Client Identifier Scheme allows the Client to authenticate using a JWT that is bound to a certain public key as defined in (OpenID4VP: Client Attestation). When the Client Identifier Scheme is client_attestation, the Client Identifier MUST equal the sub claim value in the Client attestation JWT. The request MUST be signed with the private key corresponding to the public key in the cnf claim in the Client attestation JWT. This serves as proof of possesion of this key. The Client attestation JWT MUST be added to the jwt JOSE Header of the request object (see (OpenID4VP: Client Attestation)). The Authorization Server MUST validate the signature on the Client attestation JWT. The iss claim value of the Client Attestation JWT MUST identify a party the Authorization Server trusts for issuing Client Attestation JWTs. If the Authorization Server cannot establish trust, it MUST refuse the request. If the issuer of the Client Attestation JWT adds a redirect_uris claim to the attestation, the Authorization Server MUST ensure the redirect_uri request parameter value exactly matches one of the redirect_uris claim entries. Example Client Identifier: client_attestation:client.example.¶

• x509_san_dns: When the Client Identifier Scheme is x509_san_dns, the Client Identifier MUST be a DNS name and match a dNSName Subject Alternative Name (SAN) [RFC5280] entry in the leaf certificate passed with the request. The request MUST be signed with the private key corresponding to the public key in the leaf X.509 certificate of the certificate chain added to the request in the x5c JOSE header [RFC7515] of the signed request object. The Authorization Server MUST validate the signature and the trust chain of the X.509 certificate. If the Authorization Server can establish trust in the Client Identifier authenticated through the certificate, e.g. because the Client Identifier is contained in a list of trusted Client Identifiers, it may allow the client to freely choose the redirect_uri value. If not, the FQDN of the redirect_uri value MUST match the Client Identifier without the prefix x509_san_dns:. Example Client Identifier: x509_san_dns:client.example.org.¶

• x509_san_uri: When the Client Identifier Scheme is x509_san_uri, the Client Identifier MUST be a URI and match a uniformResourceIdentifier Subject Alternative Name (SAN) [RFC5280] entry in the leaf certificate passed with the request. The request MUST be signed with the private key corresponding to the public key in the leaf X.509 certificate of the certificate chain added to the request in the x5c JOSE header [RFC7515] of the signed request object. The Authorization Server MUST validate the signature and the trust chain of the X.509 certificate. If the Authorization Server can establish trust in the Client Identifier authenticated through the certificate, e.g., because the Client Identifier is contained in a list of trusted Client Identifiers, it may allow the client to freely choose the redirect_uri value. If not, the redirect_uri value MUST match the Client Identifier without the prefix x509_san_uri:. Example Client Identifier: x509_san_uri:https://client.example.org/cb.¶

• https: This Client Identifier Scheme MUST NOT be registered.¶

7.1. Client Identifier Mixups

Confusing Clients using a Client Identifier Scheme with those using none can lead to attacks. Therefore, Authorization Servers MUST always use the full Client Identifier, including the prefix if provided, within the context of the Authorization Server or its responses to identify the client. This refers in particular to places where the Client Identifier is used in [RFC6749] as well as in any artifacts such as the aud claim of JWT access tokens [RFC9068].¶

9.1. Normative References

[DID-Core]

"DID Core", 19 July 2022, <https://www.w3.org/TR/did-core/>.

[OpenID.Federation]

Hedberg, R., Jones, M.B., Solberg, A.Å., Bradley, J., Marco, G. D., and V. Dzhuvinov, "OpenID Federation 1.0", 17 May 2024, <https://openid.net/specs/openid-federation-1_0.html>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/rfc/rfc5280>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

9.2. Informative References

[I-D.draft-parecki-oauth-client-id-metadata-document]

Parecki, A. and E. Smith, "OAuth Client ID Metadata Document", Work in Progress, Internet-Draft, draft-parecki-oauth-client-id-metadata-document-01, 8 July 2024, <https://datatracker.ietf.org/doc/html/draft-parecki-oauth-client-id-metadata-document-01>.

[OpenID]

Sakimura, N., Bradley, J., Jones, M., Medeiros, B. de., and C. Mortimore, "OpenID Connect Core 1.0", 15 December 2023, <https://openid.net/specs/openid-connect-core-1_0.html>.

[RFC7591]

Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, <https://www.rfc-editor.org/rfc/rfc7591>.

[RFC9068]

Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, <https://www.rfc-editor.org/rfc/rfc9068>.