provide a valid DPoP proof JWT in a DPoP header.

Condition: when requesting an access token bound to a public key using DPoP, regardless of grant type

the client MUST provide a valid DPoP proof JWT in a DPoP header

discard the access token response.

Condition: when token_type is not DPoP and DPoP protection is deemed important for the application's security

The client MUST discard the response in this case

include both a DPoP proof and the access token.

Condition: when making a request to a DPoP-protected resource

Requests to DPoP-protected resources MUST include both a DPoP proof and the access token

generate a unique DPoP proof.

Condition: when retrying an idempotent request after an HTTP error generally understood as transient

It is RECOMMENDED that clients generate a unique DPoP proof

include token_type with the value DPoP in the access token response.

Condition: when the access token was bound to the client's DPoP key

A token_type of DPoP MUST be included in the access token response

bind the refresh token to the respective public key.

Condition: when supporting DPoP and issuing a refresh token to a public client that presented a valid DPoP proof at the token endpoint

the refresh token MUST be bound to the respective public key

validate the refresh token's public-key binding.

Condition: when the refresh token is later presented to obtain new access tokens

The binding MUST be validated when the refresh token is later presented

reject token requests from the client that do not contain a DPoP header.

Condition: when the client's dpop_bound_access_tokens client registration metadata value is true

the authorization server MUST reject token requests from the client that do not contain the DPoP header

issue an access token that is not DPoP-bound.

An authorization server MAY elect to issue access tokens that are not DPoP bound

grant access to the resource.

Condition: unless all DPoP access-token and proof checks are successful

The resource server MUST NOT grant access to the resource unless all checks are successful.

reliably identify whether an access token is DPoP-bound and ascertain sufficient information to verify its binding to the DPoP proof public key.

Resource servers MUST be able to reliably identify whether an access token is DPoP-bound

ensure that the public key from the DPoP proof matches the public key bound to the access token.

Condition: when validating a DPoP-bound access token

Resource servers supporting DPoP MUST ensure that the public key from the DPoP proof matches

check that a DPoP proof was received, validate it under Section 4.3, and verify that its public key matches the access-token binding.

Condition: when processing a DPoP-bound access token

a resource server MUST check that a DPoP proof was also received

accept DPoP proofs only for a limited time after their creation.

Condition: to limit DPoP proof replay

servers MUST only accept DPoP proofs for a limited time after their creation

ensure that the DPoP proof satisfies the header cardinality, JWT syntax, required-claim, typ, alg, signature, public-key, method, URI, nonce, creation-time, and applicable access-token-binding checks listed in Section 4.3.

Condition: when validating a DPoP proof

To validate a DPoP proof, the receiving server MUST ensure the following

apply syntax-based and scheme-based URI normalization before comparing the htu claim.

Condition: to reduce false negatives during DPoP proof validation

servers SHOULD employ syntax-based normalization and scheme-based normalization

include an error authentication parameter indicating why the request was declined.

Condition: when the request included an access token but failed authentication

An error parameter SHOULD be included to indicate the reason why the request was declined

include an algs authentication parameter listing acceptable JWS algorithms for DPoP proof JWTs.

Condition: in a DPoP authentication challenge

An algs parameter SHOULD be included

use the challenge corresponding to the attempted authentication mechanism to deliver error information.

Condition: when that mechanism can be established unambiguously

the corresponding challenge SHOULD be used to deliver error information

accept a DPoP proof whose iat value is in the reasonably near future.

Condition: to accommodate clock offsets

the server MAY accept DPoP proofs that carry an iat time in the reasonably near future

limit DPoP proof lifetimes using server-provided nonce values containing server time.

Condition: instead of comparing client-supplied iat with server time

servers MAY limit DPoP proof lifetimes by using server-provided nonce values

include a WWW-Authenticate header in responses to conditions other than missing, invalid, or insufficient credentials.

Condition: when issuing a DPoP authentication challenge

The server MAY include the WWW-Authenticate header in response to other conditions as well.

include a realm authentication parameter.

Condition: in a DPoP authentication challenge

The authentication parameter realm MAY be included

include a scope authentication parameter.

Condition: in a DPoP authentication challenge

A scope authentication parameter MAY be included

include an error_description authentication parameter with a human-readable developer explanation.

Condition: when an error parameter is included in a DPoP authentication challenge

An error_description parameter MAY be included along with the error parameter

use additional authentication parameters.

Condition: in a DPoP authentication challenge

Additional authentication parameters MAY be used

use both Bearer and DPoP challenges to deliver error information.

Condition: when the attempted authentication mechanism cannot be established unambiguously

both Bearer and DPoP challenges MAY be used to deliver error information

include an error code or other error information.

Condition: when no authentication information was included with the request

the challenges SHOULD NOT include an error code or other error information

be used with Proxy-Authenticate or Proxy-Authorization header fields.

Condition: because the scheme is only for origin-server authentication

this authentication scheme MUST NOT be used with the Proxy-Authenticate or Proxy-Authorization header fields

contain a valid DPoP proof JWT.

Condition: in a DPoP access token request

The DPoP HTTP header field MUST contain a valid DPoP proof JWT.

contain an ath claim.

Condition: when used with an access token for protected resource access

the DPoP proof MUST also contain the following claim

contain a nonce claim carrying a recent nonce from the DPoP-Nonce response header.

Condition: when the authorization server or resource server provided a DPoP-Nonce header

the DPoP proof MUST also contain the following claim

include the ath claim containing a valid hash of the associated access token.

Condition: when used to access a DPoP-protected resource

The DPoP proof MUST include the ath claim with a valid hash

contain additional JOSE header parameters or claims.

Condition: as defined by an extension, profile, or deployment-specific requirement

A DPoP proof MAY contain other JOSE Header Parameters or claims

be the base64url-encoded SHA-256 hash of the ASCII encoding of the associated access-token value.

Condition: when included in a DPoP proof

The value MUST be the result of a base64url encoding the SHA-256 hash

identify none or a symmetric signature algorithm.

It MUST NOT be none or an identifier for a symmetric algorithm

contain at least typ, alg, and jwk parameters, with typ equal to dpop+jwt.

The JOSE Header of a DPoP JWT MUST contain at least the following parameters

be assigned with negligible probability of duplication in the same context during its validity window.

The value MUST be assigned such that there is a negligible probability

contain a private key.

It MUST NOT contain a private key.

contain at least the jti, htm, htu, and iat claims.

The payload of a DPoP proof MUST contain at least the following claims

reject a DPoP-bound access token received using the Bearer authentication scheme.

such a protected resource MUST reject a DPoP-bound access token received as a bearer token

follow the specified rules for selecting which authentication challenge carries error information.

Condition: when responding with multiple WWW-Authenticate challenges

It is RECOMMENDED that the following rules be adhered to

present a DPoP proof for the same key used to obtain the refresh token.

Condition: each time the DPoP-bound refresh token is used to obtain a new access token

such a client MUST present a DPoP proof for the same key

ignore unknown authentication parameters.

Condition: when processing a DPoP authentication challenge

unknown parameters MUST be ignored by recipients