rfc9126.original   rfc9126.txt 
Web Authorization Protocol T. Lodderstedt Internet Engineering Task Force (IETF) T. Lodderstedt
Internet-Draft yes.com Request for Comments: 9126 yes.com
Intended status: Standards Track B. Campbell Category: Standards Track B. Campbell
Expires: 30 January 2022 Ping Identity ISSN: 2070-1721 Ping Identity
N. Sakimura N. Sakimura
NAT.Consulting NAT.Consulting
D. Tonge D. Tonge
Moneyhub Financial Technology Moneyhub Financial Technology
F. Skokan F. Skokan
Auth0 Auth0
29 July 2021 September 2021
OAuth 2.0 Pushed Authorization Requests OAuth 2.0 Pushed Authorization Requests
draft-ietf-oauth-par-10
Abstract Abstract
This document defines the pushed authorization request (PAR) This document defines the pushed authorization request (PAR)
endpoint, which allows clients to push the payload of an OAuth 2.0 endpoint, which allows clients to push the payload of an OAuth 2.0
authorization request to the authorization server via a direct authorization request to the authorization server via a direct
request and provides them with a request URI that is used as request and provides them with a request URI that is used as
reference to the data in a subsequent call to the authorization reference to the data in a subsequent call to the authorization
endpoint. endpoint.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 30 January 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9126.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Section 4.e of
provided without warranty as described in the Simplified BSD License. the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Introductory Example . . . . . . . . . . . . . . . . . . 4 1.1. Introductory Example
1.2. Conventions and Terminology . . . . . . . . . . . . . . . 5 1.2. Conventions and Terminology
2. Pushed Authorization Request Endpoint . . . . . . . . . . . . 6 2. Pushed Authorization Request Endpoint
2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Request
2.2. Successful Response . . . . . . . . . . . . . . . . . . . 9 2.2. Successful Response
2.3. Error Response . . . . . . . . . . . . . . . . . . . . . 10 2.3. Error Response
2.4. Management of Client Redirect URIs . . . . . . . . . . . 11 2.4. Management of Client Redirect URIs
3. The "request" Request Parameter . . . . . . . . . . . . . . . 12 3. The "request" Request Parameter
4. Authorization Request . . . . . . . . . . . . . . . . . . . . 14 4. Authorization Request
5. Authorization Server Metadata . . . . . . . . . . . . . . . . 15 5. Authorization Server Metadata
6. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 16 6. Client Metadata
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations
7.1. Request URI Guessing . . . . . . . . . . . . . . . . . . 16 7.1. Request URI Guessing
7.2. Open Redirection . . . . . . . . . . . . . . . . . . . . 16 7.2. Open Redirection
7.3. Request Object Replay . . . . . . . . . . . . . . . . . . 16 7.3. Request Object Replay
7.4. Client Policy Change . . . . . . . . . . . . . . . . . . 17 7.4. Client Policy Change
7.5. Request URI Swapping . . . . . . . . . . . . . . . . . . 17 7.5. Request URI Swapping
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 8. Privacy Considerations
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9.1. OAuth Authorization Server Metadata
10.1. OAuth Authorization Server Metadata . . . . . . . . . . 18 9.2. OAuth Dynamic Client Registration Metadata
10.2. OAuth Dynamic Client Registration Metadata . . . . . . . 18 9.3. OAuth URI Registration
10.3. OAuth URI Registration . . . . . . . . . . . . . . . . . 18 10. References
11. Normative References . . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References
12. Informative References . . . . . . . . . . . . . . . . . . . 19 10.2. Informative References
Appendix A. Document History . . . . . . . . . . . . . . . . . . 21 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses
1. Introduction 1. Introduction
A pushed authorization request (PAR), defined by this document, This document defines the pushed authorization request (PAR)
enables an OAuth [RFC6749] client to push the payload of an endpoint, which enables an OAuth [RFC6749] client to push the payload
authorization request directly to the authorization server. A of an authorization request directly to the authorization server. A
request URI value is received in in exchange, which is used as request URI value is received in exchange; it is used as reference to
reference to the authorization request payload data in a subsequent the authorization request payload data in a subsequent call to the
call to the authorization endpoint via the user agent. authorization endpoint via the user agent.
In OAuth [RFC6749] authorization request parameters are typically In OAuth [RFC6749], authorization request parameters are typically
sent as URI query parameters via redirection in the user agent. This sent as URI query parameters via redirection in the user agent. This
is simple but also yields challenges: is simple but also yields challenges:
* There is no cryptographic integrity and authenticity protection. * There is no cryptographic integrity and authenticity protection.
An attacker could, for example, modify the scope of access An attacker could, for example, modify the scope of access
requested or swap the context of a payment transaction by changing requested or swap the context of a payment transaction by changing
scope values. Although protocol facilities exist to enable scope values. Although protocol facilities exist to enable
clients or users to detect some such changes, preventing clients or users to detect some such changes, preventing
modifications early in the process is a more robust solution. modifications early in the process is a more robust solution.
* There is no mechanism to ensure confidentiality of the request * There is no mechanism to ensure confidentiality of the request
parameters. Although HTTPS is required for the authorization parameters. Although HTTPS is required for the authorization
endpoint, the request data passes through the user agent in the endpoint, the request data passes through the user agent in the
clear and query string data can inadvertently leak to web server clear, and query string data can inadvertently leak to web server
logs and to other sites via referer. The impact of such leakage logs and to other sites via the referer. The impact of such
can be significant, if personally identifiable information or leakage can be significant, if personally identifiable information
other regulated data is sent in the authorization request (which or other regulated data is sent in the authorization request
might well be the case in identity, open banking, and similar (which might well be the case in identity, open banking, and
scenarios). similar scenarios).
* Authorization request URLs can become quite large, especially in * Authorization request URLs can become quite large, especially in
scenarios requiring fine-grained authorization data, which might scenarios requiring fine-grained authorization data, which might
cause errors in request processing. cause errors in request processing.
JWT Secured Authorization Request (JAR) [I-D.ietf-oauth-jwsreq] JWT-Secured Authorization Request (JAR) [RFC9101] provides solutions
provides solutions for the security challenges by allowing OAuth for the security challenges by allowing OAuth clients to wrap
clients to wrap authorization request parameters in a request object, authorization request parameters in a Request Object, which is a
which is a signed and optionally encrypted JSON Web Token (JWT) signed and optionally encrypted JSON Web Token (JWT) [RFC7519]. In
[RFC7519]. In order to cope with the size restrictions, JAR order to cope with the size restrictions, JAR introduces the
introduces the "request_uri" parameter that allows clients to send a "request_uri" parameter that allows clients to send a reference to a
reference to a request object instead of the request object itself. Request Object instead of the Request Object itself.
This document complements JAR by providing an interoperable way to This document complements JAR by providing an interoperable way to
push the payload of an authorization request directly to the push the payload of an authorization request directly to the
authorization server in exchange for a "request_uri" value usable at authorization server in exchange for a "request_uri" value usable at
the authorization server in a subsequent authorization request. the authorization server in a subsequent authorization request.
PAR fosters OAuth security by providing clients a simple means for a PAR fosters OAuth security by providing clients a simple means for a
confidential and integrity protected authorization request. Clients confidential and integrity-protected authorization request. Clients
requiring an even higher security level, especially cryptographically requiring an even higher security level, especially cryptographically
confirmed non-repudiation, are able to use JWT-based request objects confirmed non-repudiation, are able to use JWT-based Request Objects
as defined by [I-D.ietf-oauth-jwsreq] in conduction with PAR. as defined by [RFC9101] in conjunction with PAR.
PAR allows the authorization server to authenticate the client before PAR allows the authorization server to authenticate the client before
any user interaction happens. The increased confidence in the any user interaction happens. The increased confidence in the
identity of the client during the authorization process allows the identity of the client during the authorization process allows the
authorization server to refuse illegitimate requests much earlier in authorization server to refuse illegitimate requests much earlier in
the process, which can prevent attempts to spoof clients or otherwise the process, which can prevent attempts to spoof clients or otherwise
tamper with or misuse an authorization request. tamper with or misuse an authorization request.
Note that HTTP "POST" requests to the authorization endpoint via the Note that HTTP "POST" requests to the authorization endpoint via the
user agent, as described in Section 3.1 of [RFC6749] and user agent, as described in Section 3.1 of [RFC6749] and
Section 3.1.2.1 of [OIDC], could also be used to cope with the Section 3.1.2.1 of [OIDC], could also be used to cope with the
request size limitations described above. However, it's only request size limitations described above. However, it's only
optional per [RFC6749] and, even when supported, it is a viable optional per [RFC6749], and, even when supported, it is a viable
option for traditional web applications but is prohibitively option for conventional web applications but is prohibitively
difficult to use with native mobile applications. As described in difficult to use with installed mobile applications. As described in
[RFC8252] those apps use platform-specific APIs to open the [RFC8252], those apps use platform-specific APIs to open the
authorization request URI in the system browser. When a native app authorization request URI in the system browser. When a mobile app
launches a browser, however, the resultant initial request is launches a browser, however, the resultant initial request is
constrained to use the "GET" method. Using "POST" for the constrained to use the "GET" method. Using "POST" for the
authorization request would require the app to first direct the authorization request would require the app to first direct the
browser to open a URI that the app controls via "GET" while somehow browser to open a URI that the app controls via "GET" while somehow
conveying the sizable authorization request payload and then have the conveying the sizable authorization request payload and then having
resultant response contain content and script to initiate a cross- the resultant response contain the content and script to initiate a
site form "POST" towards the authorization server. PAR is simpler to cross-site form "POST" towards the authorization server. PAR is
use and has additional security benefits described above. simpler to use and has additional security benefits, as described
above.
1.1. Introductory Example 1.1. Introductory Example
In traditional OAuth 2.0, a client typically initiates an In conventional OAuth 2.0, a client typically initiates an
authorization request by directing the user agent to make an HTTP authorization request by directing the user agent to make an HTTP
request like the following to the authorization server's request like the following to the authorization server's
authorization endpoint (extra line breaks and indentation for display authorization endpoint (extra line breaks and indentation for display
purposes only): purposes only):
GET /authorize?response_type=code GET /authorize?response_type=code
&client_id=CLIENT1234&state=duk681S8n00GsJpe7n9boxdzen &client_id=CLIENT1234&state=duk681S8n00GsJpe7n9boxdzen
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1
Host: as.example.com Host: as.example.com
Such a request could instead be pushed directly to the authorization Such a request could instead be pushed directly to the authorization
server by the client with a "POST" request to the PAR endpoint as server by the client with a "POST" request to the PAR endpoint as
illustrated in the following example (extra line breaks and illustrated in the following example (extra line breaks and spaces
whitespace for display purposes only). The client can authenticate for display purposes only). The client can authenticate (e.g., using
(e.g., using JWT client assertion based authentication as shown) JWT client assertion-based authentication as shown) because the
because the request is made directly to the authorization server. request is made directly to the authorization server.
POST /as/par HTTP/1.1 POST /as/par HTTP/1.1
Host: as.example.com Host: as.example.com
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
&response_type=code &response_type=code
&client_id=CLIENT1234&state=duk681S8n00GsJpe7n9boxdzen &client_id=CLIENT1234&state=duk681S8n00GsJpe7n9boxdzen
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&client_assertion_type= &client_assertion_type=
urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
skipping to change at page 5, line 44 skipping to change at line 223
only): only):
GET /authorize?client_id=CLIENT1234 GET /authorize?client_id=CLIENT1234
&request_uri=urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1 &request_uri=urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1
Host: as.example.com Host: as.example.com
1.2. Conventions and Terminology 1.2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This specification uses the terms "access token", "authorization This specification uses the terms "access token", "authorization
server", "authorization endpoint", "authorization request", "token server", "authorization endpoint", "authorization request", "token
endpoint", and "client" defined by The OAuth 2.0 Authorization endpoint", and "client" defined by "The OAuth 2.0 Authorization
Framework [RFC6749]. Framework" [RFC6749].
2. Pushed Authorization Request Endpoint 2. Pushed Authorization Request Endpoint
The pushed authorization request endpoint is an HTTP API at the The pushed authorization request endpoint is an HTTP API at the
authorization server that accepts HTTP "POST" requests with authorization server that accepts HTTP "POST" requests with
parameters in the HTTP request message body using the "application/x- parameters in the HTTP request message body using the "application/x-
www-form-urlencoded" format with a character encoding of UTF-8 as www-form-urlencoded" format. This format has a character encoding of
described in Appendix B of [RFC6749]. The PAR endpoint URL MUST use UTF-8, as described in Appendix B of [RFC6749]. The PAR endpoint URL
the "https" scheme. MUST use the "https" scheme.
Authorization servers supporting PAR SHOULD include the URL of their Authorization servers supporting PAR SHOULD include the URL of their
pushed authorization request endpoint in their authorization server pushed authorization request endpoint in their authorization server
metadata document [RFC8414] using the metadata document [RFC8414] using the
"pushed_authorization_request_endpoint" parameter as defined in "pushed_authorization_request_endpoint" parameter as defined in
Section 5. Section 5.
The endpoint accepts the authorization request parameters defined in The endpoint accepts the authorization request parameters defined in
[RFC6749] for the authorization endpoint as well as all applicable [RFC6749] for the authorization endpoint as well as all applicable
extensions defined for the authorization endpoint. Some examples of extensions defined for the authorization endpoint. Some examples of
such extensions include PKCE [RFC7636], Resource Indicators such extensions include Proof Key for Code Exchange (PKCE) [RFC7636],
[RFC8707], and OpenID Connect [OIDC]. The endpoint MAY also support Resource Indicators [RFC8707], and OpenID Connect (OIDC) [OIDC]. The
sending the set of authorization request parameters as a request endpoint MAY also support sending the set of authorization request
object according to [I-D.ietf-oauth-jwsreq] and Section 3. parameters as a Request Object according to [RFC9101] and Section 3
of this document.
The rules for client authentication as defined in [RFC6749] for token The rules for client authentication as defined in [RFC6749] for token
endpoint requests, including the applicable authentication methods, endpoint requests, including the applicable authentication methods,
apply for the PAR endpoint as well. If applicable, the apply for the PAR endpoint as well. If applicable, the
"token_endpoint_auth_method" client metadata [RFC7591] parameter "token_endpoint_auth_method" client metadata parameter [RFC7591]
indicates the registered authentication method for the client to use indicates the registered authentication method for the client to use
when making direct requests to the authorization server, including when making direct requests to the authorization server, including
requests to the PAR endpoint. Similarly, the requests to the PAR endpoint. Similarly, the
"token_endpoint_auth_methods_supported" authorization server metadata "token_endpoint_auth_methods_supported" authorization server metadata
[RFC8414] parameter lists client authentication methods supported by [RFC8414] parameter lists client authentication methods supported by
the authorization server when accepting direct requests from clients, the authorization server when accepting direct requests from clients,
including requests to the PAR endpoint. including requests to the PAR endpoint.
Due to historical reasons there is potential ambiguity regarding the Due to historical reasons, there is potential ambiguity regarding the
appropriate audience value to use when employing JWT client assertion appropriate audience value to use when employing JWT client
based authentication (defined in Section 2.2 of [RFC7523] with assertion-based authentication (defined in Section 2.2 of [RFC7523]
"private_key_jwt" or "client_secret_jwt" authentication method names with "private_key_jwt" or "client_secret_jwt" authentication method
per Section 9 of [OIDC]). To address that ambiguity the issuer names per Section 9 of [OIDC]). To address that ambiguity, the
identifier URL of the authorization server according to [RFC8414] issuer identifier URL of the authorization server according to
SHOULD be used as the value of the audience. In order to facilitate [RFC8414] SHOULD be used as the value of the audience. In order to
interoperability the authorization server MUST accept its issuer facilitate interoperability, the authorization server MUST accept its
identifier, token endpoint URL, or pushed authorization request issuer identifier, token endpoint URL, or pushed authorization
endpoint URL as values that identify it as an intended audience. request endpoint URL as values that identify it as an intended
audience.
2.1. Request 2.1. Request
A client sends the parameters that comprise an authorization request A client sends the parameters that comprise an authorization request
directly to the PAR endpoint. A typical parameter set might include: directly to the PAR endpoint. A typical parameter set might include:
"client_id", "response_type", "redirect_uri", "scope", "state", "client_id", "response_type", "redirect_uri", "scope", "state",
"code_challenge", and "code_challenge_method" as shown in the example "code_challenge", and "code_challenge_method" as shown in the example
below. However, the pushed authorization request can be composed of below. However, the pushed authorization request can be composed of
any of the parameters applicable for use at authorization endpoint any of the parameters applicable for use at the authorization
including those defined in [RFC6749] as well as all applicable endpoint, including those defined in [RFC6749] as well as all
extensions. The "request_uri" authorization request parameter is one applicable extensions. The "request_uri" authorization request
exception, which MUST NOT be provided. parameter is one exception, and it MUST NOT be provided.
The request also includes, as appropriate for the given client, any The request also includes, as appropriate for the given client, any
additional parameters necessary for client authentication (e.g., additional parameters necessary for client authentication (e.g.,
"client_secret", or "client_assertion" and "client_assertion_type"). "client_secret" or "client_assertion" and "client_assertion_type").
Such parameters are defined and registered for use at the token Such parameters are defined and registered for use at the token
endpoint but are applicable only for client authentication. When endpoint but are applicable only for client authentication. When
present in a pushed authorization request, they are relied upon only present in a pushed authorization request, they are relied upon only
for client authentication and are not germane to the authorization for client authentication and are not germane to the authorization
request itself. Any token endpoint parameters that are not related request itself. Any token endpoint parameters that are not related
to client authentication have no defined meaning for a pushed to client authentication have no defined meaning for a pushed
authorization request. The "client_id" parameter is defined with the authorization request. The "client_id" parameter is defined with the
same semantics for both authorization requests and requests to the same semantics for both authorization requests and requests to the
token endpoint; as a required authorization request parameter, it is token endpoint; as a required authorization request parameter, it is
similarly required in a pushed authorization request. similarly required in a pushed authorization request.
The client constructs the message body of an HTTP "POST" request with The client constructs the message body of an HTTP "POST" request with
"x-www-form-urlencoded" formatted parameters using a character parameters formatted with "x-www-form-urlencoded" using a character
encoding of UTF-8 as described in Appendix B of [RFC6749]. If encoding of UTF-8, as described in Appendix B of [RFC6749]. If
applicable, the client also adds its authentication credentials to applicable, the client also adds its authentication credentials to
the request header or the request body using the same rules as for the request header or the request body using the same rules as for
token endpoint requests. token endpoint requests.
This is illustrated by the following example (extra line breaks in This is illustrated by the following example (extra line breaks in
the message body for display purposes only): the message body for display purposes only):
POST /as/par HTTP/1.1 POST /as/par HTTP/1.1
Host: as.example.com Host: as.example.com
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
skipping to change at page 8, line 41 skipping to change at line 352
parameter is provided. parameter is provided.
3. Validate the pushed request as it would an authorization request 3. Validate the pushed request as it would an authorization request
sent to the authorization endpoint. For example, the sent to the authorization endpoint. For example, the
authorization server checks whether the redirect URI matches one authorization server checks whether the redirect URI matches one
of the redirect URIs configured for the client and also checks of the redirect URIs configured for the client and also checks
whether the client is authorized for the scope for which it is whether the client is authorized for the scope for which it is
requesting access. This validation allows the authorization requesting access. This validation allows the authorization
server to refuse unauthorized or fraudulent requests early. The server to refuse unauthorized or fraudulent requests early. The
authorization server MAY omit validation steps that it is unable authorization server MAY omit validation steps that it is unable
to perform when processing the pushed request, however, such to perform when processing the pushed request; however, such
checks MUST then be performed when processing the authorization checks MUST then be performed when processing the authorization
request at the authorization endpoint. request at the authorization endpoint.
The authorization server MAY allow clients with authentication The authorization server MAY allow clients with authentication
credentials to establish per-authorization-request redirect URIs with credentials to establish per-authorization-request redirect URIs with
every pushed authorization request. Described in more detail in every pushed authorization request. Described in more detail in
Section 2.4, this is possible since, in contrast to [RFC6749], this Section 2.4, this is possible since, in contrast to [RFC6749], this
specification gives the authorization server the ability to specification gives the authorization server the ability to
authenticate clients and validate client requests before the actual authenticate clients and validate client requests before the actual
authorization request is performed. authorization request is performed.
2.2. Successful Response 2.2. Successful Response
If the verification is successful, the server MUST generate a request If the verification is successful, the server MUST generate a request
URI and provide it in the response with a "201" HTTP status code. URI and provide it in the response with a "201" HTTP status code.
The following parameters are included as top-level members in the The following parameters are included as top-level members in the
message body of the HTTP response using the "application/json" media message body of the HTTP response using the "application/json" media
type as defined by [RFC8259]. type as defined by [RFC8259].
* "request_uri" : The request URI corresponding to the authorization request_uri
request posted. This URI is a single-use reference to the The request URI corresponding to the authorization request posted.
respective request data in the subsequent authorization request. This URI is a single-use reference to the respective request data
The way the authorization process obtains the authorization in the subsequent authorization request. The way the
request data is at the discretion of the authorization server and authorization process obtains the authorization request data is at
out of scope of this specification. There is no need to make the the discretion of the authorization server and is out of scope of
authorization request data available to other parties via this this specification. There is no need to make the authorization
URI. request data available to other parties via this URI.
* "expires_in" : A JSON number that represents the lifetime of the expires_in
request URI in seconds as a positive integer. The request URI A JSON number that represents the lifetime of the request URI in
lifetime is at the discretion of the authorization server but will seconds as a positive integer. The request URI lifetime is at the
typically be relatively short (e.g., between 5 and 600 seconds). discretion of the authorization server but will typically be
relatively short (e.g., between 5 and 600 seconds).
The format of the "request_uri" value is at the discretion of the The format of the "request_uri" value is at the discretion of the
authorization server but it MUST contain some part generated using a authorization server, but it MUST contain some part generated using a
cryptographically strong pseudorandom algorithm such that it is cryptographically strong pseudorandom algorithm such that it is
computationally infeasible to predict or guess a valid value (see computationally infeasible to predict or guess a valid value (see
Section 10.10 of [RFC6749] for specifics). The authorization server Section 10.10 of [RFC6749] for specifics). The authorization server
MAY construct the "request_uri" value using the form MAY construct the "request_uri" value using the form
"urn:ietf:params:oauth:request_uri:<reference-value>" with "urn:ietf:params:oauth:request_uri:<reference-value>" with
"<reference-value>" as the random part of the URI that references the "<reference-value>" as the random part of the URI that references the
respective authorization request data. respective authorization request data.
The "request_uri" value MUST be bound to the client that posted the The "request_uri" value MUST be bound to the client that posted the
authorization request. authorization request.
skipping to change at page 10, line 13 skipping to change at line 420
} }
2.3. Error Response 2.3. Error Response
The authorization server returns an error response with the same The authorization server returns an error response with the same
format as is specified for error responses from the token endpoint in format as is specified for error responses from the token endpoint in
Section 5.2 of [RFC6749] using the appropriate error code from Section 5.2 of [RFC6749] using the appropriate error code from
therein or from Section 4.1.2.1 of [RFC6749]. In those cases where therein or from Section 4.1.2.1 of [RFC6749]. In those cases where
Section 4.1.2.1 of [RFC6749] prohibits automatic redirection with an Section 4.1.2.1 of [RFC6749] prohibits automatic redirection with an
error back to the requesting client and hence doesn't define an error error back to the requesting client and hence doesn't define an error
code, for example when the request fails due to a missing, invalid, code (for example, when the request fails due to a missing, invalid,
or mismatching redirection URI, the "invalid_request" error code can or mismatching redirection URI), the "invalid_request" error code can
be used as the default error code. Error codes defined by OAuth be used as the default error code. Error codes defined by the OAuth
extension can also be used when such an extension is involved in the extension can also be used when such an extension is involved in the
initial processing of authorization request that was pushed. Since initial processing of the authorization request that was pushed.
initial processing of the pushed authorization request does not Since initial processing of the pushed authorization request does not
involve resource owner interaction, error codes related to user involve resource owner interaction, error codes related to user
interaction, such as "consent_required" defined by [OIDC], are never interaction, such as "consent_required" defined by [OIDC], are never
returned. returned.
If the client is required to use signed request objects, either by If the client is required to use signed Request Objects, by either
authorization server or client policy (see [I-D.ietf-oauth-jwsreq], the authorization server or the client policy (see [RFC9101],
section 10.5), the authorization server MUST only accept requests Section 10.5), the authorization server MUST only accept requests
complying with the definition given in Section 3 and MUST refuse any complying with the definition given in Section 3 and MUST refuse any
other request with HTTP status code 400 and error code other request with HTTP status code 400 and error code
"invalid_request". "invalid_request".
In addition to the above, the PAR endpoint can also make use of the In addition to the above, the PAR endpoint can also make use of the
following HTTP status codes: following HTTP status codes:
* 405: If the request did not use the "POST" method, the 405: If the request did not use the "POST" method, the authorization
authorization server responds with an HTTP 405 (Method Not server responds with an HTTP 405 (Method Not Allowed) status
Allowed) status code. code.
* 413: If the request size was beyond the upper bound that the 413: If the request size was beyond the upper bound that the
authorization server allows, the authorization server responds authorization server allows, the authorization server responds
with an HTTP 413 (Payload Too Large) status code. with an HTTP 413 (Payload Too Large) status code.
* 429: If the number of requests from a client during a particular 429: If the number of requests from a client during a particular
time period exceeds the number the authorization server allows, time period exceeds the number the authorization server allows,
the authorization server responds with an HTTP 429 (Too Many the authorization server responds with an HTTP 429 (Too Many
Requests) status code. Requests) status code.
The following is an example of an error response from the PAR The following is an example of an error response from the PAR
endpoint: endpoint:
HTTP/1.1 400 Bad Request HTTP/1.1 400 Bad Request
Content-Type: application/json Content-Type: application/json
Cache-Control: no-cache, no-store Cache-Control: no-cache, no-store
{ {
"error": "invalid_request", "error": "invalid_request",
"error_description": "error_description":
"The redirect_uri is not valid for the given client" "The redirect_uri is not valid for the given client"
} }
2.4. Management of Client Redirect URIs 2.4. Management of Client Redirect URIs
OAuth 2.0 [RFC6749] allows clients to use unregistered "redirect_uri" OAuth 2.0 [RFC6749] allows clients to use unregistered "redirect_uri"
values in certain circumstances or for the authorization server to values in certain circumstances or for the authorization server to
apply its own matching semantics to the "redirect_uri" value apply its own matching semantics to the "redirect_uri" value
presented by the client at the authorization endpoint. However, the presented by the client at the authorization endpoint. However, the
OAuth Security BCP [I-D.ietf-oauth-security-topics] as well as OAuth OAuth security BCP [OAUTH-SECURITY-TOPICS] as well as the OAuth 2.1
2.1 [I-D.ietf-oauth-v2-1] require an authorization server exactly specification [OAUTH-V2] require an authorization server to exactly
match the "redirect_uri" parameter against the set of redirect URIs match the "redirect_uri" parameter against the set of redirect URIs
previously established for a particular client. This is a means for previously established for a particular client. This is a means for
early detection of client impersonation attempts and prevents token early detection of client impersonation attempts and prevents token
leakage and open redirection. As a downside, this can make client leakage and open redirection. As a downside, this can make client
management more cumbersome since the redirect URI is typically the management more cumbersome since the redirect URI is typically the
most volatile part of a client policy. most volatile part of a client policy.
The exact matching requirement MAY be relaxed when using PAR for The exact matching requirement MAY be relaxed when using PAR for
clients that have established authentication credentials with the clients that have established authentication credentials with the
authorization server. This is possible since, in contrast to a authorization server. This is possible since, in contrast to a
traditional authorization request, the authorization server conventional authorization request, the authorization server
authenticates the client before the authorization process starts and authenticates the client before the authorization process starts and
thus ensures it is interacting with the legitimate client. The thus ensures it is interacting with the legitimate client. The
authorization server MAY allow such clients to specify "redirect_uri" authorization server MAY allow such clients to specify "redirect_uri"
values that were not previously registered with the authorization values that were not previously registered with the authorization
server. This will give the client more flexibility (e.g., to mint server. This will give the client more flexibility (e.g., to mint
distinct redirect URI values per authorization server at runtime) and distinct "redirect_uri" values per authorization server at runtime)
can simplify client management. It is at the discretion of the and can simplify client management. It is at the discretion of the
authorization server to apply restrictions on supplied "redirect_uri" authorization server to apply restrictions on supplied "redirect_uri"
values, e.g., the authorization server MAY require a certain URI values, e.g., the authorization server MAY require a certain URI
prefix or allow only a query parameter to vary at runtime. prefix or allow only a query parameter to vary at runtime.
Note: The ability to set up transaction specific redirect URIs is | Note: The ability to set up transaction-specific redirect URIs
also useful in situations where client ids and corresponding | is also useful in situations where client IDs and corresponding
credentials and policies are managed by a trusted 3rd party, e.g. via | credentials and policies are managed by a trusted third party,
client certificates containing client permissions. Such an | e.g., via client certificates containing client permissions.
externally managed client could interact with an authorization server | Such an externally managed client could interact with an
trusting the respective 3rd party without the need for an additional | authorization server trusting the respective third party
registration step. | without the need for an additional registration step.
3. The "request" Request Parameter 3. The "request" Request Parameter
Clients MAY use the "request" parameter as defined in JAR Clients MAY use the "request" parameter as defined in JAR [RFC9101]
[I-D.ietf-oauth-jwsreq] to push a request object JWT to the to push a Request Object JWT to the authorization server. The rules
authorization server. The rules for processing, signing, and for processing, signing, and encryption of the Request Object as
encryption of the request object as defined in JAR defined in JAR [RFC9101] apply. Request parameters required by a
[I-D.ietf-oauth-jwsreq] apply. Request parameters required by a
given client authentication method are included in the "application/ given client authentication method are included in the "application/
x-www-form-urlencoded" request directly, and are the only parameters x-www-form-urlencoded" request directly and are the only parameters
other than "request" in the form body (e.g. Mutual TLS client other than "request" in the form body (e.g., mutual TLS client
authentication [RFC8705] uses the "client_id" HTTP request parameter authentication [RFC8705] uses the "client_id" HTTP request parameter,
while JWT assertion based client authentication [RFC7523] uses while JWT assertion-based client authentication [RFC7523] uses
"client_assertion" and "client_assertion_type"). All other request "client_assertion" and "client_assertion_type"). All other request
parameters, i.e., those pertaining to the authorization request parameters, i.e., those pertaining to the authorization request
itself, MUST appear as claims of the JWT representing the itself, MUST appear as claims of the JWT representing the
authorization request. authorization request.
The following is an example of a pushed authorization request using a The following is an example of a pushed authorization request using a
signed request object with the same authorization request payload as signed Request Object with the same authorization request payload as
the example in Section 2.1. The client is authenticated with JWT the example in Section 2.1. The client is authenticated with JWT
client assertion based authentication [RFC7523] (extra line breaks client assertion-based authentication [RFC7523] (extra line breaks
and whitespace for display purposes only): and spaces for display purposes only):
POST /as/par HTTP/1.1 POST /as/par HTTP/1.1
Host: as.example.com Host: as.example.com
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
client_assertion_type= client_assertion_type=
urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3Mi &client_assertion=eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3Mi
OiJzNkJoZFJrcXQzIiwic3ViIjoiczZCaGRSa3F0MyIsImF1ZCI6Imh0dHBzOi8vc OiJzNkJoZFJrcXQzIiwic3ViIjoiczZCaGRSa3F0MyIsImF1ZCI6Imh0dHBzOi8vc
2VydmVyLmV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY5Njc3fQ.te4IdnP_DK4hWrh 2VydmVyLmV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY5Njc3fQ.te4IdnP_DK4hWrh
skipping to change at page 13, line 38 skipping to change at line 559
BZ0B3VQZ9_KYdPt5bTkaflS5fSDklM3_7my9MyOSKFYmf46INk6ju_qUuC2crkOQX BZ0B3VQZ9_KYdPt5bTkaflS5fSDklM3_7my9MyOSKFYmf46INk6ju_qUuC2crkOQX
ZWYJB-0bnYEbdHpUjazFSUvN49cEGstNQeE-dKDWHNgEojgcuNA_pjKfL9VYp1dEA ZWYJB-0bnYEbdHpUjazFSUvN49cEGstNQeE-dKDWHNgEojgcuNA_pjKfL9VYp1dEA
6-WjXZ_OlJ7R_mBWpjFAzc0UkQwqX5hfOJoGTqB2tE4a4aB2z8iYlUJp0DeeYp_hP 6-WjXZ_OlJ7R_mBWpjFAzc0UkQwqX5hfOJoGTqB2tE4a4aB2z8iYlUJp0DeeYp_hP
N6svtmdvte73p5bLGDFpRIlmrBQIAQuxiS0skORpXlS0cBcgHimXVnXOJG7E-A_lS N6svtmdvte73p5bLGDFpRIlmrBQIAQuxiS0skORpXlS0cBcgHimXVnXOJG7E-A_lS
_5y54dVLQPA1jKYx-fxbYSG7dp2fw _5y54dVLQPA1jKYx-fxbYSG7dp2fw
&client_id=s6BhdRkqt3 &client_id=s6BhdRkqt3
The authorization server MUST take the following steps beyond the The authorization server MUST take the following steps beyond the
processing rules defined in Section 2.1: processing rules defined in Section 2.1:
1. If applicable, decrypt the request object as specified in JAR 1. If applicable, decrypt the Request Object as specified in JAR
[I-D.ietf-oauth-jwsreq], section 6.1. [RFC9101], Section 6.1.
2. Validate the request object signature as specified in JAR 2. Validate the Request Object signature as specified in JAR
[I-D.ietf-oauth-jwsreq], section 6.2. [RFC9101], Section 6.2.
3. If the client has authentication credentials established with the 3. If the client has authentication credentials established with the
authorization server, reject the request if the authenticated authorization server, reject the request if the authenticated
"client_id" does not match the "client_id" claim in the request "client_id" does not match the "client_id" claim in the Request
object. Additionally requiring the "iss" claim to match the Object. Additionally, requiring the "iss" claim to match the
"client_id" is at the discretion of authorization server. "client_id" is at the discretion of the authorization server.
The following RSA key pair, represented in JWK [RFC7517] format, can The following RSA key pair, represented in JSON Web Key (JWK) format
be used to validate or recreate the request object signature in the [RFC7517], can be used to validate or recreate the Request Object
above example (extra line breaks and indentation within values for signature in the above example (extra line breaks and indentation
display purposes only): within values for display purposes only):
{ {
"kty": "RSA", "kty": "RSA",
"kid":"k2bdc", "kid":"k2bdc",
"n": "y9Lqv4fCp6Ei-u2-ZCKq83YvbFEk6JMs_pSj76eMkddWRuWX2aBKGHAtKlE "n": "y9Lqv4fCp6Ei-u2-ZCKq83YvbFEk6JMs_pSj76eMkddWRuWX2aBKGHAtKlE
5P7_vn__PCKZWePt3vGkB6ePgzAFu08NmKemwE5bQI0e6kIChtt_6KzT5Oa 5P7_vn__PCKZWePt3vGkB6ePgzAFu08NmKemwE5bQI0e6kIChtt_6KzT5Oa
aXDFI6qCLJmk51Cc4VYFaxgqevMncYrzaW_50mZ1yGSFIQzLYP8bijAHGVj aXDFI6qCLJmk51Cc4VYFaxgqevMncYrzaW_50mZ1yGSFIQzLYP8bijAHGVj
dEFgZaZEN9lsn_GdWLaJpHrB3ROlS50E45wxrlg9xMncVb8qDPuXZarvghL dEFgZaZEN9lsn_GdWLaJpHrB3ROlS50E45wxrlg9xMncVb8qDPuXZarvghL
L0HzOuYRadBJVoWZowDNTpKpk2RklZ7QaBO7XDv3uR7s_sf2g-bAjSYxYUG L0HzOuYRadBJVoWZowDNTpKpk2RklZ7QaBO7XDv3uR7s_sf2g-bAjSYxYUG
sqkNA9b3xVW53am_UZZ3tZbFTIh557JICWKHlWj5uzeJXaw", sqkNA9b3xVW53am_UZZ3tZbFTIh557JICWKHlWj5uzeJXaw",
skipping to change at page 14, line 47 skipping to change at line 613
zpAeYtCT82jxroB2XqhLxGeMxEPQpsz2qTKLSe4BgHY2ml2uxSDGdjcsrbb zpAeYtCT82jxroB2XqhLxGeMxEPQpsz2qTKLSe4BgHY2ml2uxSDGdjcsrbb
NoKUKaN1CuyZszhWl1n0AT_bENl4bJgQj_Fh0UEsQj5YBBUJt5gr_k", NoKUKaN1CuyZszhWl1n0AT_bENl4bJgQj_Fh0UEsQj5YBBUJt5gr_k",
"dp": "Zc877jirkkLOtyTs2vxyNe9KnMNAmOidlUc2tE_-0gAL4Lpo1hSwKCtKwe "dp": "Zc877jirkkLOtyTs2vxyNe9KnMNAmOidlUc2tE_-0gAL4Lpo1hSwKCtKwe
ZJ-gkqt1hT-dwNx_0Xtg_-NXsadMRMwJnzBMYwYAfjApUkfqABc0yUCJJl3 ZJ-gkqt1hT-dwNx_0Xtg_-NXsadMRMwJnzBMYwYAfjApUkfqABc0yUCJJl3
KozRCugf1WXkU9GZAH2_x8PUopdNUEa70ISowPRh04HANKX4fkjWAE" KozRCugf1WXkU9GZAH2_x8PUopdNUEa70ISowPRh04HANKX4fkjWAE"
} }
4. Authorization Request 4. Authorization Request
The client uses the "request_uri" value returned by the authorization The client uses the "request_uri" value returned by the authorization
server to build an authorization request as defined in server to build an authorization request as defined in [RFC9101].
[I-D.ietf-oauth-jwsreq]. This is shown in the following example This is shown in the following example where the client directs the
where the client directs the user agent to make the following HTTP user agent to make the following HTTP request (extra line breaks and
request (extra line breaks and indentation for display purposes indentation for display purposes only):
only):
GET /authorize?client_id=s6BhdRkqt3&request_uri=urn%3Aietf%3Aparams GET /authorize?client_id=s6BhdRkqt3&request_uri=urn%3Aietf%3Aparams
%3Aoauth%3Arequest_uri%3A6esc_11ACC5bwc014ltc14eY22c HTTP/1.1 %3Aoauth%3Arequest_uri%3A6esc_11ACC5bwc014ltc14eY22c HTTP/1.1
Host: as.example.com Host: as.example.com
Since parts of the authorization request content, e.g. the Since parts of the authorization request content, e.g., the
"code_challenge" parameter value, are unique to a particular "code_challenge" parameter value, are unique to a particular
authorization request, the client MUST only use a "request_uri" value authorization request, the client MUST only use a "request_uri" value
once. Authorization servers SHOULD treat "request_uri" values as once. Authorization servers SHOULD treat "request_uri" values as
one-time use but MAY allow for duplicate requests due to a user one-time use but MAY allow for duplicate requests due to a user
reloading/refreshing their user agent. An expired "request_uri" MUST reloading/refreshing their user agent. An expired "request_uri" MUST
be rejected as invalid. be rejected as invalid.
The authorization server MUST validate authorization requests arising The authorization server MUST validate authorization requests arising
from a pushed request as it would any other authorization request. from a pushed request as it would any other authorization request.
The authorization server MAY omit validation steps that it performed The authorization server MAY omit validation steps that it performed
when the request was pushed, provided that it can validate that the when the request was pushed, provided that it can validate that the
request was a pushed request, and that the request or the request was a pushed request and that the request or the
authorization server's policy has not been modified in a way that authorization server's policy has not been modified in a way that
would affect the outcome of the omitted steps. would affect the outcome of the omitted steps.
Authorization server policy MAY dictate, either globally or on a per- Authorization server policy MAY dictate, either globally or on a per-
client basis, that PAR is the only means for a client to pass client basis, that PAR be the only means for a client to pass
authorization request data. In this case, the authorization server authorization request data. In this case, the authorization server
will refuse, using the "invalid_request" error code, to process any will refuse, using the "invalid_request" error code, to process any
request to the authorization endpoint that does not have a request to the authorization endpoint that does not have a
"request_uri" parameter with a value obtained from the PAR endpoint. "request_uri" parameter with a value obtained from the PAR endpoint.
Note: authorization server and clients MAY use metadata as defined in | Note: Authorization server and clients MAY use metadata as
Section 5 and Section 6 to signal the desired behavior. | defined in Sections 5 and 6 to signal the desired behavior.
5. Authorization Server Metadata 5. Authorization Server Metadata
The following authorization server metadata [RFC8414] parameters are The following authorization server metadata parameters [RFC8414] are
introduced to signal the server's capability and policy with respect introduced to signal the server's capability and policy with respect
to PAR. to PAR.
"pushed_authorization_request_endpoint" The URL of the pushed pushed_authorization_request_endpoint
authorization request endpoint at which a client can post an The URL of the pushed authorization request endpoint at which a
authorization request to exchange for a "request_uri" value usable client can post an authorization request to exchange for a
at the authorization server. "request_uri" value usable at the authorization server.
"require_pushed_authorization_requests" Boolean parameter indicating require_pushed_authorization_requests
whether the authorization server accepts authorization request Boolean parameter indicating whether the authorization server
data only via PAR. If omitted, the default value is "false". accepts authorization request data only via PAR. If omitted, the
default value is "false".
Note that the presence of "pushed_authorization_request_endpoint" is Note that the presence of "pushed_authorization_request_endpoint" is
sufficient for a client to determine that it may use the PAR flow. A sufficient for a client to determine that it may use the PAR flow. A
"request_uri" value obtained from the PAR endpoint is usable at the "request_uri" value obtained from the PAR endpoint is usable at the
authorization endpoint regardless of other authorization server authorization endpoint regardless of other authorization server
metadata such as "request_uri_parameter_supported" or metadata such as "request_uri_parameter_supported" or
"require_request_uri_registration" [OIDC.Disco]. "require_request_uri_registration" [OIDC.Disco].
6. Client Metadata 6. Client Metadata
skipping to change at page 16, line 21 skipping to change at line 684
dynamically registering OAuth 2.0 client metadata with authorization dynamically registering OAuth 2.0 client metadata with authorization
servers. The metadata defined by [RFC7591], and registered servers. The metadata defined by [RFC7591], and registered
extensions to it, also imply a general data model for clients that is extensions to it, also imply a general data model for clients that is
useful for authorization server implementations even when the Dynamic useful for authorization server implementations even when the Dynamic
Client Registration Protocol isn't in play. Such implementations Client Registration Protocol isn't in play. Such implementations
will typically have some sort of user interface available for will typically have some sort of user interface available for
managing client configuration. The following client metadata managing client configuration. The following client metadata
parameter is introduced by this document to indicate whether pushed parameter is introduced by this document to indicate whether pushed
authorization requests are required for the given client. authorization requests are required for the given client.
"require_pushed_authorization_requests" Boolean parameter indicating require_pushed_authorization_requests
whether the only means of initiating an authorization request the Boolean parameter indicating whether the only means of initiating
client is allowed to use is PAR. If omitted, the default value is an authorization request the client is allowed to use is PAR. If
"false". omitted, the default value is "false".
7. Security Considerations 7. Security Considerations
7.1. Request URI Guessing 7.1. Request URI Guessing
An attacker could attempt to guess and replay a valid request URI An attacker could attempt to guess and replay a valid request URI
value and try to impersonate the respective client. The value and try to impersonate the respective client. The
authorization server MUST consider the considerations given in JAR authorization server MUST account for the considerations given in JAR
[I-D.ietf-oauth-jwsreq], section 10.2, clause (d) on request URI [RFC9101], Section 10.2, clause (d) on request URI entropy.
entropy.
7.2. Open Redirection 7.2. Open Redirection
An attacker could try to register a redirect URI pointing to a site An attacker could try to register a redirect URI pointing to a site
under his control in order to obtain authorization codes or launch under their control in order to obtain authorization codes or launch
other attacks towards the user. The authorization server MUST only other attacks towards the user. The authorization server MUST only
accept new redirect URIs in the pushed authorization request from accept new redirect URIs in the pushed authorization request from
authenticated clients. authenticated clients.
7.3. Request Object Replay 7.3. Request Object Replay
An attacker could replay a request URI captured from a legitimate An attacker could replay a request URI captured from a legitimate
authorization request. In order to cope with such attacks, the authorization request. In order to cope with such attacks, the
authorization server SHOULD make the request URIs one-time use. authorization server SHOULD make the request URIs one-time use.
7.4. Client Policy Change 7.4. Client Policy Change
The client policy might change between the lodging of the request The client policy might change between the lodging of the Request
object and the authorization request using a particular request Object and the authorization request using a particular Request
object. It is therefore recommended that the authorization server Object. Therefore, it is recommended that the authorization server
check the request parameter against the client policy when processing check the request parameter against the client policy when processing
the authorization request. the authorization request.
7.5. Request URI Swapping 7.5. Request URI Swapping
An attacker could capture the request URI from one request and then An attacker could capture the request URI from one request and then
substitute it into a different authorization request. For example, substitute it into a different authorization request. For example,
in the context of OpenID Connect, an attacker could replace a request in the context of OpenID Connect, an attacker could replace a request
URI asking for a high level of authentication assurance with one that URI asking for a high level of authentication assurance with one that
requires a lower level of assurance. Clients SHOULD make use of PKCE requires a lower level of assurance. Clients SHOULD make use of PKCE
[RFC7636], a unique "state" parameter [RFC6749], or the OIDC "nonce" [RFC7636], a unique "state" parameter [RFC6749], or the OIDC "nonce"
parameter [OIDC] in the pushed request object to prevent this attack. parameter [OIDC] in the pushed Request Object to prevent this attack.
8. Privacy Considerations 8. Privacy Considerations
OAuth 2.0 is a complex and flexible framework with broad-ranging OAuth 2.0 is a complex and flexible framework with broad-ranging
privacy implications due to the very nature of it having one entity privacy implications due to its very nature of having one entity
intermediate user authorization to data access between two other intermediate user authorization to data access between two other
entities. The privacy considerations of all of OAuth are beyond the entities. The privacy considerations of all of OAuth are beyond the
scope of this document, which only defines an alternative way of scope of this document, which only defines an alternative way of
initiating one message sequence in the larger framework. Using PAR, initiating one message sequence in the larger framework. However,
however, may improve privacy by reducing the potential for using PAR may improve privacy by reducing the potential for
inadvertent information disclosure since it passes the authorization inadvertent information disclosure since it passes the authorization
request data directly between client and authorization server over a request data directly between the client and authorization server
secure connection in the message body of an HTTP request, rather than over a secure connection in the message body of an HTTP request
in the query component of a URL that passes through the user agent in rather than in the query component of a URL that passes through the
the clear. user agent in the clear.
9. Acknowledgements
This specification is based on the work towards Pushed Request Object
(https://bitbucket.org/openid/fapi/src/master/
Financial_API_Pushed_Request_Object.md) conducted at the Financial-
grade API working group at the OpenID Foundation. We would like to
thank the members of the WG for their valuable contributions.
We would like to thank Vladimir Dzhuvinov, Aaron Parecki, Justin
Richer, Sascha Preibisch, Daniel Fett, Michael B. Jones, Annabelle
Backman, Joseph Heenan, Sean Glencross, Maggie Hung, Neil Madden,
Karsten Meyer zu Selhausen, Roman Danyliw, Meral Shirazipour, and
Takahiko Kawasaki for their valuable feedback on this draft.
10. IANA Considerations 9. IANA Considerations
10.1. OAuth Authorization Server Metadata 9.1. OAuth Authorization Server Metadata
This specification requests registration of the following values in IANA has registered the following values in the IANA "OAuth
the IANA "OAuth Authorization Server Metadata" registry of Authorization Server Metadata" registry of [IANA.OAuth.Parameters]
[IANA.OAuth.Parameters] established by [RFC8414]. established by [RFC8414].
Metadata Name: "pushed_authorization_request_endpoint" Metadata Name: "pushed_authorization_request_endpoint"
Metadata Description: URL of the authorization server's pushed Metadata Description: URL of the authorization server's pushed
authorization request endpoint authorization request endpoint.
Change Controller: IESG Change Controller: IESG
Specification Document(s): Section 5 of [[ this document ]] Specification Document(s): Section 5 of RFC 9126
Metadata Name: "require_pushed_authorization_requests" Metadata Name: "require_pushed_authorization_requests"
Metadata Description: Indicates whether the authorization server Metadata Description: Indicates whether the authorization server
accepts authorization requests only via PAR. accepts authorization requests only via PAR.
Change Controller: IESG Change Controller: IESG
Specification Document(s): Section 5 of [[ this document ]] Specification Document(s): Section 5 of RFC 9126
10.2. OAuth Dynamic Client Registration Metadata 9.2. OAuth Dynamic Client Registration Metadata
This specification requests registration of the following value in IANA has registered the following value in the IANA "OAuth Dynamic
the IANA "OAuth Dynamic Client Registration Metadata" registry of Client Registration Metadata" registry of [IANA.OAuth.Parameters]
[IANA.OAuth.Parameters] established by [RFC7591]. established by [RFC7591].
Client Metadata Name: "require_pushed_authorization_requests" Client Metadata Name: "require_pushed_authorization_requests"
Client Metadata Description: Indicates whether the client is Client Metadata Description: Indicates whether the client is
required to use the PAR to initiate authorization requests. required to use PAR to initiate authorization requests.
Change Controller: IESG Change Controller: IESG
Specification Document(s): Section 6 of [[ this document ]] Specification Document(s): Section 6 of RFC 9126
10.3. OAuth URI Registration 9.3. OAuth URI Registration
This specification requests registration of the following value in IANA has registered the following value in the "OAuth URI" registry
the "OAuth URI" registry of [IANA.OAuth.Parameters] established by of [IANA.OAuth.Parameters] established by [RFC6755].
[RFC6755].
URN: "urn:ietf:params:oauth:request_uri:" URN: "urn:ietf:params:oauth:request_uri:"
Common Name: A URN Sub-Namespace for OAuth Request URIs. Common Name: A URN Sub-Namespace for OAuth Request URIs.
Change Controller: IESG Change Controller: IESG
Specification Document(s): Section 2.2 of [[ this document ]] Specification Document(s): Section 2.2 of RFC 9126
11. Normative References 10. References
[I-D.ietf-oauth-jwsreq] 10.1. Normative References
Sakimura, N., Bradley, J., and M. B. Jones, "The OAuth 2.0
Authorization Framework: JWT Secured Authorization Request
(JAR)", Work in Progress, Internet-Draft, draft-ietf-
oauth-jwsreq-34, 8 April 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
jwsreq-34>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
skipping to change at page 19, line 32 skipping to change at line 814
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", RFC 8414, Authorization Server Metadata", RFC 8414,
DOI 10.17487/RFC8414, June 2018, DOI 10.17487/RFC8414, June 2018,
<https://www.rfc-editor.org/info/rfc8414>. <https://www.rfc-editor.org/info/rfc8414>.
12. Informative References [RFC9101] Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0
Authorization Framework: JWT-Secured Authorization Request
(JAR)", RFC 9101, DOI 10.17487/RFC9101, August 2021,
<https://www.rfc-editor.org/info/rfc9101>.
[I-D.ietf-oauth-security-topics] 10.2. Informative References
[IANA.OAuth.Parameters]
IANA, "OAuth Parameters",
<http://www.iana.org/assignments/oauth-parameters>.
[OAUTH-SECURITY-TOPICS]
Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
"OAuth 2.0 Security Best Current Practice", Work in "OAuth 2.0 Security Best Current Practice", Work in
Progress, Internet-Draft, draft-ietf-oauth-security- Progress, Internet-Draft, draft-ietf-oauth-security-
topics-18, 13 April 2021, topics-18, 13 April 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth- <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
security-topics-18>. security-topics-18>.
[I-D.ietf-oauth-v2-1] [OAUTH-V2] Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1
Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1
Authorization Framework", Work in Progress, Internet- Authorization Framework", Work in Progress, Internet-
Draft, draft-ietf-oauth-v2-1-02, 15 March 2021, Draft, draft-ietf-oauth-v2-1-03, 8 September 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth- <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
v2-1-02>. v2-1-03>.
[IANA.OAuth.Parameters]
IANA, "OAuth Parameters",
<http://www.iana.org/assignments/oauth-parameters>.
[OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and [OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0 incorporating C. Mortimore, "OpenID Connect Core 1.0 incorporating
errata set 1", 8 November 2014, errata set 1", November 2014,
<http://openid.net/specs/openid-connect-core-1_0.html>. <http://openid.net/specs/openid-connect-core-1_0.html>.
[OIDC.Disco] [OIDC.Disco]
Sakimura, N., Bradley, J., Jones, M.B., and E. Jay, Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID
"OpenID Connect Discovery 1.0", 8 November 2014, Connect Discovery 1.0 incorporating errata set 1",
<http://openid.net/specs/openid-connect-discovery- November 2014, <http://openid.net/specs/openid-connect-
1_0.html>. discovery-1_0.html>.
[RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012, for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012,
<https://www.rfc-editor.org/info/rfc6755>. <https://www.rfc-editor.org/info/rfc6755>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015, DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>. <https://www.rfc-editor.org/info/rfc7517>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
skipping to change at page 21, line 9 skipping to change at line 891
[RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T.
Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication
and Certificate-Bound Access Tokens", RFC 8705, and Certificate-Bound Access Tokens", RFC 8705,
DOI 10.17487/RFC8705, February 2020, DOI 10.17487/RFC8705, February 2020,
<https://www.rfc-editor.org/info/rfc8705>. <https://www.rfc-editor.org/info/rfc8705>.
[RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource [RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource
Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707,
February 2020, <https://www.rfc-editor.org/info/rfc8707>. February 2020, <https://www.rfc-editor.org/info/rfc8707>.
Appendix A. Document History Acknowledgements
[[ To be removed from the final specification ]]
-10
* Updates from mistakenly overlooked IESG evaluation comments
-09
* Editorial fixes from Genart last call review
* Updates from IESG evaluation comments
-08
* Updates to address feedback from AD Review
https://mailarchive.ietf.org/arch/msg/oauth/
bGSyonUqsvJ1vtY7l_ohwov25SA/
(https://mailarchive.ietf.org/arch/msg/oauth/
bGSyonUqsvJ1vtY7l_ohwov25SA/)
-07
* updated references (however they did not actually update due to
tooling issues - some info in this thread:
https://mailarchive.ietf.org/arch/msg/xml2rfc/
zqYiMxZ070SCIi7CRNF9vbDeYno/
(https://mailarchive.ietf.org/arch/msg/xml2rfc/
zqYiMxZ070SCIi7CRNF9vbDeYno/) )
-06
* Add a note clarifying that the presence of
"pushed_authorization_request_endpoint" is sufficient for a client
to know that it can use the PAR flow
-05
* Mention use of "invalid_request" error code for cases, like a bad
"redirect_uri", that don't have a more specific one
-04
* Edits to address WGLC comments
* Replace I-D.ietf-oauth-mtls reference with now published RFC8705
* Moved text about redirect URI management from introduction into
separate section
-03
* Editorial updates
* Mention that https is required for the PAR endpoint
* Add some discussion of browser form posting an authz request vs.
the benefits of PAR for any application
* Added text about motivations behind PAR - integrity,
confidentiality and early client auth
* Better explain one-time use recommendation of the request_uri
* Drop the section on special error responses for request objects
* Clarify authorization request examples to say that the client
directs the user agent to make the HTTP GET request (vs. making
the request itself)
-02
* Update Resource Indicators reference to the somewhat recently
published RFC 8707
* Added metadata in support of pushed authorization requests only
feature
* Update to comply with draft-ietf-oauth-jwsreq-21, which requires
"client_id" in the authorization request in addition to the
"request_uri"
* Clarified timing of request validation
* Add some guidance/options on the request URI structure
* Add the key used in the request object example so that a reader
could validate or recreate the request object signature
* Update to draft-ietf-oauth-jwsreq-25 and added note regarding
"require_signed_request_object"
-01
* Use the newish RFC v3 XML and HTML format
* Added IANA registration request for
"pushed_authorization_request_endpoint"
* Changed abbrev to "OAuth PAR"
-00 (WG draft)
* Reference RFC6749 sec 2.3.1 for client secret basic rather than
RFC7617
* further clarify that a request object JWT contains all the
authorization request parameters while client authentication
params, if applicable, are outside that JWT as regular form
encoded params in HTTP body
-01
* List "client_id" as one of the basic parameters
* Explicitly forbid "request_uri" in the processing rules
* Clarification regarding client authentication and that public
clients are allowed
* Added option to let clients register per-authorization request
redirect URIs
* General clean up and wording improvements
-00 This specification is based on the work on Pushed Request Object
(https://bitbucket.org/openid/fapi/src/master/
Financial_API_Pushed_Request_Object.md) conducted at the Financial-
grade API Working Group at the OpenID Foundation. We would like to
thank the members of the WG for their valuable contributions.
* first draft We would like to thank Vladimir Dzhuvinov, Aaron Parecki, Justin
Richer, Sascha Preibisch, Daniel Fett, Michael B. Jones, Annabelle
Backman, Joseph Heenan, Sean Glencross, Maggie Hung, Neil Madden,
Karsten Meyer zu Selhausen, Roman Danyliw, Meral Shirazipour, and
Takahiko Kawasaki for their valuable feedback on this document.
Authors' Addresses Authors' Addresses
Torsten Lodderstedt Torsten Lodderstedt
yes.com yes.com
Email: torsten@lodderstedt.net Email: torsten@lodderstedt.net
Brian Campbell Brian Campbell
Ping Identity Ping Identity
 End of changes. 90 change blocks. 
398 lines changed or deleted 272 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/