urn:ietf:params:oauth:request_
Registry Context
This URN form can identify a request URI issued after a successful pushed authorization request, for later use in an authorization request.
Technical Summary
RFC 9126 permits an authorization server to construct a request_uri as `urn:ietf:params:oauth:request_uri:<reference-value>`. The value must contain a cryptographically strong pseudorandom component and be bound to the client that posted the authorization request.
When Used
When an authorization server chooses this URN representation for the request_uri returned by a successful pushed authorization request.
Normative Requirements
Clients
RFC 9126 - Section 4
use a request_uri value only once.
Condition: When building an authorization request from a pushed request
the client MUST only use a request_uri value once
RFC 9126 - Section 7.5
use PKCE, a unique state parameter, or the OpenID Connect nonce parameter in the pushed Request Object.
Condition: To prevent request URI swapping
Clients SHOULD make use of PKCE, a unique state parameter, or the OIDC "nonce" parameter
Authorization servers
RFC 9126 - Section 2.2
include in the request_uri some part generated using a cryptographically strong pseudorandom algorithm, making valid values computationally infeasible to predict or guess.
Condition: When generating the request_uri value
it MUST contain some part generated using a cryptographically strong pseudorandom algorithm
RFC 9126 - Section 2.2
bind the request_uri value to the client that posted the authorization request.
Condition: When issuing the request_uri
The request_uri value MUST be bound to the client that posted the authorization request
RFC 9126 - Section 4
reject an expired request_uri as invalid.
Condition: When the request_uri has expired
An expired request_uri MUST be rejected as invalid
RFC 9126 - Section 4
validate an authorization request arising from a pushed request as it would any other authorization request.
Condition: When processing the subsequent authorization request
The authorization server MUST validate authorization requests arising from a pushed request as it would any other authorization request
RFC 9126 - Section 7.1
account for the request URI entropy considerations in RFC 9101 Section 10.2 clause (d).
Condition: To mitigate request URI guessing and replay
The authorization server MUST account for the considerations given in JAR [RFC9101], Section 10.2, clause (d) on request URI entropy
RFC 9126 - Section 4
treat request_uri values as one-time use.
Authorization servers SHOULD treat request_uri values as one-time use
RFC 9126 - Section 2.2
construct the request_uri as `urn:ietf:params:oauth:request_uri:<reference-value>`, using the reference value as the random part.
The authorization server MAY construct the request_uri value using the form urn:ietf:params:oauth:request_uri:<reference-value>
RFC 9126 - Section 4
allow duplicate use of a request_uri caused by the user reloading or refreshing the user agent.
Condition: To accommodate a user-agent reload or refresh
MAY allow for duplicate requests due to a user reloading/refreshing their user agent
RFC 9126 - Section 4
omit validation steps already performed when the request was pushed.
Condition: Only if it can validate that the request was pushed and neither the request nor server policy has changed in a way affecting the omitted checks
The authorization server MAY omit validation steps that it performed when the request was pushed
Servers
RFC 9126 - Section 2.2
generate a request URI and provide it in the response with HTTP status code 201.
Condition: If verification of the pushed authorization request is successful
the server MUST generate a request URI and provide it in the response with a 201 HTTP status code
Validation Guidance
Verify that a successful PAR response uses HTTP status 201 and contains a request_uri member.
Verify that a successful PAR response also contains an expires_in positive integer describing the request URI lifetime in seconds.
Verify that generated request_uri values contain a cryptographically strong, unpredictable component with entropy appropriate to the protected resource.
Verify that each request_uri is bound to the client that initiated the pushed authorization request.
If the optional URN representation is used, verify that it has the form `urn:ietf:params:oauth:request_uri:<reference-value>`.
Verify that clients do not reuse request_uri values and that the authorization server normally enforces one-time use, except for deliberately supported user-agent reloads or refreshes.
Reject an expired request_uri as invalid.
Apply normal authorization-request validation to requests using a pushed request_uri; omit previously completed checks only under the conditions permitted by RFC 9126.
Verify that clients use PKCE, unique state, or an OpenID Connect nonce in the pushed Request Object to mitigate request URI swapping.
Security Notes
RFC 9126 - Section 7.1
An attacker could guess and replay a valid request URI to impersonate its client. The authorization server must account for RFC 9101's request URI entropy guidance.
RFC 9126 - Section 7.5
An attacker could capture a request URI and substitute it into another authorization request. RFC 9126 recommends that clients use PKCE, unique state, or an OpenID Connect nonce in the pushed Request Object.
Reference
Details
- Entry Id
urn:ietf:params:oauth:request_uri - Urn
urn:ietf:params:oauth:request_uri - Common Name
A URN Sub-Namespace for OAuth Request URIs.- Change Controller
IESG- Reference
RFC9126 - Section 2.2