OAuth 2.0 Attestation-Based Client Authentication

5.1. Client Attestation PoP JWT

The Client Attestation PoP MUST be encoded as a "JSON Web Token (JWT)" according to [RFC7519].¶

The following content applies to the JWT Header:¶

• typ: REQUIRED. The typ (JWT type) header MUST be oauth-client-attestation-pop+jwt.¶

• alg: REQUIRED. The alg (algorithm) header MUST specify the cryptographic algorithm used to sign the Client Attestation PoP¶

The following content applies to the JWT Claims Set:¶

• aud: REQUIRED. The aud (audience) claim MUST specify a value that identifies the intended audience of the JWT. When the JWT is presented to an Authorization Server, the [RFC8414] issuer identifier URL of the Authorization Server MUST be used. When the JWT is presented to a Resource Server, the [RFC9728] resource identifier URL of the Resource Server MUST be used. A Client Attestation PoP JWT is intended for a single audience, Clients MUST generate JWTs for each target.¶

• jti: REQUIRED. The jti (JWT identifier) claim MUST specify a unique identifier for the Client Attestation PoP. The Authorization Server or Resource Server can utilize the jti value for replay attack detection, see Section 11.1.¶

• iat: REQUIRED. The iat (issued at) claim MUST specify the time at which the Client Attestation PoP was issued. Note that the Authorization Server or Resource Server may reject JWTs with an "iat" claim value that is unreasonably far in the past.¶

• challenge: OPTIONAL. The challenge (challenge) claim MUST specify a String value that is provided by the Authorization Server or Resource Server for the client to include in the Client Attestation PoP JWT.¶

The following additional rules apply:¶

1. The JWT MAY contain other claims. All claims that are not understood by implementations MUST be ignored.¶

2. The JWT MUST be digitally signed using an asymmetric cryptographic algorithm. The Authorization Server or Resource Server MUST reject JWTs with an invalid signature.¶

3. The public key used to verify the JWT MUST be the key located in the "cnf" claim of the corresponding Client Attestation JWT.¶

4. The Authorization Server or Resource Server MUST reject a JWT that is not valid in all other respects per "JSON Web Token (JWT)" [RFC7519].¶

The following example is the decoded header and payload of a JWT meeting the processing rules as defined above.¶

{
  "typ": "oauth-client-attestation-pop+jwt",
  "alg": "ES256"
}
.
{
  "aud": "https://as.example.com",
  "jti": "d25d00ab-552b-46fc-ae19-98f440f25064",
  "iat": 1772487595,
  "challenge": "5c1a9e10-29ff-4c2b-ae73-57c0957c09c4"
}

When using headers to transfer the Client Attestation PoP JWT to an Authorization Server or Resource Server, it MUST be provided in an HTTP request using the HTTP header field OAuth-Client-Attestation-PoP.¶

The following is an example of the OAuth-Client-Attestation-PoP header.¶

OAuth-Client-Attestation-PoP: eyJ0eXAiOiJvYXV0aC1jbGllbnQtYXR0ZXN0YXRp
b24tcG9wK2p3dCIsImFsZyI6IkVTMjU2In0.eyJhdWQiOiJodHRwczovL2FzLmV4YW1wb
GUuY29tIiwianRpIjoiZDI1ZDAwYWItNTUyYi00NmZjLWFlMTktOThmNDQwZjI1MDY0Ii
wiaWF0IjoxNzcyNDg3NTk1LCJjaGFsbGVuZ2UiOiI1YzFhOWUxMC0yOWZmLTRjMmItYWU
3My01N2MwOTU3YzA5YzQifQ.M4Uc4rWVAqaLlmDDUXQKkKPbAQKj0JrTizLgWhZndmbkv
M3VL8y-w_QJr7Z0HZlH94E64cLa8L5fSjJItYv0jg

Note that per [RFC9110] header field names are case-insensitive; so OAUTH-CLIENT-ATTESTATION-POP, oauth-client-attestation-pop, etc., are all valid and equivalent header field names. Case is significant in the header field value, however.¶

The OAuth-Client-Attestation-PoP HTTP header field value uses the token68 syntax defined in Section 11.2 of [RFC9110] (repeated below for ease of reference).¶

OAuth-Client-Attestation-PoP   = token68
token68                        = 1*( ALPHA / DIGIT / "-" / "." /
                                     "_" / "~" / "+" / "/" ) *"="

5.2. Using DPoP as the Proof of Possession

This section defines an optimization that allows a single Proof of Possession (PoP) JWT to satisfy the role of both (a) the Client Attestation PoP defined in this specification and (b) the DPoP proof defined in [RFC9449] for sender-constrained access tokens. In this "combined mode" the Client Instance Key and the DPoP Key are the same asymmetric key pair, and a request using the mechanism carries only one PoP, the DPoP proof, instead of two separate PoP JWTs (the DPoP proof and Client Attestation PoP JWT).¶

Note when authorization code binding as defined in Section 10 of [RFC9449] is used, this mode only works with the DPoP Proof header containing a proof of possession and not dpop_jkt. When using dpop_jkt, the normal mode has to be used.¶

Note that DPoP [RFC9449] can also be used alongside the Client Attestation PoP JWT without this combined mode. In this case, the DPoP proof is validated according to [RFC9449] independently of this specification and its public key is not required to match the key in the cnf claim of the Client Attestation JWT (see Section 7).¶

The following rules apply to the DPoP proof as defined in [RFC9449]:¶

1. The DPoP proof MUST adhere to [RFC9449]¶

2. The public key located in the DPoP proof MUST match the public key located in the cnf claim of the Client Attestation JWT.¶

The following non-normative example shows a token request using combined mode (line breaks for display only):¶

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
OAuth-Client-Attestation: <Client-Attestation-JWT>
DPoP: <Combined-DPoP-And-Attestation-PoP-JWT>

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA

Decoded (non-normative) DPoP (combined) proof - Header:¶

{
  "typ": "dpop+jwt",
  "alg": "ES256",
  "jwk": {
    "kty": "EC",
    "crv": "P-256",
    "x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM",
    "y": "-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA"
  }
}

Payload:¶

{
  "htm": "POST",
  "htu": "https://as.example.com/token",
  "iat": 1700000000,
  "jti": "7c20c3e2-0f52-4f74-81a5-5c7b83a7a1f9"
}

Note that additional claims may be present in the DPoP proof depending on the context, as required by [RFC9449].¶

6.1. Providing Challenges through the Challenge Endpoint

The Authorization Server or Resource Server MAY offer a challenge endpoint for Clients to fetch Challenges in the context of this specification. If the Authorization Server supports metadata as defined in [RFC8414] or the Resource Server supports metadata as defined in [RFC9728], it MUST signal support for the challenge endpoint by including the metadata entry challenge_endpoint containing the URL of the endpoint as its value. If the Authorization Server offers a challenge endpoint, the Client MUST retrieve a challenge and MUST use this challenge in the Client Attestation PoP JWT or DPoP Proof as defined in Section 5.¶

A request for a Challenge is made by sending an HTTP POST request to the URL provided in the challenge_endpoint parameter of the Authorization Server metadata. The following is a non-normative example of a request:¶

POST /as/challenge HTTP/1.1
Host: as.example.com
Accept: application/json

The Authorization Server or Resource Server provides a Challenge in the HTTP response with a 200 status code and the following parameters included in the message body of the HTTP response using the application/json media type:¶

• attestation_challenge: REQUIRED if the Authorization Server or Resource Server supports Client Attestations and server-provided challenges as described in this document. String containing a Challenge to be used in the Client Attestation PoP JWT or DPoP Proof as defined in Section 5. The intention of this element not being required in other circumstances is to preserve the ability for the challenge endpoint to be used in other applications unrelated to client attestations.¶

The Authorization Server or Resource Server MUST make the response uncacheable by adding a Cache-Control header field including the value no-store. The Authorization Server or Resource Server MAY add additional challenges or data.¶

The following is a non-normative example of a response:¶

HTTP/1.1 200 OK
Host: as.example.com
Content-Type: application/json
Cache-Control: no-store

{
  "attestation_challenge": "AYjcyMzY3ZDhiNmJkNTZ"
}

6.2. Providing Challenges on Previous Responses

The Authorization Server or Resource Server MAY provide a fresh Challenge with any HTTP response using a HTTP header-based syntax. The HTTP header field parameter MUST be named "OAuth-Client-Attestation-Challenge" and contain the value of the Challenge. The Client MUST use this new Challenge for the next OAuth-Client-Attestation-PoP.¶

The following is a non-normative example of an Authorization Response containing a fresh Challenge:¶

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
OAuth-Client-Attestation-Challenge: AYjcyMzY3ZDhiNmJkNTZ

{
  "access_token": "2YotnFZFEjr1zCsicMWpAA",
  "token_type": "Bearer",
  "expires_in": 3600
}

7.1. Client Attestation JWT

To validate a Client Attestation, the receiving server MUST ensure the following conditions and rules are met:¶

1. There is precisely one OAuth-Client-Attestation HTTP request header field containing a Client Attestation JWT.¶

2. The Client Attestation JWT contains all required claims and header parameters as per Section 4.¶

3. The alg JOSE Header Parameter contains a registered algorithm [IANA.JOSE.ALGS], is not none, is supported by the application, and is acceptable per local policy.¶

4. The signature of the Client Attestation JWT verifies with the public key of a known and trusted Client Attester.¶

5. The key contained in the cnf claim of the Client Attestation JWT is not a private key.¶

6. The Client Attestation JWT is fresh enough per local policy of the Authorization Server or Resource Server by checking the iat or exp claims.¶

7. If a client_id is provided in the request containing the Client Attestation, then this client_id matches the sub claim of the Client Attestation JWT.¶

7.2. Client Attestation PoP JWT

This section applies when the Client Attestation PoP JWT is used as the Proof of Possession. When operating in DPoP combined mode as defined in Section 5.2, this section does not apply; instead, see Section 7.3.¶

To validate a Client Attestation PoP, the receiving server MUST ensure the following conditions and rules are met:¶

1. There is precisely one OAuth-Client-Attestation-PoP HTTP request header field containing a Client Attestation PoP JWT.¶

2. The Client Attestation PoP JWT contains all required claims and header parameters as per Section 5.1.¶

3. The alg JOSE Header Parameter contains a registered algorithm [IANA.JOSE.ALGS], is not none, is supported by the application, and is acceptable per local policy.¶

4. The signature of the Client Attestation PoP JWT verifies with the public key contained in the cnf claim of the Client Attestation JWT.¶

5. If the server provided a challenge value to the client, the challenge claim is present in the Client Attestation PoP JWT and matches the server-provided challenge value.¶

6. The creation time of the Client Attestation PoP JWT as determined by either the iat claim or a server managed timestamp via the challenge claim, is within an acceptable window per local policy of the Authorization Server or Resource Server.¶

7. The audience claim in the Client Attestation PoP JWT identifies the receiving server: when validated by an Authorization Server, it MUST be the issuer identifier URL of the Authorization Server as described in [RFC8414]; when validated by a Resource Server, it MUST be the resource identifier URL of the Resource Server as described in [RFC9728].¶

8. If the Client received a challenge through the Authorization Server's challenge endpoint or within previous responses as described in Section 6, it MUST match the challenge claim of the Client Attestation PoP JWT.¶

9. Depending on the security requirements of the deployment, additional checks to guarantee replay protection for the Client Attestation PoP JWT might need to be applied (see Section 11.1 for more details).¶

7.3. DPoP Combined Mode

This section applies when the DPoP combined mode is used as defined in Section 5.2. When the Client Attestation PoP JWT is used as the Proof of Possession instead, this section does not apply; see Section 7.2.¶

To validate a request using DPoP combined mode, the receiving server MUST perform the following steps:¶

1. There is no OAuth-Client-Attestation-PoP HTTP request header field present in the request.¶

2. There is precisely one DPoP HTTP request header field present in the request.¶

3. Validate the DPoP proof in accordance with [RFC9449].¶

4. The public key in the jwk header parameter of the DPoP proof MUST be identical to the public key in the cnf claim of the Client Attestation JWT.¶

5. If the Client received a challenge through the Authorization Server's challenge endpoint or within previous responses as described in Section 6, it MUST match the nonce payload claim of the DPoP proof.¶

7.4. Errors

When validation errors specifically related to the use of client attestations are encountered the following additional error codes are defined for use in either Authorization Server authenticated endpoint error responses (as defined in Section 5.2 of [RFC6749]) or Resource Server error responses (as defined in Section 3 of [RFC6750]).¶

• use_attestation_challenge MUST be used when the Client Attestation PoP JWT is not using an expected server-provided challenge. When used this error code MUST be accompanied by the OAuth-Client-Attestation-Challenge HTTP header field parameter (as described in Section 6.2).¶

• use_fresh_attestation MUST be used when the Client Attestation JWT is deemed to be not fresh enough to be acceptable by the server.¶

• invalid_client_attestation MAY be used in addition to the more general invalid_client error code as defined in [RFC6749] if the attestation or its proof of possession could not be successfully verified, the proof of possession is not supported.¶

In the event of errors due to situations not described above, Authorization and Resource Servers MUST follow the guidance of [RFC6749] and [RFC6750] or their respective extensions of when to return suitable Error Responses.¶

7.5. Client Attestation as an OAuth Client Authentication

A Client Attestation may be used as an OAuth 2 Client Authentication mechanism as described in Section 2.3 of [RFC6749] towards an Authorization Server. If the token request contains a client_id parameter as per [RFC6749] the Authorization Server MUST verify that the value of this parameter is the same as the client_id value in the sub claim of the Client Attestation.¶

The following example demonstrates usage of the client attestation mechanism in an access token request (with extra line breaks for display purposes only):¶

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
OAuth-Client-Attestation: eyJ0eXAiOiJvYXV0aC1jbGllbnQtYXR0ZXN0YXRpb24
rand0IiwiYWxnIjoiRVMyNTYiLCJraWQiOiIxMSJ9.eyJzdWIiOiJodHRwczovL2NsaWV
udC5leGFtcGxlLmNvbSIsImlhdCI6MTc3MjQ4NzU5NSwiZXhwIjoyNTI5ODY2Mzk0LCJj
bmYiOnsiandrIjp7Imt0eSI6IkVDIiwidXNlIjoic2lnIiwiY3J2IjoiUC0yNTYiLCJ4I
joiVmNLVk5CWjRJYUJBWVczanhNNHczVEpGVkE3bXllVUdReUd0LWdfeXZwUSIsInkiOi
JmLUUtaFlFM1RBV0t3aFZ2OXBlajlOQUJzOVNYOVhzTk84MHg1N2pGVHlVIn19fQ._TS4
d-LAnRlwdN97wiVnl4z7C9gvm45IWr-BvGTzeZaHtZtgNZ88gvzroU3LElUPbgF4kWi_D
FORnKzsx5yu6A
OAuth-Client-Attestation-PoP: eyJ0eXAiOiJvYXV0aC1jbGllbnQtYXR0ZXN0YXRp
b24tcG9wK2p3dCIsImFsZyI6IkVTMjU2In0.eyJhdWQiOiJodHRwczovL2FzLmV4YW1wb
GUuY29tIiwianRpIjoiZDI1ZDAwYWItNTUyYi00NmZjLWFlMTktOThmNDQwZjI1MDY0Ii
wiaWF0IjoxNzcyNDg3NTk1LCJjaGFsbGVuZ2UiOiI1YzFhOWUxMC0yOWZmLTRjMmItYWU
3My01N2MwOTU3YzA5YzQifQ.M4Uc4rWVAqaLlmDDUXQKkKPbAQKj0JrTizLgWhZndmbkv
M3VL8y-w_QJr7Z0HZlH94E64cLa8L5fSjJItYv0jg

grant_type=authorization_code&
code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4

7.6. Client Attestation as an additional security signal

A Client Attestation may be used as a (additional) security signal towards an Authorization Server or Resource Server. This may provide additional assurance about the client's authenticity, integrity, state or other information contained in the Client Attestation. When used at the Authorization Server, the Client Attestation may appear alongside existing OAuth 2 Client Authentication mechanisms.¶

An Authorization Server or Resource Server MAY signal a requirement to Clients for presenting a Client Attestation and its Proof of Possession as an additional security signal alongside the regular request. A server signals this demand by including the client_attestation_pop_methods_supported metadata parameter in its published metadata, as defined in [RFC8414] for the Authorization Server and in [RFC9728] for the Resource Server. The value of client_attestation_pop_methods_supported is a JSON array of case-sensitive strings, each identifying a Proof of Possession method that the server accepts, as registered in the "OAuth Client Attestation Proof-of-Possession Methods" registry established by this specification (see Section 13.5). A server MUST NOT include a method it does not accept, and the array MUST NOT be empty when the parameter is present.¶

When the parameter is omitted, presenting a Client Attestation as an additional security signal is OPTIONAL. When the parameter includes none, the Client MAY omit the Client Attestation. If the Client sends a Client Attestation, it MUST use one of the supported Proof of Possession methods. For example, for "client_attestation_pop_methods_supported": ["dpop_combined", "none"], the server accepts requests without a Client Attestation as well as requests carrying a Client Attestation with a DPoP proof as the Proof of Possession. When the parameter is present and does not include none, a Client SHOULD include the Client Attestation and its Proof of Possession in its requests to that server, and the Client MUST use one of the listed Proof of Possession methods.¶

This specification registers the following Proof of Possession methods:¶

• attestation_pop_jwt: The Proof of Possession is a dedicated Client Attestation PoP JWT as defined in Section 5.1 ("normal mode").¶

• dpop_combined: The Proof of Possession is a DPoP proof serving as the combined Proof of Possession as defined in Section 5.2 ("DPoP combined mode").¶

• none: No Client Attestation is required. A server includes this value to signal that the Client MAY omit the Client Attestation.¶

The following example demonstrates usage of the client attestation mechanism in a PAR request as defined in [RFC9126] alongside client_secret (with extra line breaks for display purposes only):¶

POST /as/par HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
OAuth-Client-Attestation: eyJ0eXAiOiJvYXV0aC1jbGllbnQtYXR0ZXN0YXRpb24
rand0IiwiYWxnIjoiRVMyNTYiLCJraWQiOiIxMSJ9.eyJzdWIiOiJodHRwczovL2NsaWV
udC5leGFtcGxlLmNvbSIsImlhdCI6MTc3MjQ4NzU5NSwiZXhwIjoyNTI5ODY2Mzk0LCJj
bmYiOnsiandrIjp7Imt0eSI6IkVDIiwidXNlIjoic2lnIiwiY3J2IjoiUC0yNTYiLCJ4I
joiVmNLVk5CWjRJYUJBWVczanhNNHczVEpGVkE3bXllVUdReUd0LWdfeXZwUSIsInkiOi
JmLUUtaFlFM1RBV0t3aFZ2OXBlajlOQUJzOVNYOVhzTk84MHg1N2pGVHlVIn19fQ._TS4
d-LAnRlwdN97wiVnl4z7C9gvm45IWr-BvGTzeZaHtZtgNZ88gvzroU3LElUPbgF4kWi_D
FORnKzsx5yu6A
OAuth-Client-Attestation-PoP: eyJ0eXAiOiJvYXV0aC1jbGllbnQtYXR0ZXN0YXRp
b24tcG9wK2p3dCIsImFsZyI6IkVTMjU2In0.eyJhdWQiOiJodHRwczovL2FzLmV4YW1wb
GUuY29tIiwianRpIjoiZDI1ZDAwYWItNTUyYi00NmZjLWFlMTktOThmNDQwZjI1MDY0Ii
wiaWF0IjoxNzcyNDg3NTk1LCJjaGFsbGVuZ2UiOiI1YzFhOWUxMC0yOWZmLTRjMmItYWU
3My01N2MwOTU3YzA5YzQifQ.M4Uc4rWVAqaLlmDDUXQKkKPbAQKj0JrTizLgWhZndmbkv
M3VL8y-w_QJr7Z0HZlH94E64cLa8L5fSjJItYv0jg

response_type=code
&state=af0ifjsldkj
&client_id=s6BhdRkqt3
&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U
&code_challenge_method=S256&scope=account-information

The following example demonstrates usage of the client attestation mechanism at the Resource Server (with extra line breaks for display purposes only):¶

POST /api/users/list HTTP/1.1
Host: rs.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Bearer mF_9.B5f-4.1JqM
Accept: application/json
OAuth-Client-Attestation: eyJ0eXAiOiJvYXV0aC1jbGllbnQtYXR0ZXN0YXRpb24
rand0IiwiYWxnIjoiRVMyNTYiLCJraWQiOiIxMSJ9.eyJzdWIiOiJodHRwczovL2NsaWV
udC5leGFtcGxlLmNvbSIsImlhdCI6MTc3MjQ4NzU5NSwiZXhwIjoyNTI5ODY2Mzk0LCJj
bmYiOnsiandrIjp7Imt0eSI6IkVDIiwidXNlIjoic2lnIiwiY3J2IjoiUC0yNTYiLCJ4I
joiVmNLVk5CWjRJYUJBWVczanhNNHczVEpGVkE3bXllVUdReUd0LWdfeXZwUSIsInkiOi
JmLUUtaFlFM1RBV0t3aFZ2OXBlajlOQUJzOVNYOVhzTk84MHg1N2pGVHlVIn19fQ._TS4
d-LAnRlwdN97wiVnl4z7C9gvm45IWr-BvGTzeZaHtZtgNZ88gvzroU3LElUPbgF4kWi_D
FORnKzsx5yu6A
OAuth-Client-Attestation-PoP: eyJ0eXAiOiJvYXV0aC1jbGllbnQtYXR0ZXN0YXRp
b24tcG9wK2p3dCIsImFsZyI6IkVTMjU2In0.eyJhdWQiOiJodHRwczovL3JzLmV4YW1wb
GUuY29tIiwianRpIjoiZDI1ZDAwYWItNTUyYi00NmZjLWFlMTktOThmNDQwZjI1MDY0Ii
wiaWF0IjoxNzcyNDg3NTk1LCJjaGFsbGVuZ2UiOiI1YzFhOWUxMC0yOWZmLTRjMmItYWU
3My01N2MwOTU3YzA5YzQifQ.Uh-vRynTGGARZNqijGyovBMm_EsX5qu0fg0VGPVRsp1rJ
dF7rElbZcEv0CAtzm5kXhjSXHYGxEVb0I7HIeUFRg

9.1. DPoP Combined Mode Considerations

When using DPoP combined mode, the key used for client authentication and token binding is shared. This may be undesirable depending on the deployment considerations of the Client. Conversely, the benefits of this approach are as follows:¶

• It authenticates (attests) the DPoP key used for sender-constraining tokens against the Client deployment.¶

• It reduces implementation complexity for the Client by minimizing the number of JWTs that need to be constructed or validated in a request.¶

• It reduces run-time costs for the Client by minimizing the number of cryptographic operations that need to be constructed in a request, especially if the keys are in a remote and/or hardware-backed key storage.¶

9.2. Reuse of a Client Attestation JWT

Implementers should be aware that the design of this authentication mechanism deliberately allows for a Client Instance to re-use a single Client Attestation JWT in multiple interactions/requests with an Authorization Server or Resource Server, whilst producing a fresh Client Attestation PoP JWT. Client deployments should consider this when determining the validity period for issued Client Attestation JWTs as this ultimately controls how long a Client Instance can re-use a single Client Attestation JWT.¶

9.3. Refresh token binding

Authorization servers issuing a refresh token in response to a token request using the client attestation mechanism as defined by this draft MUST bind the refresh token to the Client Instance and its associated public key, and NOT just the client as specified in Section 6 of [RFC6749]. To prove this binding, the Client Instance MUST use the client attestation mechanism when refreshing an access token. The client MUST also use the same key that was present in the "cnf" claim of the client attestation that was used when the refresh token was issued.¶

9.4. Binding of OAuth protocol artifacts

Authorization servers using Attestation-Based Client Authentication are RECOMMENDED to bind relevant protocol artifacts to the Client Instance and its associated public key where possible, and NOT just the client as specified in [RFC6749]. Note that this only applies if Attestation-Based Client Authentication is used as Client Authentication. Examples of these artifacts include but are not limited to:¶

• The authorization_code as specified in Section 4.1 of [RFC6749].¶

• The auth_req_id as specified in section 7.3 [CIBA].¶

How this binding is established and then proven is specific to the protocol artifact. For example establishing binding to an authorization_code involves the client instance using client attestation before the user is redirected to the Authorization Endpoint (for example by using PAR, [RFC9126]), and proving binding of the authorization_code to the Client Instance involves using the client attestation mechanism to authenticate at the token endpoint when performing the authorization code grant.¶

9.5. Web Server Default Maximum HTTP Header Sizes

Because the Client Attestation and Client Attestation PoP are communicated using HTTP headers, implementers should consider that web servers may have a default maximum HTTP header size configured which could be too low to allow conveying a Client Attestation and or Client Attestation PoP in an HTTP request. It should be noted, that this limit is not given by the HTTP [RFC9112], but instead web server implementations commonly set a default maximum size for HTTP headers. As of 2024, typical limits for modern web servers configure maximum HTTP headers as 8 kB or more as a default.¶

9.6. Rotation of Client Instance Key

This specification does not provide a mechanism to rotate the Client Instance Key in the Client Attestation JWT's "cnf" claim. If the Client Instance needs to use a new Client Instance Key for any reason, then it MUST request a new Client Attestation JWT from its Client Attester.¶

9.7. Replay Attack Detection

Authorization Server or Resource Servers implementing measures to detect replay attacks as described in Section 11.1 require efficient data structures to manage large amounts of challenge or jti values for use cases with high volumes of transactions. To limit the size of the data structure, the Authorization Server or Resource Server should use a sliding window, allowing Client Attestation PoPs within a certain time window, in which the seen challenge or jti values are stored, but discarded afterwards. The allowed window is determined by the iat of the Client Attestation PoP and the sliding window time duration chosen by the Authorization Server or Resource Server. To ensure security, the Authorization Server or Resource Server MUST first evaluate the iat of the Client Attestation PoP and reject any Client Attestation PoP whose iat falls outside this time window. Using such a data structure, the Authorization Server or Resource Server performs the following operations:¶

• search for the challenge or jti value of the Client Attestation PoP to validate whether it has been previously seen, and reject the Client Attestation PoP if it has¶

• insert the challenge or jti value of the Client Attestation PoP once it has passed all other checks¶

• delete challenge or jti values after they have passed the sliding time window¶

A trie (also called prefix tree), or a patricia trie (also called radix tree) are RECOMMENDED data structures to implement such a mechanism. Note that this seen-values mechanism is only needed when replay detection relies on a jti value or on a challenge obtained from the challenge endpoint. When the Authorization Server or Resource Server issues a challenge bound to a specific Client Instance session (see Section 11.1), it can instead validate the Client Attestation PoP against the single challenge value expected for that session, without maintaining a seen-values data structure.¶

9.8. Trust Management and Key Resolution

The mechanisms by which the Authorization Server establishes trust in the Client Attester, and by which it obtains the public keys used to verify Client Attestation JWTs, are out of scope of this specification.¶

Attestation-Based Client Authentication protects the integrity of Client Attestations using either Message Authentication Codes (MACs) or digital signatures. When digital signatures are used, the Authorization Server needs to be able to obtain the corresponding public key, either through pre-configuration or through dynamic discovery.¶

Examples of trust management approaches include:¶

• Public Key Infrastructure (PKI) and trust lists.¶

• Pre-shared or out-of-band negotiated configuration (e.g., keys, URLs).¶

Specifications, profiles, and ecosystems built on top of Attestation-Based Client Authentication SHOULD adopt one of the following mechanisms to resolve the public key used to verify a Client Attestation JWT:¶

• The x5c header parameter, as defined in Section 4.1.6 of [RFC7515], conveys an X.509 certificate chain in the JOSE header of each Client Attestation. Trust is established by validating the chain against a configured trust anchor.¶

• The kid header parameter combined with the jku header parameter, as defined in Section 4.1.2 of [RFC7515] and Section 4.1.3 of [RFC7515]. The Authorization Server retrieves a JWK Set from the URL indicated by jku and selects the key identified by kid. This approach is self-contained but requires an additional HTTP request, and trust must be established in the jku URL.¶

• The kid header parameter combined with Client Metadata or other pre-shared information. Client Metadata, as defined in [RFC7591], includes a jwks_uri parameter which, together with kid, enables resolution of the verification key.¶

10.1. Client Instance Tracking Across Authorization Servers or Resource Servers

Implementers should be aware that using the same client attestation across multiple Authorization Servers or Resource Servers could result in correlation of the end user using the Client Instance through claim values (including the Client Instance Key in the cnf claim). Client deployments are therefore RECOMMENDED to use different Client Attestation JWTs with different Client Instance Keys across different Authorization Servers or Resource Servers.¶

11.1. Replay Attacks

An Authorization/Resource Server SHOULD implement measures to detect replay attacks by the Client Instance. In the context of this specification, this means to detect that an attacker is resending the same Client Attestation PoP JWT in multiple requests. The following options are RECOMMENDED for this client authentication method:¶

• The Authorization/Resource Server manages a list of witnessed jti values of the Client Attestation PoP JWT for the time window of which the JWT would be considered valid. This sliding time window is based on the iat of the Client Attestation PoP and the duration chosen by the Authorization/Resource Server. If any Client Attestation PoP JWT would be replayed, the Authorization/Resource Server would recognize the jti value in the list and respond with an authentication error. Details how to implement such a data structure to maintain jti values is given in Section 9.7.¶

• The Authorization/Resource Server provides a challenge as an OAuth-Client-Attestation-Challenge in the challenge endpoint to the Client Instance and the Client uses it as a challenge value in the Client Attestation PoP JWT. The Authorization/Resource Server may choose to:¶

  • manage a list of witnessed challenge values, similar to the previously described jti approach. Details how to implement such a data structure to maintain challenge values is given in Section 9.7. This guarantees stronger replay protection with a challenge chosen by the Authorization/Resource Server itself, at the potential cost of an additional round-trip.¶

  • use self-contained challenges while not storing the seen challenges. This approach scales well, while only guaranteeing freshness, but no replay protection within the limited time-window chosen by the Authorization/Resource Server.¶

• The Authorization/Resource Server generates a challenge that is bound to the Client Instance's session, such that a specific challenge in the Client Attestation PoP JWT is expected and validated. The Authorization/Resource Server sends the challenge as part of another previous response to the Client Instance.¶

Note that protocols that provide a challenge as part of a previous response should provide a clear indicator for clients when this feature is used. This makes it easier for client implementations to deal with proper state handling. This can be implicit by always mandating support for this feature or via some metadata that allows the client to detect support for this feature for a specific server.¶

Because clock skews between servers and clients may be large, Authorization/Resource Servers MAY limit Client Attestation PoP lifetimes by using server-provided challenge values containing the time at the server rather than comparing the client-supplied iat time to the time at the server. Challenges created in this way yield the same result even in the face of arbitrarily large clock skews.¶

In any case the Authorization/Resource Server SHOULD ensure the freshness of the Client Attestation PoP by checking either the iat claim or if present the server provided challenge, is within an acceptable time window.¶

The approach using a challenge explicitly provided by the Authorization/Resource Server gives stronger replay attack detection guarantees, however support by the Authorization/Resource Server is OPTIONAL to simplify mandatory implementation requirements. The jti value is mandatory and hence acts as a default fallback.¶

11.2. Client Attestation Protection

This specification allows both, digital signatures using asymmetric cryptography, and Message Authentication Codes (MAC) to be used to protect Client Attestation JWTs. Implementers should only use MACs to secure the integrity of Client Attestation JWTs if they fully understand the risks of MACs when compared to digital signatures and especially the requirements of their use-case scenarios. These use-cases typically represent deployments where the Client Attester and Authorization Server have a trust relationship and the possibility to securely exchange keys out of band or are the same entity and no other entity needs to verify the Client Attestations. We expect most deployments to use digital signatures for the protection of Client Attestations, and implementers SHOULD default to digital signatures if they are unsure.¶

13.1. OAuth Extensions Error Registration

This specification requests registration of the following values in the IANA "OAuth Extensions Error Registry" registry of [IANA.OAuth.Params] established by [RFC6749].¶

• Name: use_attestation_challenge¶

• Usage Location: token error response, resource access error response¶

• Protocol Extension: OAuth 2.0 Attestation-Based Client Authentication¶

• Change Controller: IETF¶

• Reference: Section 7.4 of this specification¶

• Name: use_fresh_attestation¶

• Usage Location: token error response, resource access error response¶

• Protocol Extension: OAuth 2.0 Attestation-Based Client Authentication¶

• Change Controller: IETF¶

• Reference: Section 7.4 of this specification¶

• Name: invalid_client_attestation¶

• Usage Location: token error response, resource access error response¶

• Protocol Extension: OAuth 2.0 Attestation-Based Client Authentication¶

• Change Controller: IETF¶

• Reference: Section 7.4 of this specification¶

13.2. OAuth Authorization Server Metadata Registration

This specification requests registration of the following values in the IANA "OAuth Authorization Server Metadata" registry of [IANA.OAuth.Params] established by [RFC8414].¶

• Metadata Name: challenge_endpoint¶

• Metadata Description: URL of the authorization server's challenge endpoint which is used to obtain a fresh challenge for usage in client authentication methods such as client attestation.¶

• Change Controller: IETF¶

• Reference: Section 6.1 of this specification¶

• Metadata Name: client_attestation_signing_alg_values_supported¶

• Metadata Description: JSON array containing a list of the JWS signing algorithms supported by the authorization server for the signature on the Client Attestation JWT.¶

• Change Controller: IETF¶

• Reference: Section 8 of this specification¶

• Metadata Name: client_attestation_pop_signing_alg_values_supported¶

• Metadata Description: JSON array containing a list of the JWS signing algorithms supported by the authorization server for the signature on the Client Attestation PoP JWT.¶

• Change Controller: IETF¶

• Reference: Section 8 of this specification¶

13.3. OAuth Protected Resource Metadata Registration

This specification requests registration of the following values in the IANA "OAuth Protected Resource Metadata" registry of [IANA.OAuth.Params] established by [RFC9728].¶

• Metadata Name: challenge_endpoint¶

• Metadata Description: URL of the protected resource's challenge endpoint which is used to obtain a fresh challenge for usage in client authentication methods such as client attestation.¶

• Change Controller: IETF¶

• Reference: Section 6.1 of this specification¶

• Metadata Name: client_attestation_pop_methods_supported¶

• Metadata Description: JSON array of strings, each identifying a Proof of Possession method the authorization server accepts when requiring Clients to present a Client Attestation as an additional security signal. If omitted, presenting a Client Attestation is not required.¶

• Change Controller: IETF¶

• Reference: Section 7.6 of this specification¶

13.4. OAuth Protected Resource Metadata Registration

This specification requests registration of the following value in the IANA "OAuth Protected Resource Metadata" registry of [IANA.OAuth.Params] established by [RFC9728].¶

• Metadata Name: client_attestation_pop_methods_supported¶

• Metadata Description: JSON array of strings, each identifying a Proof of Possession method the protected resource accepts when requiring Clients to present a Client Attestation as an additional security signal. If omitted, presenting a Client Attestation is not required.¶

• Change Controller: IETF¶

• Reference: Section 7.6 of this specification¶

13.5. OAuth Client Attestation Proof-of-Possession Methods Registry

This specification establishes the IANA "OAuth Client Attestation Proof-of-Possession Methods" registry. This registry lists the Proof of Possession methods that a Client may use to demonstrate possession of the Client Instance Key, referenced by the client_attestation_pop_methods_supported metadata parameter defined in Section 7.6.¶

Client Attestation Proof-of-Possession Methods are registered by Specification Required [RFC8126] after a two-week review period on the oauth-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts. To allow for the allocation of values prior to publication of the final version of a specification, the designated experts may approve registration once they are satisfied that the specification will be completed and published. However, if the specification is not completed and published in a timely manner, as determined by the designated experts, the designated experts may request that IANA withdraw the registration.¶

Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register Client Attestation PoP: 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. If the designated experts are not responsive, the registration requesters should contact IANA to escalate the process.¶

Designated experts should apply at least the following criteria when reviewing proposed registrations:¶

• the mechanism should not duplicate existing functionality¶

• the mechanism is likely generally applicable, as opposed to being used for a single application¶

• the specification sufficiently describes how the Proof of Possession method works in combination with a Client Attestation¶

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

In order to enable broadly informed review of registration decisions, there should be multiple designated experts to represent the perspectives of different applications using this specification. In cases where registration may be perceived as a conflict of interest for a particular expert, that expert should defer to the judgment of the other experts.¶

The mailing list is used to enable public review of registration requests, which enables both designated experts and other interested parties to provide feedback on proposed registrations. Designated experts may allocate values prior to publication of the final specification. This allows authors to receive guidance from the designated experts early, so any identified issues can be fixed before the final specification is published.¶

13.6. Registration of attest_jwt_client_auth Token Endpoint Authentication Method

This section registers the value "attest_jwt_client_auth" in the IANA "OAuth Token Endpoint Authentication Methods" registry established by OAuth 2.0 Dynamic Client Registration Protocol [RFC7591].¶

• Token Endpoint Authentication Method Name: "attest_jwt_client_auth"¶

• Change Controller: IESG¶

• Specification Document(s): Section 8 of this specification¶

13.7. Registration of attest_jwt_client_auth_dpop Token Endpoint Authentication Method

This section registers the value "attest_jwt_client_auth_dpop" in the IANA "OAuth Token Endpoint Authentication Methods" registry established by OAuth 2.0 Dynamic Client Registration Protocol [RFC7591].¶

• Token Endpoint Authentication Method Name: "attest_jwt_client_auth_dpop"¶

• Change Controller: IESG¶

• Specification Document(s): Section 5.2 of this specification¶

13.8. HTTP Field Name Registration

This section requests registration of the following scheme in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" [IANA.HTTP.Fields] described in [RFC9110]:¶

• Field Name: OAuth-Client-Attestation¶

• Status: permanent¶

• Structured Type: Item¶

• Reference: Section 4 of this specification¶

• Field Name: OAuth-Client-Attestation-PoP¶

• Status: permanent¶

• Structured Type: Item¶

• Reference: Section 5.1 of this specification¶

• Field Name: OAuth-Client-Attestation-Challenge¶

• Status: permanent¶

• Structured Type: Item¶

• Reference: Section 6 of this specification¶

14.1. Normative References

[IANA.HTTP.Fields]

IANA, "Hypertext Transfer Protocol (HTTP) Field Name Registry", n.d., <https://www.iana.org/assignments/http-fields/http-fields.xhtml>.

[IANA.JOSE.ALGS]

IANA, "JSON Web Signature and Encryption Algorithms", n.d., <https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms>.

[IANA.OAuth.Params]

IANA, "OAuth Parameters", n.d., <https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml>.

[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>.

[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>.

[RFC6750]

Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, <https://www.rfc-editor.org/rfc/rfc6750>.

[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>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[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>.

[RFC7800]

Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, <https://www.rfc-editor.org/rfc/rfc7800>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[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>.

[RFC8414]

Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, <https://www.rfc-editor.org/rfc/rfc8414>.

[RFC8725]

Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, <https://www.rfc-editor.org/rfc/rfc8725>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[RFC9112]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112, June 2022, <https://www.rfc-editor.org/rfc/rfc9112>.

[RFC9126]

Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, September 2021, <https://www.rfc-editor.org/rfc/rfc9126>.

[RFC9449]

Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.

[RFC9728]

Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, <https://www.rfc-editor.org/rfc/rfc9728>.

14.2. Informative References

[CIBA]

"OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0", n.d., <https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html>.

[RFC7523]

Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, <https://www.rfc-editor.org/rfc/rfc7523>.

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/rfc/rfc9334>.

[RFC9901]

Fett, D., Yasuda, K., and B. Campbell, "Selective Disclosure for JSON Web Tokens", RFC 9901, DOI 10.17487/RFC9901, November 2025, <https://www.rfc-editor.org/rfc/rfc9901>.