nonce
Registry Context
The `nonce` claim associates a client session with an ID Token and may also carry nonce values in other JWT applications, including DPoP proofs.
Technical Summary
RFC 9449 uses the claim for authorization server-provided DPoP nonces that can limit the lifetime of DPoP proofs. Supplied nonce values must be unpredictable, mismatches must be rejected, and a client receiving a new nonce in a successful response must use it for subsequent token requests until another is supplied.
When Used
Use this claim to associate a client session with an ID Token or to carry a nonce defined by another JWT-based protocol, such as an authorization server-provided DPoP nonce.
Normative Requirements
Clients
RFC 9449 - Section 8.2
use the newly supplied nonce for the next token request and all subsequent token requests.
Condition: until the authorization server supplies another nonce
The client MUST use the new nonce value supplied
Authorization servers
RFC 9449 - Section 8
include more than one DPoP-Nonce header in the error response.
Condition: when returning a DPoP nonce challenge
there MUST NOT be more than one DPoP-Nonce header
RFC 9449 - Section 8
generate unpredictable nonce values.
Condition: when supplying nonce values for DPoP proofs
Nonce values MUST be unpredictable.
RFC 9449 - Section 8
reject the request when the nonce claim does not exactly match a nonce recently supplied to the client.
Condition: when validating a DPoP proof containing a nonce claim
the authorization server MUST reject the request
RFC 9449 - Section 8
use a nonce value contributed by the authorization server in DPoP proofs to limit their lifetime.
Including a nonce value contributed by the authorization server in the DPoP proof MAY be used
RFC 9449 - Section 8
supply a nonce value for the client to include in DPoP proofs.
An authorization server MAY supply a nonce value
RFC 9449 - Section 8
include a DPoP-Nonce HTTP header providing a new nonce for subsequent requests.
Condition: in a response rejecting a nonce mismatch
The rejection response MAY include a DPoP-Nonce HTTP header
RFC 9449 - Section 8.2
supply a new nonce using a DPoP-Nonce HTTP header in the response.
The authorization server MAY supply the new nonce
Validation Guidance
When used as a DPoP nonce, verify that the value conforms to the `1*NQCHAR` syntax defined in RFC 9449 Section 8.1.
Ensure authorization server-generated DPoP nonce values are unpredictable.
Reject a DPoP proof when its nonce claim does not exactly match a nonce recently supplied to the client.
Ensure a DPoP nonce challenge response contains no more than one DPoP-Nonce header.
Ensure the client replaces its nonce state when a new nonce is supplied and uses that value for subsequent token requests until another is supplied.
Security Notes
RFC 9449 - Section 8
Authorization server-provided nonces can limit the lifetime of DPoP proofs and prevent a party controlling the client from creating proofs for use arbitrarily far in the future.
Reference
Details
- Entry Id
nonce- Claim Name
nonce- Claim Description
Value used to associate a Client session with an ID Token (MAY also be used for nonce values in other applications of JWTs)- Change Controller
OpenID_Foundation_ Artifact_ Binding_ Working_ Group - Reference
OpenID Connect Core 1.0 - Section 2, RFC9449