draft-ietf-oauth-par-03.txt   draft-ietf-oauth-par-04.txt 
Web Authorization Protocol T. Lodderstedt Web Authorization Protocol T. Lodderstedt
Internet-Draft yes.com Internet-Draft yes.com
Intended status: Standards Track B. Campbell Intended status: Standards Track B. Campbell
Expires: 1 February 2021 Ping Identity Expires: 22 March 2021 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
31 July 2020 18 September 2020
OAuth 2.0 Pushed Authorization Requests OAuth 2.0 Pushed Authorization Requests
draft-ietf-oauth-par-03 draft-ietf-oauth-par-04
Abstract Abstract
This document defines the pushed authorization request endpoint, This document defines the pushed authorization request endpoint,
which allows clients to push the payload of an OAuth 2.0 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 authorization request. reference to the data in a subsequent call to the authorization
endpoint.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 1 February 2021. This Internet-Draft will expire on 22 March 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 5 1.1. Introductory Example . . . . . . . . . . . . . . . . . . 4
1.2. Conventions and Terminology . . . . . . . . . . . . . . . 5
2. Pushed Authorization Request Endpoint . . . . . . . . . . . . 5 2. Pushed Authorization Request Endpoint . . . . . . . . . . . . 5
2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Successful Response . . . . . . . . . . . . . . . . . . . 8 2.2. Successful Response . . . . . . . . . . . . . . . . . . . 8
2.3. Error Response . . . . . . . . . . . . . . . . . . . . . 9 2.3. Error Response . . . . . . . . . . . . . . . . . . . . . 9
3. "request" Parameter . . . . . . . . . . . . . . . . . . . . . 10 2.4. Management of Client Redirect URIs . . . . . . . . . . . 10
4. Authorization Request . . . . . . . . . . . . . . . . . . . . 12 3. The "request" Request Parameter . . . . . . . . . . . . . . . 11
4. Authorization Request . . . . . . . . . . . . . . . . . . . . 13
5. Authorization Server Metadata . . . . . . . . . . . . . . . . 13 5. Authorization Server Metadata . . . . . . . . . . . . . . . . 13
6. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 13 6. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7.1. Request URI Guessing . . . . . . . . . . . . . . . . . . 14 7.1. Request URI Guessing . . . . . . . . . . . . . . . . . . 14
7.2. Open Redirection . . . . . . . . . . . . . . . . . . . . 14 7.2. Open Redirection . . . . . . . . . . . . . . . . . . . . 14
7.3. Request Object Replay . . . . . . . . . . . . . . . . . . 14 7.3. Request Object Replay . . . . . . . . . . . . . . . . . . 15
7.4. Client Policy Change . . . . . . . . . . . . . . . . . . 14 7.4. Client Policy Change . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 7.5. Request URI Swapping . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
9.1. OAuth Authorization Server Metadata . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
9.2. OAuth Dynamic Client Registration Metadata . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.3. OAuth URI Registration . . . . . . . . . . . . . . . . . 15 10.1. OAuth Authorization Server Metadata . . . . . . . . . . 16
10. Normative References . . . . . . . . . . . . . . . . . . . . 15 10.2. OAuth Dynamic Client Registration Metadata . . . . . . . 16
11. Informative References . . . . . . . . . . . . . . . . . . . 16 10.3. OAuth URI Registration . . . . . . . . . . . . . . . . . 16
Appendix A. Document History . . . . . . . . . . . . . . . . . . 17 11. Normative References . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 12. Informative References . . . . . . . . . . . . . . . . . . . 17
Appendix A. Document History . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
Pushed authorization requests (PAR), defined by this document, enable
OAuth [RFC6749] clients to push the payload of an authorization
request directly to the authorization server in exchange for a
request URI value, which is used as reference to the authorization
request payload data in a subsequent call to the 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 ACR value requested by An attacker could, for example, modify the scope of access
the client or swap the context of a payment transaction requested or swap the context of a payment transaction by changing
authorization by changing scope values. Although clients should scope values. Although protocol facilities exist to enable
detect such changes by inspecting the token response data, clients or users to detect some such changes, preventing
preventing such modifications early in the process would be a modifications early in the process is a more robust solution.
better solution.
* There is no mechanism to ensure confidentiality of the request * There is no mechanism to ensure confidentiality of the request
parameters. This obviously is an issue if personal identifiable parameters. Although HTTPS is required for the authorization
information is sent in the authorization request, which might be endpoint, the request data passes through the user-agent in the
the case in identity and open banking scenarios. clear and query string data can inadvertently leak to web server
logs and to other sites via referer. The impact of which can be
significant, if personal identifiable information or other
regulated data is sent in the authorization request (which might
well be the case in identity, open banking, and 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) [I-D.ietf-oauth-jwsreq]
provides solutions for the security challenges by allowing OAuth provides solutions for the security challenges by allowing OAuth
clients to wrap authorization request parameters in a signed, and clients to wrap authorization request parameters in a request object,
optionally encrypted, JSON Web Token (JWT), the so-called "Request which is a signed and optionally encrypted JSON Web Token (JWT)
Object". In order to cope with the size restrictions, JAR introduces [RFC7519]. In order to cope with the size restrictions, JAR
the "request_uri" parameter that allows clients to send a reference introduces the "request_uri" parameter that allows clients to send a
to a request object instead of the request object itself. reference to a 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 a request object directly to the authorization push the payload of an authorization request directly to the
server in exchange for a "request_uri". authorization server in exchange for a "request_uri" value usable at
the authorization server in a subsequent authorization request.
It also allows for clients to push the form encoded authorization PAR fosters OAuth security by providing clients a simple means for a
request parameters to the authorization server in order to exchange confidential and integrity protected authorization request. Clients
them for a request URI that the client can use in a subsequent requiring an even higher security level, especially cryptographically
confirmed non-repudiation, are able to use JWT-based request objects
as defined by [I-D.ietf-oauth-jwsreq] in conduction with a pushed
authorization request. authorization request.
For example, a client typically initiates an authorization request by PAR allows the authorization server to authenticate the client before
directing the user-agent to make an HTTP request like the following: any user interaction happens. The increased confidence in the
identity of the client during the authorization process allows the
authorization server to refuse illegitimate requests much earlier in
the process, which can prevent attempts to spoof clients or otherwise
tamper with or misuse an authorization request.
Note that HTTP "POST" requests to the authorization endpoint via the
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
request size limitations described above. However, it's only
optional per [RFC6749] and, even when supported, it is a viable
option for traditional web applications but is prohibitively
difficult to use with mobile apps. Those apps typically invoke a
custom tab with an URL that is translated into a GET request. Using
"POST" would require the app to first open a web page under its
control in the custom tab that in turn would initiate the form "POST"
towards the authorization server. PAR is simpler to use and has
additional security benefits as described above.
1.1. Introductory Example
A client typically initiates an authorization request by directing
the user-agent to make an HTTP request like the following to the
authorization server's authorization endpoint (extra line breaks and
indentation for display purposes only):
GET /authorize?response_type=code GET /authorize?response_type=code
&client_id=s6BhdRkqt3&state=af0ifjsldkj &client_id=s6BhdRkqt3&state=af0ifjsldkj
&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 as follows: server by the client as follows with a "POST" request to the pushed
authorization request endpoint (extra line breaks 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
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
response_type=code response_type=code
&client_id=s6BhdRkqt3&state=af0ifjsldkj &client_id=s6BhdRkqt3&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
skipping to change at page 4, line 21 skipping to change at page 5, line 10
&client_id=s6BhdRkqt3&state=af0ifjsldkj &client_id=s6BhdRkqt3&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
The authorization server responds with a request URI: The authorization server responds with a request URI:
HTTP/1.1 201 Created HTTP/1.1 201 Created
Cache-Control: no-cache, no-store Cache-Control: no-cache, no-store
Content-Type: application/json Content-Type: application/json
{ {
"request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2", "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2",
"expires_in": 90 "expires_in": 90
} }
The client uses the request URI value to create the subsequent The client uses the request URI value to create the subsequent
authorization request and directing the user-agent to make an HTTP authorization request by directing the user-agent to make an HTTP
request like the following: request to the authorization server's authorization endpoint like the
following (extra line breaks and indentation for display purposes
only):
GET /authorize?client_id=s6BhdRkqt3& GET /authorize?client_id=s6BhdRkqt3
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
The pushed authorization request endpoint fosters OAuth security by 1.2. Conventions and Terminology
providing all clients a simple means for a confidential and integrity
protected authorization request, but it also allows clients requiring
an even higher security level, especially cryptographically confirmed
non-repudiation, to explicitly adopt JWT-based request objects.
As a further benefit, the pushed authorization request allows the
authorization server to authenticate the clients before any user
interaction happens, i.e., the authorization server may refuse
unauthorized requests much earlier in the process and has much higher
confidence in the client's identity in the authorization process than
before. This generally improves security since it prevents attempts
to spoof confidential clients early in the process.
This is directly utilized by this draft to allow confidential clients
to set the redirect URI for every authorization request, which gives
them more flexibility in building redirect URI. And if the client
IDs and credentials are managed by some external authority (e.g. a
certification authority), explicit client registration with the
particular authorization server could practically be skipped.
Note: HTTP POST requests to the authorization endpoint as described
in Section 3.1 of [RFC6749] and Section 3.1.2.1 of [OIDC] could also
be used to cope with the request size limitations described above.
Although this is a viable option for traditional web applications,
it's difficult to use with mobile apps. Those apps typically invoke
a custom tab with an URL that is translated into a GET request.
Using POST would require the app to first open a web page under its
control in the custom tab that in turn would initiate the form POST
towards the authorization server. PAR is simpler to use and has
additional security benefits as described above.
1.1. 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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 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", "refresh token", This specification uses the terms "access token", "authorization
"authorization server", "resource server", "authorization endpoint", server", "authorization endpoint", "authorization request", "token
"authorization request", "authorization response", "token endpoint", endpoint", and "client" defined by The OAuth 2.0 Authorization
"grant type", "access token request", "access token response", and Framework [RFC6749].
"client" defined by The OAuth 2.0 Authorization 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 POST requests with parameters in authorization server that accepts HTTP "POST" requests with
the HTTP request entity-body using the "application/x-www-form- parameters in the HTTP request entity-body using the "application/x-
urlencoded" format with a character encoding of UTF-8 as described in www-form-urlencoded" format with a character encoding of UTF-8 as
Appendix B of [RFC6749]. The pushed authorization request endpoint described in Appendix B of [RFC6749]. The pushed authorization
URL MUST use the "https" scheme. request endpoint URL MUST use the "https" scheme.
Authorization servers supporting pushed authorization requests SHOULD Authorization servers supporting pushed authorization requests SHOULD
include the URL of their pushed authorization request endpoint in include the URL of their pushed authorization request endpoint in
their authorization server metadata document [RFC8414] using the their authorization server 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 parameters defined in [RFC6749] for the The endpoint accepts the authorization request parameters defined in
authorization endpoint as well as all applicable extensions defined [RFC6749] for the authorization endpoint as well as all applicable
for the authorization endpoint. Some examples of such extensions extensions defined for the authorization endpoint. Some examples of
include PKCE [RFC7636], Resource Indicators [RFC8707], and OpenID such extensions include PKCE [RFC7636], Resource Indicators
Connect [OIDC]. The endpoint also supports sending all authorization [RFC8707], and OpenID Connect [OIDC]. The endpoint MAY also support
request parameters as request object according to sending the set of authorization request parameters as a request
[I-D.ietf-oauth-jwsreq]. object according to [I-D.ietf-oauth-jwsreq] and Section 3.
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 pushed authorization request endpoint as well. If apply for the pushed authorization request endpoint as well. If
applicable, the "token_endpoint_auth_method" client metadata applicable, the "token_endpoint_auth_method" client metadata
parameter indicates the registered authentication method for the [RFC7591] parameter indicates the registered authentication method
client to use when making direct requests to the authorization for the client to use when making direct requests to the
server, including requests to the pushed authorization request authorization server, including requests to the pushed authorization
endpoint. request endpoint. Similarly, the
"token_endpoint_auth_methods_supported" authorization server metadata
[RFC8414] parameter lists client authentication methods supported by
the authorization server when accepting direct requests from clients,
including requests to the pushed authorization request endpoint.
Note that there's some potential ambiguity around the appropriate Due to historical reasons there is potential ambiguity regarding the
audience value to use when JWT client assertion based authentication appropriate audience value to use when employing JWT client assertion
is employed. To address that ambiguity the issuer identifier URL of based authentication (defined in Section 2.2 of [RFC7523] with
the authorization server according to [RFC8414] SHOULD be used as the "private_key_jwt" or "client_secret_jwt" authentication method names
value of the audience. In order to facilitate interoperability the per Section 9 of [OIDC]). To address that ambiguity the issuer
authorization server MUST accept its issuer identifier, token identifier URL of the authorization server according to [RFC8414]
endpoint URL, or pushed authorization request endpoint URL as values SHOULD be used as the value of the audience. In order to facilitate
that identify it as an intended audience. interoperability the authorization server MUST accept its issuer
identifier, token endpoint URL, or pushed authorization request
endpoint URL as values that identify it as an intended audience.
2.1. Request 2.1. Request
A client can send all the parameters that usually comprise an A client sends the parameters that comprise an authorization request
authorization request to the pushed authorization request endpoint. directly to the pushed authorization request endpoint. A typical
A basic parameter set will typically include: parameter set might include: "client_id", "response_type",
"redirect_uri", "scope", "state", "code_challenge", and
* "client_id" "code_challenge_method" as shown in the example below. However, the
pushed authorization request can be composed of any of the parameters
* "response_type" applicable for use at authorization endpoint including those defined
in [RFC6749] as well as all applicable extensions. The "request_uri"
* "redirect_uri" authorization request parameter is one exception, which MUST NOT be
provided.
* "scope"
* "state"
* "code_challenge" The request also includes, as appropriate for the given client, any
additional parameters necessary for client authentication (e.g.,
"client_secret", or "client_assertion" and "client_assertion_type").
* "code_challenge_method" Such parameters are defined and registered for use at the token
Depending on client type and authentication method, the request might endpoint but are applicable only for client authentication. When
also include other parameters for client authentication such as the present in a pushed authorization request, they are relied upon only
"client_secret" parameter, the "client_assertion" parameter and the for client authentication and are not germane to the authorization
"client_assertion_type" parameter. The "request_uri" authorization request itself. Any token endpoint parameters that are not related
request parameter MUST NOT be provided in this case (see Section 3). to client authentication have no defined meaning for a pushed
authorization request. The "client_id" parameter is defined with the
same semantics for both authorization requests and requests to the
token endpoint; as a required authorization request parameter, it is
similarly required in a pushed authorization request.
The client adds the parameters in "x-www-form-urlencoded" format with The client adds the parameters in "x-www-form-urlencoded" format with
a character encoding of UTF-8 as described in Appendix B of [RFC6749] a character encoding of UTF-8 as described in Appendix B of [RFC6749]
to the body of an HTTP POST request. If applicable, the client also to the body of an HTTP "POST" request. If applicable, the client
adds client credentials to the request header or the request body also adds its authentication credentials to the request header or the
using the same rules as for token endpoint requests. request body using the same rules as for token endpoint requests.
This is illustrated by the following example: This is illustrated by the following example (extra line breaks in
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
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
response_type=code& response_type=code&state=af0ifjsldkj&client_id=s6BhdRkqt3
state=af0ifjsldkj& &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
client_id=s6BhdRkqt3& &code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U
redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb& &code_challenge_method=S256&scope=account-information
code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U&
code_challenge_method=S256&
scope=ais
The authorization server MUST process the request as follows: The authorization server MUST process the request as follows:
1. Authenticate the client in the same way as at the token endpoint. 1. Authenticate the client in the same way as at the token endpoint.
2. Reject the request if the "request_uri" authorization request 2. Reject the request if the "request_uri" authorization request
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 at the authorization endpoint. checks MUST then be performed at the authorization endpoint.
The authorization server MAY allow confidential clients to establish The authorization server MAY allow clients with authentication
per-authorization request redirect URIs with every pushed credentials to establish per-authorization request redirect URIs with
authorization request. This is possible since, in contrast to every pushed authorization request. Described in more detail in
Section 2.4, this is possible since, in contrast to [RFC6749], this
[RFC6749], this specification gives the authorization server the specification gives the authorization server the the ability to
ability to authenticate and authorize clients before the actual authenticate clients and validate client requests before the actual
authorization request is performed. authorization request is performed.
This feature gives clients more flexibility in building redirect URIs
and, if the client IDs and credentials are managed by some authority
(CA or other type), the explicit client registration with the
particular authorization server (manually or via dynamic client
registration [RFC7591]) could practically be skipped. This makes
this mechanism especially useful for clients interacting with a
federation of authorization servers (or OpenID Connect Providers),
for example in Open Banking, where the certificate is provided as
part of a federated PKI.
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 return a JSON response with the following members at the top URI and return a JSON response with the following members at the top
level with "201 Created" HTTP response code. level with "201 Created" HTTP response code.
* "request_uri" : The request URI corresponding to the authorization * "request_uri" : The request URI corresponding to the authorization
request posted. This URI is used as reference to the respective request posted. This URI is used as reference to the respective
request data in the subsequent authorization request only. The request data in the subsequent authorization request only. The
way the authorization process obtains the authorization request way the authorization process obtains the authorization request
data is at the discretion of the authorization server and out of data is at the discretion of the authorization server and out of
scope of this specification. There is no need to make the scope of this specification. There is no need to make the
authorization request data available to other parties via this authorization request data available to other parties via this
URI. URI.
* "expires_in" : A JSON number that represents the lifetime of the * "expires_in" : A JSON number that represents the lifetime of the
request URI in seconds. The request URI lifetime is at the request URI in seconds as a positive integer. The request URI
discretion of the authorization server and will typically be lifetime is at the discretion of the authorization server but will
relatively short. 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. The computationally infeasible to predict or guess a valid value. The
authorization server MAY construct the "request_uri" value using the authorization server MAY construct the "request_uri" value using the
form "urn:ietf:params:oauth:request_uri:<reference-value>" with form "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. The string representation of respective authorization request data. The string representation of
a UUID as a URN per [RFC4122] is also an option for authorization a UUID as a URN per [RFC4122] is also an option for authorization
servers to construct "request_uri" values. servers to construct "request_uri" values.
The "request_uri" 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.
Since parts of the request content, e.g. the "code_challenge"
parameter value, is unique to a certain authorization request, a
"request_uri" SHOULD be limited to one-time use.
The following is an example of such a response: The following is an example of such a response:
HTTP/1.1 201 Created HTTP/1.1 201 Created
Content-Type: application/json Content-Type: application/json
Cache-Control: no-cache, no-store Cache-Control: no-cache, no-store
{ {
"request_uri": "request_uri":
"urn:ietf:params:oauth:request_uri:bwc4JK-ESC0w8acc191e-Y1LTC2", "urn:ietf:params:oauth:request_uri:bwc4JK-ESC0w8acc191e-Y1LTC2",
"expires_in": 60 "expires_in": 60
} }
2.3. Error Response 2.3. Error Response
For an error the authorization server sets an appropriate HTTP status The authorization server returns an error response with the same
code and MAY include additional error parameters in the entity-body format as is specified for error responses from the token endpoint in
of the HTTP response using the format specified for the token Section 5.2 of [RFC6749] using the appropriate error code from
endpoint in Section 5.2 of [RFC6749]. therein or from Section 4.1.2.1 of [RFC6749]. Error codes defined by
OAuth extension can also be used when such an extension is involved
If the authorization server sets an error code, it SHOULD be one of in the initial processing of authorization request that was pushed.
the defined codes for the token endpoint in Section 5.2 or for the Since initial processing of the pushed authorization request does not
authorization endpoint in Sections 4.1.2.1 and 4.2.2.1 of [RFC6749], involve resource owner interaction, error codes related to user
or by an OAuth extension if one is involved in the initial processing interaction, such as "consent_required" defined by [OIDC], are never
of authorization request that was pushed. Since initial processing returned.
of the pushed authorization request doesn't involve resource owner
interaction, error codes related to user interaction, such as
"consent_required" defined by [OIDC], are not returned.
If the client is required to use signed request objects, either by If the client is required to use signed request objects, either by
authorization server or client policy (see [I-D.ietf-oauth-jwsreq], authorization server or client policy (see [I-D.ietf-oauth-jwsreq],
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 error codes above, the pushed authorization In addition to the above, the pushed authorization request endpoint
request endpoint can also make use of the following HTTP status can also make use of the following HTTP status codes:
codes:
* 405: If the request did not use POST, the authorization server * 405: If the request did not use the "POST" method, the
responds with an HTTP 405 (Method Not Allowed) status code. authorization server responds with an HTTP 405 (Method Not
Allowed) status 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 request from the client for a time period goes beyond * 429: If the number of requests from a client during a particular
the number the authorization server allows, the authorization time period exceeds the number the authorization server allows,
server responds with an HTTP 429 (Too Many Requests) status code. the authorization server responds with an HTTP 429 (Too Many
Requests) status code.
The following is an example of an error response from the pushed The following is an example of an error response from the pushed
authorization request endpoint: authorization request 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"
} }
3. "request" Parameter 2.4. Management of Client Redirect URIs
While OAuth 2.0 [RFC6749] allows clients to use unregistered
"redirect_uri" values in certain circumstances, or for the
authorization server to apply its own matching semantics to the
"redirect_uri" value presented by the client at the authorization
endpoint, the OAuth Security BCP [I-D.ietf-oauth-security-topics] as
well as OAuth 2.1 [I-D.ietf-oauth-v2-1] require an authorization
server exactly match the "redirect_uri" parameter against the set of
redirect URIs previously established for a particular client. This
is a means for early detection of client impersonation attempts and
prevents token leakage and open redirection. As a downside, this can
make client management more cumbersome since the redirect URI is
typically the most volatile part of a client policy.
The exact matching requirement MAY be relaxed when using pushed
authorization requests for clients that have established
authentication credentials with the authorization server. This is
possible since, in contrast to a traditional authorization request,
the authorization server authenticates the client before the
authorization process starts and thus ensures it is interacting with
the legitimate client. The authorization server MAY allow such
clients to specify "redirect_uri" values that were not previously
registered with the authorization server. This will give the client
more flexibility (e.g. to mint distinct redirect URI values per
authorization server at runtime) and can simplify client management.
It is at the discretion of the authorization server to apply
restrictions on supplied "redirect_uri" values, e.g. the
authorization server MAY require a certain URI prefix or allow only a
query parameter to vary at runtime.
Note: The ability to set up transaction specific redirect URIs is
also useful in situations where client ids and corresponding
credentials and policies are managed by a trusted 3rd party, e.g. via
client certificates containing client permissions. Such an
externally managed client could interact with an authorization server
trusting the respective 3rd party without the need for an additional
registration step.
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
[I-D.ietf-oauth-jwsreq] to push a request object JWT to the [I-D.ietf-oauth-jwsreq] to push a request object JWT to the
authorization server. The rules for processing, signing, and authorization server. The rules for processing, signing, and
encryption of the request object as defined in JAR encryption of the request object as defined in JAR
[I-D.ietf-oauth-jwsreq] apply. When the "application/x-www-form- [I-D.ietf-oauth-jwsreq] apply. When the "application/x-www-form-
urlencoded" HTTP entity-body "request" parameter is used, the request urlencoded" HTTP entity-body "request" parameter is used, the request
object MUST contain all the authorization request parameters as object MUST contain all the authorization request parameters as
claims of the JWT. Additional request parameters as required by the claims of the JWT. Additional request parameters as required by the
given client authentication method are to be included as given client authentication method are to be included as
'application/x-www-form-urlencoded' parameters in the HTTP request 'application/x-www-form-urlencoded' parameters in the HTTP request
entity-body (e.g. Mutual TLS client authentication entity-body (e.g. Mutual TLS client authentication [RFC8705] uses
[I-D.ietf-oauth-mtls] uses the "client_id" HTTP request parameter the "client_id" HTTP request parameter while JWT assertion based
while JWT assertion based client authentication [RFC7523] uses client authentication [RFC7523] uses "client_assertion" and
"client_assertion" and "client_assertion_type"). "client_assertion_type").
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. The client is authenticated by its client signed request object. The client is authenticated by its client
secret using the HTTP Basic Authentication scheme specified in secret using the HTTP Basic Authentication scheme specified in
Section 2.3.1 of [RFC6749]: Section 2.3.1 of [RFC6749] (extra line breaks 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
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
request=eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3MiOiJzNkJoZ request=eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3MiOiJzNkJoZ
FJrcXQzIiwiYXVkIjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJyZXNwb2 FJrcXQzIiwiYXVkIjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJyZXNwb2
5zZV90eXBlIjoiY29kZSIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmV 5zZV90eXBlIjoiY29kZSIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmV
jdF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsInNjb3BlIjoi jdF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsInNjb3BlIjoi
YWlzIiwic3RhdGUiOiJhZjBpZmpzbGRraiIsImNvZGVfY2hhbGxlbmdlIjoiSzItb YWlzIiwic3RhdGUiOiJhZjBpZmpzbGRraiIsImNvZGVfY2hhbGxlbmdlIjoiSzItb
HRjODNhY2M0aDBjOXc2RVNDX3JFTVRKM2J3dy11Q0hhb2VLMXQ4VSIsImNvZGVfY2 HRjODNhY2M0aDBjOXc2RVNDX3JFTVRKM2J3dy11Q0hhb2VLMXQ4VSIsImNvZGVfY2
hhbGxlbmdlX21ldGhvZCI6IlMyNTYifQ.O49ffUxRPdNkN3TRYDvbEYVr1CeAL64u hhbGxlbmdlX21ldGhvZCI6IlMyNTYifQ.O49ffUxRPdNkN3TRYDvbEYVr1CeAL64u
W4FenV3n9WlaFIRHeFblzv-wlEtMm8-tusGxeE9z3ek6FxkhvvLEqEpjthXnyXqqy W4FenV3n9WlaFIRHeFblzv-wlEtMm8-tusGxeE9z3ek6FxkhvvLEqEpjthXnyXqqy
Jfq3k9GSf5ay74ml_0D6lHE1hy-kVWg7SgoPQ-GB1xQ9NRhF3EKS7UZIrUHbFUCF0 Jfq3k9GSf5ay74ml_0D6lHE1hy-kVWg7SgoPQ-GB1xQ9NRhF3EKS7UZIrUHbFUCF0
MsRLbmtIvaLYbQH_Ef3UkDLOGiU7exhVFTPeyQUTM9FF-u3K-zX-FO05_brYxNGLh MsRLbmtIvaLYbQH_Ef3UkDLOGiU7exhVFTPeyQUTM9FF-u3K-zX-FO05_brYxNGLh
VkO1G8MjqQnn2HpAzlBd5179WTzTYhKmhTiwzH-qlBBI_9GLJmE3KOipko9TfSpa2 VkO1G8MjqQnn2HpAzlBd5179WTzTYhKmhTiwzH-qlBBI_9GLJmE3KOipko9TfSpa2
6H4JOlMyfZFl0PCJwkByS0xZFJ2sTo3Gkk488RQohhgt1I0onw 6H4JOlMyfZFl0PCJwkByS0xZFJ2sTo3Gkk488RQohhgt1I0onw
&client_id=s6BhdRkqt3
The authorization server needs to 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. [I-D.ietf-oauth-jwsreq], section 6.1.
2. Validates 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. [I-D.ietf-oauth-jwsreq], section 6.2.
3. If the client is a confidential client, the authorization server 3. If the client has authentication credentials established with the
MUST check whether the authenticated "client_id" matches the authorization server, reject the request if the authenticated
"client_id" claim in the request object. If they do not match, "client_id" does not match the "client_id" claim in the request
the authorization server MUST refuse to process the request. It object. Additionally requiring the "iss" claim to match the
is at the authorization server's discretion to require the "iss" "client_id" is at the discretion of authorization server.
claim to match the "client_id" as well.
The following RSA key pair, represented in JWK [RFC7517] format, can The following RSA key pair, represented in JWK [RFC7517] format, can
be used to validate or recreate the request object signature in the be used to validate or recreate the request object signature in the
above example (line wraps within values for display purposes only): above example (extra line breaks and indentation 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 12, line 45 skipping to change at page 13, line 11
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
[I-D.ietf-oauth-jwsreq]. This is shown in the following example [I-D.ietf-oauth-jwsreq]. This is shown in the following example
where the client directs the user-agent to make the following HTTP where the client directs the user-agent to make the following HTTP
request: request (extra line breaks and indentation for display purposes
only):
GET /authorize?client_id=s6BhdRkqt3&request_uri=urn%3Aietf%3Aparams GET /authorize?client_id=s6BhdRkqt3&request_uri=urn%3Aietf%3Aparams
%3Aoauth%3Arequest_uri%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1 %3Aoauth%3Arequest_uri%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1
Host: as.example.com Host: as.example.com
Since parts of the authorization request content, e.g. the
"code_challenge" parameter value, are unique to a particular
authorization request, the client MUST only use a "request_uri" value
once. Authorization servers SHOULD treat "request_uri" values as
one-time use but MAY allow for duplicate requests due to a user
reloading/refreshing their user-agent.
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 pushed authorization requests are the only means client basis, that pushed authorization requests are the only means
skipping to change at page 13, line 31 skipping to change at page 14, line 4
Note: authorization server and clients MAY use metadata as defined in Note: authorization server and clients MAY use metadata as defined in
Section 5 and Section 6 to signal the desired behavior. Section 5 and Section 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 [RFC8414] parameters are
introduced to signal the server's capability and policy with respect introduced to signal the server's capability and policy with respect
to pushed authorization requests. to pushed authorization requests.
"pushed_authorization_request_endpoint" The URL of the pushed "pushed_authorization_request_endpoint" The URL of the pushed
authorization request endpoint at which the client can post an authorization request endpoint at which a client can post an
authorization request and get a request URI in exchange. authorization request in exchange for a "request_uri" value usable
at the authorization server.
"require_pushed_authorization_requests" Boolean parameter indicating "require_pushed_authorization_requests" Boolean parameter indicating
whether the authorization server accepts authorization request whether the authorization server accepts authorization request
data only via the pushed authorization request method. If data only via the pushed authorization request method. If
omitted, the default value is "false". omitted, the default value is "false".
6. Client Metadata 6. Client Metadata
The Dynamic Client Registration Protocol [RFC7591] defines an API for The Dynamic Client Registration Protocol [RFC7591] defines an API for
dynamically registering OAuth 2.0 client metadata with authorization dynamically registering OAuth 2.0 client metadata with authorization
skipping to change at page 14, line 5 skipping to change at page 14, line 28
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 reqired for the given client. authorization requests are reqired for the given client.
"require_pushed_authorization_requests" Boolean parameter indicating "require_pushed_authorization_requests" Boolean parameter indicating
whether the only means of initiating an authorization request the whether the only means of initiating an authorization request the
client is allowed to use is a pushed authorization request. client is allowed to use is a pushed authorization request. If
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 consider the considerations given in JAR
[I-D.ietf-oauth-jwsreq], section 10.2, clause (d) on request URI [I-D.ietf-oauth-jwsreq], section 10.2, clause (d) on request URI
entropy. entropy.
7.2. Open Redirection 7.2. Open Redirection
An attacker could try register a redirect URI pointing to a site An attacker could try register a redirect URI pointing to a site
under his control in order to obtain authorization codes or lauch under his 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 PAR request from confidential clients accept new redirect URIs in the pushed authorization request from
after successful authentication and authorization. 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. It is therefore 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.
8. Acknowledgements 7.5. Request URI Swapping
An attacker could capture the request URI from one request and then
substitute it into a different authorization request. For example,
in the context of OpenID Connect, an attacker could replace a request
URI asking for a high level of authentication assurance with one that
requires a lower level of assurance. Clients SHOULD make use of
PKCE, a unique "state" parameter, or the OIDC "nonce" parameter in
the pushed request object to prevent this attack.
8. Privacy Considerations
OAuth 2.0 is a complex and flexible framework with broad ranging
privacy implications due to the very nature of it having one entity
intermediate user authorization to data access between two other
entities. The privacy considerations of all of OAuth are beyond the
scope of this document, which only defines an alternative way of
initiating one message sequence in the larger framework. Using
pushed authorization requests, however, may improve privacy by
reducing the potential for inadvertent information disclosure due to
passing authorization request data directly between client and
authorization server over a secure connection in the message-body of
an HTTP request rather than in the query component of a URL that
passes through the user-agent in the clear.
9. Acknowledgements
This specification is based on the work towards Pushed Request Object This specification is based on the work towards Pushed Request Object
(https://bitbucket.org/openid/fapi/src/master/ (https://bitbucket.org/openid/fapi/src/master/
Financial_API_Pushed_Request_Object.md) conducted at the Financial- Financial_API_Pushed_Request_Object.md) conducted at the Financial-
grade API working group at the OpenID Foundation. We would like to grade API working group at the OpenID Foundation. We would like to
thank the members of the WG for their valuable contributions. thank the members of the WG for their valuable contributions.
We would like to thank Vladimir Dzhuvinov, Aaron Parecki, Justin We would like to thank Vladimir Dzhuvinov, Aaron Parecki, Justin
Richer, Sascha Preibisch, Daniel Fett, Michael B. Jones, Annabelle Richer, Sascha Preibisch, Daniel Fett, Michael B. Jones, Annabelle
Backman, Joseph Heenan, Sean Glencross, Maggie Hung, Neil Madden, and Backman, Joseph Heenan, Sean Glencross, Maggie Hung, Neil Madden,
Takahiko Kawasaki for their valuable feedback on this draft. Karsten Meyer zu Selhausen, and Takahiko Kawasaki for their valuable
feedback on this draft.
9. IANA Considerations 10. IANA Considerations
9.1. OAuth Authorization Server Metadata 10.1. OAuth Authorization Server Metadata
This specification requests registration of the following values in This specification requests registration of the following values in
the IANA "OAuth Authorization Server Metadata" registry of the IANA "OAuth Authorization Server Metadata" registry of
[IANA.OAuth.Parameters] established by [RFC8414]. [IANA.OAuth.Parameters] 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 [[ this document ]]
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 request only via the pushed authorization accepts authorization request only via the pushed authorization
request method. request method.
Change Controller: IESG Change Controller: IESG
Specification Document(s): Section 5 of [[ this document ]] Specification Document(s): Section 5 of [[ this document ]]
9.2. OAuth Dynamic Client Registration Metadata 10.2. OAuth Dynamic Client Registration Metadata
This specification requests registration of the following value in This specification requests registration of the following value in
the IANA "OAuth Dynamic Client Registration Metadata" registry of the IANA "OAuth Dynamic Client Registration Metadata" registry of
[IANA.OAuth.Parameters] established by [RFC7591]. [IANA.OAuth.Parameters] established by [RFC7591].
Metadata Name: "require_pushed_authorization_requests" Metadata Name: "require_pushed_authorization_requests"
Metadata Description: Indicates whether the client is required to Metadata Description: Indicates whether the client is required to
use the pushed authorization request method to initiate use the pushed authorization request method to initiate
authorization requests. authorization requests.
Change Controller: IESG Change Controller: IESG
Specification Document(s): Section 6 of [[ this document ]] Specification Document(s): Section 6 of [[ this document ]]
9.3. OAuth URI Registration 10.3. OAuth URI Registration
This specification requests registration of the following value in This specification requests registration of the following value in
the "OAuth URI" registry of [IANA.OAuth.Parameters] established by the "OAuth URI" registry 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 [[ this document ]]
10. Normative References 11. Normative References
[I-D.ietf-oauth-jwsreq] [I-D.ietf-oauth-jwsreq]
Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0
Framework: JWT Secured Authorization Request (JAR)", Work Authorization Framework: JWT Secured Authorization Request
in Progress, Internet-Draft, draft-ietf-oauth-jwsreq-26, (JAR)", Work in Progress, Internet-Draft, draft-ietf-
27 July 2020, oauth-jwsreq-30, 10 September 2020,
<https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-26>. <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-30>.
[OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0 incorporating
errata set 1", 8 November 2014,
<http://openid.net/specs/openid-connect-core-1_0.html>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", RFC 8414,
DOI 10.17487/RFC8414, June 2018,
<https://www.rfc-editor.org/info/rfc8414>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
[OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 12. Informative References
C. Mortimore, "OpenID Connect Core 1.0 incorporating
errata set 1", 8 November 2014,
<http://openid.net/specs/openid-connect-core-1_0.html>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 [I-D.ietf-oauth-v2-1]
Authorization Server Metadata", RFC 8414, Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1
DOI 10.17487/RFC8414, June 2018, Authorization Framework", Work in Progress, Internet-
<https://www.rfc-editor.org/info/rfc8414>. Draft, draft-ietf-oauth-v2-1-00, 30 July 2020,
<https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00>.
11. Informative References [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T.
Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication
and Certificate-Bound Access Tokens", RFC 8705,
DOI 10.17487/RFC8705, February 2020,
<https://www.rfc-editor.org/info/rfc8705>.
[RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key
(JWT) Profile for OAuth 2.0 Client Authentication and for Code Exchange by OAuth Public Clients", RFC 7636,
Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May DOI 10.17487/RFC7636, September 2015,
2015, <https://www.rfc-editor.org/info/rfc7523>. <https://www.rfc-editor.org/info/rfc7636>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005, DOI 10.17487/RFC4122, July 2005,
<https://www.rfc-editor.org/info/rfc4122>. <https://www.rfc-editor.org/info/rfc4122>.
[I-D.ietf-oauth-mtls]
Campbell, B., Bradley, J., Sakimura, N., and T.
Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication
and Certificate-Bound Access Tokens", Work in Progress,
Internet-Draft, draft-ietf-oauth-mtls-17, 23 August 2019,
<https://tools.ietf.org/html/draft-ietf-oauth-mtls-17>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>.
[IANA.OAuth.Parameters] [IANA.OAuth.Parameters]
IANA, "OAuth Parameters", IANA, "OAuth Parameters",
<http://www.iana.org/assignments/oauth-parameters>. <http://www.iana.org/assignments/oauth-parameters>.
[RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012,
<https://www.rfc-editor.org/info/rfc6755>.
[RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key
for Code Exchange by OAuth Public Clients", RFC 7636,
DOI 10.17487/RFC7636, September 2015,
<https://www.rfc-editor.org/info/rfc7636>.
[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>.
[RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
(JWT) Profile for OAuth 2.0 Client Authentication and
Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May
2015, <https://www.rfc-editor.org/info/rfc7523>.
[I-D.ietf-oauth-security-topics]
Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett,
"OAuth 2.0 Security Best Current Practice", Work in
Progress, Internet-Draft, draft-ietf-oauth-security-
topics-15, 5 April 2020, <https://tools.ietf.org/html/
draft-ietf-oauth-security-topics-15>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
RFC 7591, DOI 10.17487/RFC7591, July 2015, RFC 7591, DOI 10.17487/RFC7591, July 2015,
<https://www.rfc-editor.org/info/rfc7591>. <https://www.rfc-editor.org/info/rfc7591>.
[RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012,
<https://www.rfc-editor.org/info/rfc6755>.
Appendix A. Document History Appendix A. Document History
[[ To be removed from the final specification ]] [[ To be removed from the final specification ]]
-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 -03
* Editorial updates * Editorial updates
* Mention that https is required for the PAR endpoint * Mention that https is required for the PAR endpoint
* Add some discussion of browser form posting an authz request vs. * Add some discussion of browser form posting an authz request vs.
the benefits of PAR for any application the benefits of PAR for any application
* Added text about motivations behind PAR - integrity, * Added text about motivations behind PAR - integrity,
 End of changes. 75 change blocks. 
256 lines changed or deleted 363 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/