draft-ietf-oauth-par-00.txt   draft-ietf-oauth-par-01.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: July 2, 2020 Ping Identity Expires: 21 August 2020 Ping Identity
N. Sakimura N. Sakimura
Nomura Research Institute Nomura Research Institute
D. Tonge D. Tonge
Moneyhub Financial Technology Moneyhub Financial Technology
F. Skokan F. Skokan
Auth0 Auth0
December 30, 2019 18 February 2020
OAuth 2.0 Pushed Authorization Requests OAuth 2.0 Pushed Authorization Requests
draft-ietf-oauth-par-00 draft-ietf-oauth-par-01
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 July 2, 2020. This Internet-Draft will expire on 21 August 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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 Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
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 . . . . . . . . . . . . 5 2. Pushed Authorization Request Endpoint . . . . . . . . . . . . 4
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 . . . . . . . . . . . 10
3.1.1. Authentication Required . . . . . . . . . . . . . . . 10 3.1.1. Authentication Required . . . . . . . . . . . . . . . 10
4. Authorization Request . . . . . . . . . . . . . . . . . . . . 10 4. Authorization Request . . . . . . . . . . . . . . . . . . . . 10
5. Authorization Server Metadata . . . . . . . . . . . . . . . . 10 5. Authorization Server Metadata . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6.1. Request URI Guessing . . . . . . . . . . . . . . . . . . 11 6.1. Request URI Guessing . . . . . . . . . . . . . . . . . . 11
6.2. Open Redirection . . . . . . . . . . . . . . . . . . . . 11 6.2. Open Redirection . . . . . . . . . . . . . . . . . . . . 11
6.3. Request Object Replay . . . . . . . . . . . . . . . . . . 11 6.3. Request Object Replay . . . . . . . . . . . . . . . . . . 11
6.4. Client Policy Change . . . . . . . . . . . . . . . . . . 11 6.4. Client Policy Change . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Normative References . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 10. Informative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Document History . . . . . . . . . . . . . . . . . . 13 Appendix A. Document History . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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:
o 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.
o There is no mechanism to ensure confidentiality of the request * There is no mechanism to ensure confidentiality of the request
parameters. parameters.
o Authorization request URLs can become quite large, especially in * Authorization request URLs can become quite large, especially in
scenarios requiring fine-grained authorization data. scenarios requiring fine-grained authorization data.
JWT Secured Authorization Request (JAR) [I-D.ietf-oauth-jwsreq] JWT Secured Authorization Request (JAR) [I-D.ietf-oauth-jwsreq]
provides solutions for those challenges by allowing OAuth clients to provides solutions for those challenges by allowing OAuth clients to
wrap authorization request parameters in a signed, and optionally wrap authorization request parameters in a signed, and optionally
encrypted, JSON Web Token (JWT), the so-called "Request Object". encrypted, JSON Web Token (JWT), the so-called "Request Object".
In order to cope with the size restrictions, JAR introduces the In order to cope with the size restrictions, JAR introduces the
"request_uri" parameter that allows clients to send a reference to a "request_uri" parameter that allows clients to send a reference to a
request object instead of the request object itself. request object instead of the request object itself.
skipping to change at page 5, line 43 skipping to change at page 5, line 35
its issuer identifier, token endpoint URL, or pushed authorization its issuer identifier, token endpoint URL, or pushed authorization
request endpoint URL as values that identify it as an intended request endpoint URL as values that identify it as an intended
audience. audience.
2.1. Request 2.1. Request
A client can send all the parameters that usually comprise an A client can send all the parameters that usually comprise an
authorization request to the pushed authorization request endpoint. authorization request to the pushed authorization request endpoint.
A basic parameter set will typically include: A basic parameter set will typically include:
o "client_id" * "client_id"
o "response_type" * "response_type"
o "redirect_uri" * "redirect_uri"
o "scope" * "scope"
o "state" * "state"
o "code_challenge"
o "code_challenge_method" * "code_challenge"
* "code_challenge_method"
Depending on client type and authentication method, the request might Depending on client type and authentication method, the request might
also include other parameters for client authentication such as the also include other parameters for client authentication such as the
"client_secret" parameter, the "client_assertion" parameter and the "client_secret" parameter, the "client_assertion" parameter and the
"client_assertion_type" parameter. The "request_uri" authorization "client_assertion_type" parameter. The "request_uri" authorization
request parameter MUST NOT be provided in this case (see Section 3). request parameter MUST NOT be provided in this case (see Section 3).
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 also
skipping to change at page 7, line 27 skipping to change at page 7, line 18
Connect OPs), for example in Open Banking, where the certificate is Connect OPs), for example in Open Banking, where the certificate is
provided as part of a federated PKI. 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 that contains "request_uri" and URI and return a JSON response that contains "request_uri" and
"expires_in" members at the top level with "201 Created" HTTP "expires_in" members at the top level with "201 Created" HTTP
response code. response code.
o "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.
o "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 "request_uri" value MUST be generated using a cryptographically
strong pseudorandom algorithm such that it is computationally strong pseudorandom algorithm such that it is computationally
infeasible to predict or guess a valid value. infeasible to predict or guess a valid value.
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.
skipping to change at page 8, line 33 skipping to change at page 8, line 24
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.
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:
o 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.
o 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.
o 429: If the request from the client for a time period goes beyond * 429: If the request from the client for a time period goes beyond
the number the authorization server allows, the authorization the number the authorization server allows, the authorization
server responds with an HTTP 429 (Too Many Requests) status code. 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
skipping to change at page 11, line 43 skipping to change at page 11, line 36
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 7. Acknowledgements
This specification is based on the work towards Pushed Request Object This specification is based on the work towards Pushed Request Object
[1] conducted at the Financial-grade API working group at the OpenID (https://bitbucket.org/openid/fapi/src/master/
Foundation. We would like to thank the members of the WG for their Financial_API_Pushed_Request_Object.md) conducted at the Financial-
valuable contributions. grade API working group at the OpenID Foundation. We would like to
thank the members of the WG for their valuable contributions.
We would like to thank Vladimir Dzhuvinov, Aaron Parecki, Joseph We would like to thank Vladimir Dzhuvinov, Aaron Parecki, Joseph
Heenan, and Takahiko Kawasaki for their valuable feedback on this Heenan, and Takahiko Kawasaki for their valuable feedback on this
draft. draft.
8. IANA Considerations 8. IANA Considerations
... This specification requests registration of the following value in
the IANA "OAuth Authorization Server Metadata" registry of
[IANA.OAuth.Parameters] established by [RFC8414].
9. References Metadata Name: "pushed_authorization_request_endpoint"
Metadata Description: URL of the authorization server's pushed
authorization request endpoint
Change Controller: IESG
Specification Document(s): [[ this document ]]
9.1. Normative References 9. Normative 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>.
[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>.
[I-D.ietf-oauth-jwsreq] [I-D.ietf-oauth-jwsreq]
Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization
Framework: JWT Secured Authorization Request (JAR)", Framework: JWT Secured Authorization Request (JAR)", Work
draft-ietf-oauth-jwsreq-20 (work in progress), October in Progress, Internet-Draft, draft-ietf-oauth-jwsreq-20,
2019. 21 October 2019,
<https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-20>.
[OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and [OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0 incorporating C. Mortimore, "OpenID Connect Core 1.0 incorporating
errata set 1", Nov 2014, errata set 1", 8 November 2014,
<http://openid.net/specs/openid-connect-core-1_0.html>. <http://openid.net/specs/openid-connect-core-1_0.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
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>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 10. Informative References
Authorization Server Metadata", RFC 8414,
DOI 10.17487/RFC8414, June 2018,
<https://www.rfc-editor.org/info/rfc8414>.
9.2. Informative References [I-D.ietf-oauth-resource-indicators]
Campbell, B., Bradley, J., and H. Tschofenig, "Resource
Indicators for OAuth 2.0", Work in Progress, Internet-
Draft, draft-ietf-oauth-resource-indicators-08, 11
September 2019, <https://tools.ietf.org/html/draft-ietf-
oauth-resource-indicators-08>.
[I-D.ietf-oauth-mtls] [I-D.ietf-oauth-mtls]
Campbell, B., Bradley, J., Sakimura, N., and T. Campbell, B., Bradley, J., Sakimura, N., and T.
Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication
and Certificate-Bound Access Tokens", draft-ietf-oauth-
mtls-17 (work in progress), August 2019.
[I-D.ietf-oauth-resource-indicators] Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication
Campbell, B., Bradley, J., and H. Tschofenig, "Resource and Certificate-Bound Access Tokens", Work in Progress,
Indicators for OAuth 2.0", draft-ietf-oauth-resource- Internet-Draft, draft-ietf-oauth-mtls-17, 23 August 2019,
indicators-08 (work in progress), September 2019. <https://tools.ietf.org/html/draft-ietf-oauth-mtls-17>.
[RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token [RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
(JWT) Profile for OAuth 2.0 Client Authentication and (JWT) Profile for OAuth 2.0 Client Authentication and
Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May
2015, <https://www.rfc-editor.org/info/rfc7523>. 2015, <https://www.rfc-editor.org/info/rfc7523>.
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
RFC 7591, DOI 10.17487/RFC7591, July 2015,
<https://www.rfc-editor.org/info/rfc7591>.
[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>.
9.3. URIs [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
RFC 7591, DOI 10.17487/RFC7591, July 2015,
<https://www.rfc-editor.org/info/rfc7591>.
[1] https://bitbucket.org/openid/fapi/src/master/ [IANA.OAuth.Parameters]
Financial_API_Pushed_Request_Object.md IANA, "OAuth Parameters",
<http://www.iana.org/assignments/oauth-parameters>.
Appendix A. Document History Appendix A. Document History
[[ To be removed from the final specification ]] [[ To be removed from the final specification ]]
-01
* Use the newish RFC v3 XML and HTML format
* Added IANA registration request for
"pushed_authorization_request_endpoint"
* Changed abbrev to "OAuth PAR"
-00 (WG draft) -00 (WG draft)
o Reference RFC6749 sec 2.3.1 for client secret basic rather than * Reference RFC6749 sec 2.3.1 for client secret basic rather than
RFC7617 RFC7617
* further clarify that a request object JWT contains all the
o further clarify that a request object JWT contains all the
authorization request parameters while client authentication authorization request parameters while client authentication
params, if applicable, are outside that JWT as regular form params, if applicable, are outside that JWT as regular form
encoded params in HTTP body encoded params in HTTP body
-01 -01
o List "client_id" as one of the basic parameters * List "client_id" as one of the basic parameters
* Explicitly forbid "request_uri" in the processing rules
o Explicitly forbid "request_uri" in the processing rules * Clarification regarding client authentication and that public
o Clarification regarding client authentication and that public
clients are allowed clients are allowed
* Added option to let clients register per-authorization request
o Added option to let clients register per-authorization request
redirect URIs redirect URIs
* General clean up and wording improvements
o General clean up and wording improvements
-00 -00
o first draft * first draft
Authors' Addresses Authors' Addresses
Torsten Lodderstedt Torsten Lodderstedt
yes.com yes.com
Email: torsten@lodderstedt.net Email: torsten@lodderstedt.net
Brian Campbell Brian Campbell
Ping Identity Ping Identity
 End of changes. 44 change blocks. 
82 lines changed or deleted 93 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/