draft-ietf-oauth-par-01.txt   draft-ietf-oauth-par-02.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: 21 August 2020 Ping Identity Expires: 11 January 2021 Ping Identity
N. Sakimura N. Sakimura
Nomura Research Institute NAT.Consulting
D. Tonge D. Tonge
Moneyhub Financial Technology Moneyhub Financial Technology
F. Skokan F. Skokan
Auth0 Auth0
18 February 2020 10 July 2020
OAuth 2.0 Pushed Authorization Requests OAuth 2.0 Pushed Authorization Requests
draft-ietf-oauth-par-01 draft-ietf-oauth-par-02
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 authorization request.
Status of This Memo Status of This Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 21 August 2020. This Internet-Draft will expire on 11 January 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 . . . . . . . . . . . . . . . 4 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 4
2. Pushed Authorization Request Endpoint . . . . . . . . . . . . 4 2. Pushed Authorization Request Endpoint . . . . . . . . . . . . 5
2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Successful Response . . . . . . . . . . . . . . . . . . . 7 2.2. Successful Response . . . . . . . . . . . . . . . . . . . 7
2.3. Error Response . . . . . . . . . . . . . . . . . . . . . 8 2.3. Error Response . . . . . . . . . . . . . . . . . . . . . 8
3. "request" Parameter . . . . . . . . . . . . . . . . . . . . . 9 3. "request" Parameter . . . . . . . . . . . . . . . . . . . . . 9
3.1. Error responses for Request Object . . . . . . . . . . . 10 3.1. Error responses for Request Object . . . . . . . . . . . 11
3.1.1. Authentication Required . . . . . . . . . . . . . . . 10 3.1.1. Authentication Required . . . . . . . . . . . . . . . 11
4. Authorization Request . . . . . . . . . . . . . . . . . . . . 10 4. Authorization Request . . . . . . . . . . . . . . . . . . . . 12
5. Authorization Server Metadata . . . . . . . . . . . . . . . . 10 5. Authorization Server Metadata . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Request URI Guessing . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6.2. Open Redirection . . . . . . . . . . . . . . . . . . . . 11 7.1. Request URI Guessing . . . . . . . . . . . . . . . . . . 13
6.3. Request Object Replay . . . . . . . . . . . . . . . . . . 11 7.2. Open Redirection . . . . . . . . . . . . . . . . . . . . 13
6.4. Client Policy Change . . . . . . . . . . . . . . . . . . 11 7.3. Request Object Replay . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 7.4. Client Policy Change . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
9. Normative References . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Informative References . . . . . . . . . . . . . . . . . . . 12 9.1. OAuth Authorization Server Metadata . . . . . . . . . . . 14
Appendix A. Document History . . . . . . . . . . . . . . . . . . 13 9.2. OAuth Dynamic Client Registration Metadata . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 9.3. OAuth URI Registration . . . . . . . . . . . . . . . . . 15
10. Normative References . . . . . . . . . . . . . . . . . . . . 15
11. Informative References . . . . . . . . . . . . . . . . . . . 15
Appendix A. Document History . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
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,
i.e. the request can be modified on its way through the user-agent i.e. the request can be modified on its way through the user-agent
and attackers can impersonate legitimate clients. and attackers can impersonate legitimate clients.
skipping to change at page 4, line 8 skipping to change at page 4, line 17
{ {
"request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2", "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2",
"expires_in": 90 "expires_in": 90
} }
which is used by the client in the subsequent authorization request which is used by the client in the subsequent authorization request
as follows, as follows,
GET /authorize?request_uri= GET /authorize?client_id=s6BhdRkqt3&
urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1 request_uri=urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1
The pushed authorization request endpoint fosters OAuth security by The pushed authorization request endpoint fosters OAuth security by
providing all clients a simple means for an integrity protected providing all clients a simple means for an integrity protected
authorization request, but it also allows clients requiring an even authorization request, but it also allows clients requiring an even
higher security level, especially cryptographically confirmed non- higher security level, especially cryptographically confirmed non-
repudiation, to explicitly adopt JWT-based request objects. repudiation, to explicitly adopt JWT-based request objects.
As a further benefit, the pushed authorization request allows the AS As a further benefit, the pushed authorization request allows the AS
to authenticate the clients before any user interaction happens, to authenticate the clients before any user interaction happens,
i.e., the AS may refuse unauthorized requests much earlier in the i.e., the AS may refuse unauthorized requests much earlier in the
skipping to change at page 5, line 5 skipping to change at page 5, line 13
"client" defined by The OAuth 2.0 Authorization 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 POST requests with parameters in
the HTTP request entity-body using the "application/x-www-form- the HTTP request entity-body using the "application/x-www-form-
urlencoded" format with a character encoding of UTF-8 as described in urlencoded" format with a character encoding of UTF-8 as described in
Appendix B of [RFC6749]. Appendix B of [RFC6749].
Authorization servers supporting pushed authorization requests SHOULD
include the URL of their pushed authorization request endpoint in
their authorization server metadata document [RFC8414] using the
"pushed_authorization_request_endpoint" parameter as defined in
Section 5.
The endpoint accepts the parameters defined in [RFC6749] for the The endpoint accepts the parameters defined in [RFC6749] for the
authorization endpoint as well as all applicable extensions defined authorization endpoint as well as all applicable extensions defined
for the authorization endpoint. Some examples of such extensions for the authorization endpoint. Some examples of such extensions
include PKCE [RFC7636], Resource Indicators include PKCE [RFC7636], Resource Indicators [RFC8707], and OpenID
[I-D.ietf-oauth-resource-indicators], and OpenID Connect [OIDC]. Connect [OIDC]. The endpoint also supports sending all authorization
request parameters as request object according to
[I-D.ietf-oauth-jwsreq].
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 parameter indicates the registered authentication method for the
client to use when making direct requests to the authorization client to use when making direct requests to the authorization
server, including requests to the pushed authorization request server, including requests to the pushed authorization request
endpoint. endpoint.
skipping to change at page 6, line 36 skipping to change at page 7, line 5
scope=ais scope=ais
The AS MUST process the request as follows: The AS MUST process the request as follows:
1. The AS MUST authenticate the client in the same way as at the 1. The AS MUST authenticate the client in the same way as at the
token endpoint. token endpoint.
2. The AS MUST reject the request if the "request_uri" authorization 2. The AS MUST reject the request if the "request_uri" authorization
request parameter is provided. request parameter is provided.
3. The AS MUST validate the request in the same way as at the 3. The AS MUST validate the pushed request as it would an
authorization endpoint. For example, the authorization server authorization request sent to the authorization endpoint. For
checks whether the redirect URI matches one of the redirect URIs example, the authorization server checks whether the redirect URI
configured for the client. It MUST also check whether the client matches one of the redirect URIs configured for the client and
is authorized for the "scope" for which it is requesting access. also checks whether the client is authorized for the scope for
This validation allows the authorization server to refuse which it is requesting access. This validation allows the
unauthorized or fraudulent requests early. authorization server to refuse unauthorized or fraudulent
requests early. The AS MAY omit validation steps that it is
unable to perform when processing the pushed request, however
such checks MUST then be performed at the authorization endpoint.
The AS MAY allow confidential clients to establish per-authorization The AS MAY allow confidential clients to establish per-authorization
request redirect URIs with every pushed authorization request. This request redirect URIs with every pushed authorization request. This
is possible since, in contrast to [RFC6749], this specification gives is possible since, in contrast to [RFC6749], this specification gives
the AS the ability to authenticate and authorize clients before the the AS the ability to authenticate and authorize clients before the
actual authorization request is performed. actual authorization request is performed.
This feature gives clients more flexibility in building redirect URIs This feature gives clients more flexibility in building redirect URIs
and, if the client IDs and credentials are managed by some authority and, if the client IDs and credentials are managed by some authority
(CA or other type), the explicit client registration with the (CA or other type), the explicit client registration with the
skipping to change at page 7, line 31 skipping to change at page 8, line 5
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. The request URI lifetime is at the
discretion of the AS. discretion of the AS.
The "request_uri" value MUST be generated using a cryptographically The format of the "request_uri" value is at the discretion of the
strong pseudorandom algorithm such that it is computationally authorization server but it MUST contain some part generated using a
infeasible to predict or guess a valid value. cryptographically strong pseudorandom algorithm such that it is
computationally infeasible to predict or guess a valid value. The
authorization server MAY construct the "request_uri" value using the
form "urn:ietf:params:oauth:request_uri:<reference-value>" with
"<reference-value>" as the random part of the URI that references the
respective authorization request data. The string representation of
a UUID as a URN per [RFC4122] is also an option for authorization
servers to construct "request_uri" values.
The "request_uri" MUST be bound to the client that posted the The "request_uri" MUST be bound to the client that posted the
authorization request. authorization request.
Since the request URI can be replayed, its lifetime SHOULD be short Since the request URI can be replayed, its lifetime SHOULD be short
and preferably limited to one-time use. and preferably 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": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2", "request_uri":
"expires_in": 3600 "urn:ietf:params:oauth:request_uri:bwc4JK-ESC0w8acc191e-Y1LTC2",
} "expires_in": 60
}
2.3. Error Response 2.3. Error Response
For an error the authorization server sets an appropriate HTTP status For an error the authorization server sets an appropriate HTTP status
code and MAY include additional error parameters in the entity-body code and MAY include additional error parameters in the entity-body
of the HTTP response using the format specified for the token of the HTTP response using the format specified for the token
endpoint in Section 5.2 of [RFC6749]. endpoint in Section 5.2 of [RFC6749].
If the authorization server sets an error code, it SHOULD be one of If the authorization server sets an error code, it SHOULD be one of
the defined codes for the token endpoint in Section 5.2 or for the the defined codes for the token endpoint in Section 5.2 or for the
authorization endpoint in Sections 4.1.2.1 and 4.2.2.1 of [RFC6749], authorization endpoint in Sections 4.1.2.1 and 4.2.2.1 of [RFC6749],
or by an OAuth extension if one is involved in the initial processing or by an OAuth extension if one is involved in the initial processing
of authorization request that was pushed. Since initial processing of authorization request that was pushed. Since initial processing
of the pushed authorisation request doesn't involve resource owner of the pushed authorisation request doesn't involve resource owner
interaction, error codes related to user interaction, such as interaction, error codes related to user interaction, such as
"consent_required" defined by [OIDC], are not returned. "consent_required" defined by [OIDC], are not returned.
If the client is required to use signed request objects, either by
authorization server or client policy (see [I-D.ietf-oauth-jwsreq],
section 10.5), the authorization server MUST only accept requests
complying with the definition given in Section 3 and MUST refuse any
other request with HTTP status code 400 and error code
"invalid_request".
In addition to the error codes above, the pushed authorization In addition to the error codes above, the pushed authorization
request endpoint specifies use of the following HTTP status codes: request endpoint specifies use of the following HTTP status codes:
* 405: If the request did not use POST, the authorization server * 405: If the request did not use POST, the authorization server
responds with an HTTP 405 (Method Not Allowed) status code. 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.
skipping to change at page 10, line 12 skipping to change at page 10, line 44
2. The AS validates the request object signature as specified in JAR 2. The AS validates 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 is a confidential client, the authorization server
MUST check whether the authenticated "client_id" matches the MUST check whether the authenticated "client_id" matches the
"client_id" claim in the request object. If they do not match, "client_id" claim in the request object. If they do not match,
the authorization server MUST refuse to process the request. It the authorization server MUST refuse to process the request. It
is at the authorization server's discretion to require the "iss" is at the authorization server's discretion to require the "iss"
claim to match the "client_id" as well. claim to match the "client_id" as well.
The following RSA key pair, represented in JWK [RFC7517] format, can
be used to validate or recreate the request object signature in the
above example (line wraps within values for display purposes only):
{
"kty": "RSA",
"kid":"k2bdc",
"n": "y9Lqv4fCp6Ei-u2-ZCKq83YvbFEk6JMs_pSj76eMkddWRuWX2aBKGHAtKlE
5P7_vn__PCKZWePt3vGkB6ePgzAFu08NmKemwE5bQI0e6kIChtt_6KzT5Oa
aXDFI6qCLJmk51Cc4VYFaxgqevMncYrzaW_50mZ1yGSFIQzLYP8bijAHGVj
dEFgZaZEN9lsn_GdWLaJpHrB3ROlS50E45wxrlg9xMncVb8qDPuXZarvghL
L0HzOuYRadBJVoWZowDNTpKpk2RklZ7QaBO7XDv3uR7s_sf2g-bAjSYxYUG
sqkNA9b3xVW53am_UZZ3tZbFTIh557JICWKHlWj5uzeJXaw",
"e": "AQAB",
"d": "LNwG_pCKrwowALpCpRdcOKlSVqylSurZhE6CpkRiE9cpDgGKIkO9CxPlXOL
zjqxXuQc8MdMqRQZTnAwgd7HH0B6gncrruV3NewI-XQV0ckldTjqNfOTz1V
Rs-jE-57KAXI3YBIhu-_0YpIDzdk_wBuAk661Svn0GsPQe7m9DoxdzenQu9
O_soewUhlPzRrTH0EeIqYI715rwI3TYaSzoWBmEPD2fICyj18FF0MPy_SQz
k3noVUUIzfzLnnJiWy_p63QBCMqjRoSHHdMnI4z9iVpIwJWQ3jO5n_2lC2-
cSgwjmKsFzDBbQNJc7qMG1N6EssJUwgGJxz1eAUFf0w4YAQ",
"qi": "J-mG0swR4FTy3atrcQ7dd0hhYn1E9QndN-
-sDG4EQO0RnFj6wIefCvwIc4
7hCtVeFnCTPYJNc_JyV-mU-9vlzS5GSNuyR5qdpsMZXUMpEvQcwKt23ffPZ
YGaqfKyEesmf_Wi8fFcE68H9REQjnniKrXm7w2-IuG_IrVJA9Ox-uU",
"q": "4hlMYAGa0dvogdK1jnxQ7J_Lqpqi99e-AeoFvoYpMPhthChTzwFZO9lQmUo
BpMqVQTws_s7vWGmt7ZAB3ywkurf0pV7BD0fweJiUzrWk4KJjxtmP_auuxr
jvm3s2FUGn6f0wRY9Z8Hj9A7C72DnYCjuZiJQMYCWDsZ8-d-L1a-s",
"p": "5sd9Er3I2FFT9R-gy84_oakEyCmgw036B_nfYEEOCwpSvi2z7UcIVK3bSEL
5WCW6BNgB3HDWhq8aYPirwQnqm0K9mX1E-4xM10WWZ-rP3XjYpQeS0Snru5
LFVWsAzi-FX7BOqBibSAXLdEGXcXa44l08iec_bPD3xduq5V_1YoE",
"dq": "Nz2PF3XM6bEc4XsluKZO70ErdYdKgdtIJReUR7Rno_tOZpejwlPGBYVW19
zpAeYtCT82jxroB2XqhLxGeMxEPQpsz2qTKLSe4BgHY2ml2uxSDGdjcsrbb
NoKUKaN1CuyZszhWl1n0AT_bENl4bJgQj_Fh0UEsQj5YBBUJt5gr_k",
"dp": "Zc877jirkkLOtyTs2vxyNe9KnMNAmOidlUc2tE_-0gAL4Lpo1hSwKCtKwe
ZJ-gkqt1hT-dwNx_0Xtg_-NXsadMRMwJnzBMYwYAfjApUkfqABc0yUCJJl3
KozRCugf1WXkU9GZAH2_x8PUopdNUEa70ISowPRh04HANKX4fkjWAE"
}
3.1. Error responses for Request Object 3.1. Error responses for Request Object
This section gives the error responses that go beyond the basic This section gives the error responses that go beyond the basic
Section 2.3. Section 2.3.
3.1.1. Authentication Required 3.1.1. Authentication Required
If the signature validation fails, the authorization server returns a If the signature validation fails, the authorization server returns a
"401 Unauthorized" HTTP error response. The same applies if the "401 Unauthorized" HTTP error response. The same applies if the
"client_id" or, if applicable, the "iss" claim in the request object "client_id" or, if applicable, the "iss" claim in the request object
do not match the authenticated "client_id". do not match the authenticated "client_id".
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 as the authorization request parameter "request_uri" as server to build an authorization request as defined in
defined in JAR. [I-D.ietf-oauth-jwsreq]. This is shown in the following example.
GET /authorize?request_uri= GET /authorize?client_id=s6BhdRkqt3&request_uri=urn%3Aietf%3Aparams
urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1 %3Aoauth%3Arequest_uri%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1
Clients are encouraged to use the request URI as the only parameter The authorization server MUST validate authorization requests arising
in order to use the integrity and authenticity provided by the pushed from a pushed request as it would any other authorization request.
authorization request. The authorization server MAY omit validation steps that it performed
when the request was pushed, provided that it can validate that the
request was a pushed request, and that the request or the
authorization server's policy has not been modified in a way that
would affect the outcome of the omitted steps.
Authorization server policy MAY dictate, either globally or on a per-
client basis, that pushed authorization requests are the only means
for a client to pass authorization request data. In this case, the
authorization server will refuse, using the "invalid_request" error
code, to process any request to the authorization endpoint that does
not have a "request_uri" parameter with a value obtained from the
pushed authorization request endpoint.
Note: authorization server and clients MAY use metadata as defined in
Section 5 and Section 6 to signal the desired behavior.
5. Authorization Server Metadata 5. Authorization Server Metadata
If the authorization server has a pushed authorization request The following authorization server metadata [RFC8414] parameters are
endpoint, it SHOULD include the following OAuth/OpenID Provider introduced to signal the server's capability and policy with respect
Metadata parameter in discovery responses: 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 the client can post an
authorization request and get a request URI in exchange. authorization request and get a request URI in exchange.
6. Security Considerations "require_pushed_authorization_requests" Boolean parameter indicating
6.1. Request URI Guessing whether the authorization server accepts authorization request
data only via the pushed authorization request method. If
omitted, the default value is "false".
6. Client Metadata
The Dynamic Client Registration Protocol [RFC7591] defines an API for
dynamically registering OAuth 2.0 client metadata with authorization
servers. The metadata defined by [RFC7591], and registered
extensions to it, also imply a general data model for clients that is
useful for authorization server implementations even when the Dynamic
Client Registration Protocol isn't in play. Such implementations
will typically have some sort of user interface available for
managing client configuration. The following client metadata
parameter is introduced by this document to indicate whether pushed
authorization requests are reqired for the given client.
"require_pushed_authorization_requests" Boolean parameter indicating
whether the only means of initiating an authorization request the
client is allowed to use is a pushed authorization request.
7. Security Considerations
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 AS MUST value and try to impersonate the respective client. The AS MUST
consider the considerations given in JAR [I-D.ietf-oauth-jwsreq], consider the considerations given in JAR [I-D.ietf-oauth-jwsreq],
section 10.2, clause d on request URI entropy. section 10.2, clause d on request URI entropy.
6.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 lauch
other attacks towards the user. The AS MUST only accept new redirect other attacks towards the user. The AS MUST only accept new redirect
URIs in the PAR request from confidential clients after sucessful URIs in the PAR request from confidential clients after sucessful
authentication and authorization. authentication and authorization.
6.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 AS authorization request. In order to cope with such attacks, the AS
SHOULD make the request URIs one-time use. SHOULD make the request URIs one-time use.
6.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 AS check the request object. It is therefore recommended that the AS check the request
parameter against the client policy when processing the authorization parameter against the client policy when processing the authorization
request. request.
7. Acknowledgements 8. 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, Joseph We would like to thank Vladimir Dzhuvinov, Aaron Parecki, Justin
Heenan, and Takahiko Kawasaki for their valuable feedback on this Richer, Sascha Preibisch, Daniel Fett, Michael B. Jones, Annabelle
draft. Backman, Joseph Heenan, and Takahiko Kawasaki for their valuable
feedback on this draft.
8. IANA Considerations 9. IANA Considerations
This specification requests registration of the following value in 9.1. OAuth Authorization Server Metadata
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): [[ this document ]] Specification Document(s): Section 5 of [[ this document ]]
9. Normative References Metadata Name: "require_pushed_authorization_requests"
Metadata Description: Indicates whether the authorization server
accepts authorization request only via the pushed authorization
request method.
Change Controller: IESG
Specification Document(s): Section 5 of [[ this document ]]
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 9.2. OAuth Dynamic Client Registration Metadata
Authorization Server Metadata", RFC 8414,
DOI 10.17487/RFC8414, June 2018,
<https://www.rfc-editor.org/info/rfc8414>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", This specification requests registration of the following value in
RFC 6749, DOI 10.17487/RFC6749, October 2012, the IANA "OAuth Dynamic Client Registration Metadata" registry of
<https://www.rfc-editor.org/info/rfc6749>. [IANA.OAuth.Parameters] established by [RFC7591].
[I-D.ietf-oauth-jwsreq] Metadata Name: "require_pushed_authorization_requests"
Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization Metadata Description: Indicates whether the client is required to
Framework: JWT Secured Authorization Request (JAR)", Work use the pushed authorization request method to initiate
in Progress, Internet-Draft, draft-ietf-oauth-jwsreq-20, authorization requests.
21 October 2019, Change Controller: IESG
<https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20>. Specification Document(s): Section 6 of [[ this document ]]
[OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 9.3. OAuth URI Registration
C. Mortimore, "OpenID Connect Core 1.0 incorporating
errata set 1", 8 November 2014, This specification requests registration of the following value in
<http://openid.net/specs/openid-connect-core-1_0.html>. the "OAuth URI" registry of [IANA.OAuth.Parameters] established by
[RFC6755].
URN: "urn:ietf:params:oauth:request_uri:"
Common Name: A URN Sub-Namespace for OAuth Request URIs.
Change Controller: IESG
Specification Document(s): Section 2.2 of [[ this document ]]
10. Normative References
[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>.
[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>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[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>.
10. Informative References [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>.
[I-D.ietf-oauth-resource-indicators] [I-D.ietf-oauth-jwsreq]
Campbell, B., Bradley, J., and H. Tschofenig, "Resource Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization
Indicators for OAuth 2.0", Work in Progress, Internet- Framework: JWT Secured Authorization Request (JAR)", Work
Draft, draft-ietf-oauth-resource-indicators-08, 11 in Progress, Internet-Draft, draft-ietf-oauth-jwsreq-25, 1
September 2019, <https://tools.ietf.org/html/draft-ietf- July 2020,
oauth-resource-indicators-08>. <https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-25>.
[I-D.ietf-oauth-mtls] 11. Informative References
Campbell, B., Bradley, J., Sakimura, N., and T.
Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
and Certificate-Bound Access Tokens", Work in Progress, P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
Internet-Draft, draft-ietf-oauth-mtls-17, 23 August 2019, RFC 7591, DOI 10.17487/RFC7591, July 2015,
<https://tools.ietf.org/html/draft-ietf-oauth-mtls-17>. <https://www.rfc-editor.org/info/rfc7591>.
[RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
(JWT) Profile for OAuth 2.0 Client Authentication and Unique IDentifier (UUID) URN Namespace", RFC 4122,
Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May DOI 10.17487/RFC4122, July 2005,
2015, <https://www.rfc-editor.org/info/rfc7523>. <https://www.rfc-editor.org/info/rfc4122>.
[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>.
[RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource
Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707,
February 2020, <https://www.rfc-editor.org/info/rfc8707>.
[RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key
for Code Exchange by OAuth Public Clients", RFC 7636, for Code Exchange by OAuth Public Clients", RFC 7636,
DOI 10.17487/RFC7636, September 2015, DOI 10.17487/RFC7636, September 2015,
<https://www.rfc-editor.org/info/rfc7636>. <https://www.rfc-editor.org/info/rfc7636>.
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and [RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", (JWT) Profile for OAuth 2.0 Client Authentication and
RFC 7591, DOI 10.17487/RFC7591, July 2015, Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May
<https://www.rfc-editor.org/info/rfc7591>. 2015, <https://www.rfc-editor.org/info/rfc7523>.
[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>.
[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>.
Appendix A. Document History Appendix A. Document History
[[ To be removed from the final specification ]] [[ To be removed from the final specification ]]
-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 -01
* Use the newish RFC v3 XML and HTML format * Use the newish RFC v3 XML and HTML format
* Added IANA registration request for * Added IANA registration request for
"pushed_authorization_request_endpoint" "pushed_authorization_request_endpoint"
* Changed abbrev to "OAuth PAR" * Changed abbrev to "OAuth PAR"
-00 (WG draft) -00 (WG draft)
* Reference RFC6749 sec 2.3.1 for client secret basic rather than * Reference RFC6749 sec 2.3.1 for client secret basic rather than
skipping to change at page 14, line 27 skipping to change at page 18, line 19
yes.com yes.com
Email: torsten@lodderstedt.net Email: torsten@lodderstedt.net
Brian Campbell Brian Campbell
Ping Identity Ping Identity
Email: bcampbell@pingidentity.com Email: bcampbell@pingidentity.com
Nat Sakimura Nat Sakimura
Nomura Research Institute NAT.Consulting
Email: nat@sakimura.org Email: nat@sakimura.org
Dave Tonge Dave Tonge
Moneyhub Financial Technology Moneyhub Financial Technology
Email: dave@tonge.org Email: dave@tonge.org
Filip Skokan Filip Skokan
Auth0 Auth0
 End of changes. 45 change blocks. 
107 lines changed or deleted 277 lines changed or added

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