yes.com

torsten@lodderstedt.net

Ping Identity

bcampbell@pingidentity.com

NAT.Consulting

nat@sakimura.org

Moneyhub Financial Technology

dave@tonge.org

Auth0

panva.ip@gmail.com

Security Web Authorization Protocol security oauth2 This document defines the pushed authorization request (PAR) endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• .  Introduction
  • .  Introductory Example
  • .  Conventions and Terminology
• .  Pushed Authorization Request Endpoint
  • .  Request
  • .  Successful Response
  • .  Error Response
  • .  Management of Client Redirect URIs
• .  The "request" Request Parameter
• .  Authorization Request
• .  Authorization Server Metadata
• .  Client Metadata
• .  Security Considerations
  • .  Request URI Guessing
  • .  Open Redirection
  • .  Request Object Replay
  • .  Client Policy Change
  • .  Request URI Swapping
• .  Privacy Considerations
• .  IANA Considerations
  • .  OAuth Authorization Server Metadata
  • .  OAuth Dynamic Client Registration Metadata
  • .  OAuth URI Registration
• . References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Authors' Addresses

Introduction This document defines the pushed authorization request (PAR) endpoint, which enables an OAuth client to push the payload of an authorization request directly to the authorization server. A request URI value is received in exchange; it is used as reference to the authorization request payload data in a subsequent call to the authorization endpoint via the user agent. In OAuth , authorization request parameters are typically sent as URI query parameters via redirection in the user agent. This is simple but also yields challenges:

• There is no cryptographic integrity and authenticity protection. An attacker could, for example, modify the scope of access requested or swap the context of a payment transaction by changing scope values. Although protocol facilities exist to enable clients or users to detect some such changes, preventing modifications early in the process is a more robust solution.
• There is no mechanism to ensure confidentiality of the request parameters. Although HTTPS is required for the authorization endpoint, the request data passes through the user agent in the clear, and query string data can inadvertently leak to web server logs and to other sites via the referrer. The impact of such leakage can be significant, if personally 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 scenarios requiring fine-grained authorization data, which might cause errors in request processing.

JWT-Secured Authorization Request (JAR) provides solutions for the security challenges by allowing OAuth clients to wrap authorization request parameters in a Request Object, which is a signed and optionally encrypted JSON Web Token (JWT) . In order to cope with the size restrictions, JAR introduces the request_uri parameter that allows clients to send a reference to a Request Object instead of the Request Object itself. This document complements JAR by providing an interoperable way to push the payload of an authorization request directly to the authorization server in exchange for a request_uri value usable at the authorization server in a subsequent authorization request. PAR fosters OAuth security by providing clients a simple means for a confidential and integrity-protected authorization request. Clients requiring an even higher security level, especially cryptographically confirmed non-repudiation, are able to use JWT-based Request Objects as defined by in conjunction with PAR. PAR allows the authorization server to authenticate the client before 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 and Section 3.1.2.1 of , could also be used to cope with the request size limitations described above. However, it's only optional per , and, even when supported, it is a viable option for conventional web applications but is prohibitively difficult to use with installed mobile applications. As described in , those apps use platform-specific APIs to open the authorization request URI in the system browser. When a mobile app launches a browser, however, the resultant initial request is constrained to use the GET method. Using POST for the authorization request would require the app to first direct the browser to open a URI that the app controls via GET while somehow conveying the sizable authorization request payload and then having the resultant response contain the content and script to initiate a cross-site form POST towards the authorization server. PAR is simpler to use and has additional security benefits, as described above.

Introductory Example In conventional OAuth 2.0, 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 &client_id=CLIENT1234&state=duk681S8n00GsJpe7n9boxdzen &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1 Host: as.example.com Such a request could instead be pushed directly to the authorization server by the client with a POST request to the PAR endpoint as illustrated in the following example (extra line breaks and spaces for display purposes only). The client can authenticate (e.g., using JWT client assertion-based authentication as shown) because the request is made directly to the authorization server. POST /as/par HTTP/1.1 Host: as.example.com Content-Type: application/x-www-form-urlencoded &response_type=code &client_id=CLIENT1234&state=duk681S8n00GsJpe7n9boxdzen &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &client_assertion_type= urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer &client_assertion=eyJraWQiOiI0MiIsImFsZyI6IkVTMjU2In0.eyJpc3MiOiJDTE lFTlQxMjM0Iiwic3ViIjoiQ0xJRU5UMTIzNCIsImF1ZCI6Imh0dHBzOi8vc2VydmVyL mV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY4ODc4fQ.Igw8QrpAWRNPDGoWGRmJumLBM wbLjeIYwqWUu-ywgvvufl_0sQJftNs3bzjIrP0BV9rRG-3eI1Ksh0kQ1CwvzA The authorization server responds with a request URI: HTTP/1.1 201 Created Cache-Control: no-cache, no-store Content-Type: application/json { "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2", "expires_in": 90 } The client uses the request URI value to create the subsequent authorization request by directing the user agent to make an HTTP request to the authorization server's authorization endpoint like the following (extra line breaks and indentation for display purposes only): GET /authorize?client_id=CLIENT1234 &request_uri=urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1 Host: as.example.com

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This specification uses the terms "access token", "authorization server", "authorization endpoint", "authorization request", "token endpoint", and "client" defined by "The OAuth 2.0 Authorization Framework" .

Pushed Authorization Request Endpoint The pushed authorization request endpoint is an HTTP API at the authorization server that accepts HTTP POST requests with parameters in the HTTP request message body using the application/x-www-form-urlencoded format. This format has a character encoding of UTF-8, as described in . The PAR endpoint URL MUST use the "https" scheme. Authorization servers supporting PAR SHOULD include the URL of their pushed authorization request endpoint in their authorization server metadata document using the pushed_authorization_request_endpoint parameter as defined in . The endpoint accepts the authorization request parameters defined in for the authorization endpoint as well as all applicable extensions defined for the authorization endpoint. Some examples of such extensions include Proof Key for Code Exchange (PKCE) , Resource Indicators , and OpenID Connect (OIDC) . The endpoint MAY also support sending the set of authorization request parameters as a Request Object according to and of this document. The rules for client authentication as defined in for token endpoint requests, including the applicable authentication methods, apply for the PAR endpoint as well. If applicable, the token_endpoint_auth_method client metadata parameter indicates the registered authentication method for the client to use when making direct requests to the authorization server, including requests to the PAR endpoint. Similarly, the token_endpoint_auth_methods_supported authorization server metadata parameter lists client authentication methods supported by the authorization server when accepting direct requests from clients, including requests to the PAR endpoint. Due to historical reasons, there is potential ambiguity regarding the appropriate audience value to use when employing JWT client assertion-based authentication (defined in with private_key_jwt or client_secret_jwt authentication method names per Section 9 of ). To address that ambiguity, the issuer identifier URL of the authorization server according to SHOULD be used as the value of the audience. In order to facilitate 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.

Request A client sends the parameters that comprise an authorization request directly to the PAR endpoint. A typical parameter set might include: client_id, response_type, redirect_uri, scope, state, code_challenge, and code_challenge_method as shown in the example below. However, the pushed authorization request can be composed of any of the parameters applicable for use at the authorization endpoint, including those defined in as well as all applicable extensions. The request_uri authorization request parameter is one exception, and it MUST NOT be provided. 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). Such parameters are defined and registered for use at the token endpoint but are applicable only for client authentication. When present in a pushed authorization request, they are relied upon only for client authentication and are not germane to the authorization request itself. Any token endpoint parameters that are not related 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 constructs the message body of an HTTP POST request with parameters formatted with x-www-form-urlencoded using a character encoding of UTF-8, as described in . If applicable, the client also adds its authentication credentials to the request header or the request body using the same rules as for token endpoint requests. This is illustrated by the following example (extra line breaks in the message body for display purposes only): POST /as/par HTTP/1.1 Host: as.example.com Content-Type: application/x-www-form-urlencoded response_type=code&state=af0ifjsldkj&client_id=s6BhdRkqt3 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U &code_challenge_method=S256&scope=account-information &client_assertion_type= urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer &client_assertion=eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3Mi OiJzNkJoZFJrcXQzIiwic3ViIjoiczZCaGRSa3F0MyIsImF1ZCI6Imh0dHBzOi8vc 2VydmVyLmV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY5Njc3fQ.te4IdnP_DK4hWrh TWA6fyhy3fxlAQZAhfA4lmzRdpoP5uZb-E90R5YxzN1YDA8mnVdpgj_Bx1lG5r6se f5TlckApA3hahhC804dcqlE4naEmLISmN1pds2WxTMOUzZY8aKKSDzNTDqhyTgE-K dTb3RafRj7tdZb09zWs7c_moOvfVcQIoy5zz1BvLQKW1Y8JsYvdpu2AvpxRPbcP8W yeW9B6PL6_fy3pXYKG3e-qUcvPa9kan-mo9EoSgt-YTDQjK1nZMdXIqTluK9caVJE RWW0fD1Y11_tlOcJn-ya7v7d8YmFyJpkhZfm8x1FoeH0djEicXTixEkdRuzsgUCm6 GQ The authorization server MUST process the request as follows:

1. Authenticate the client in the same way as at the token endpoint ().
2. Reject the request if the request_uri authorization request parameter is provided.
3. Validate the pushed request as it would an authorization request sent to the authorization endpoint. For example, the authorization server checks whether the redirect URI matches one of the redirect URIs configured for the client and also checks whether the client is authorized for the scope for which it is requesting access. This validation allows the authorization server to refuse unauthorized or fraudulent requests early. The authorization server MAY omit validation steps that it is unable to perform when processing the pushed request; however, such checks MUST then be performed when processing the authorization request at the authorization endpoint.

The authorization server MAY allow clients with authentication credentials to establish per-authorization-request redirect URIs with every pushed authorization request. Described in more detail in , this is possible since, in contrast to , this specification gives the authorization server the ability to authenticate clients and validate client requests before the actual authorization request is performed.

Successful Response If the verification is successful, the server MUST generate a request URI and provide it in the response with a 201 HTTP status code. The following parameters are included as top-level members in the message body of the HTTP response using the application/json media type as defined by .

request_uri

The request URI corresponding to the authorization request posted. This URI is a single-use reference to the respective request data in the subsequent authorization request. The way the authorization process obtains the authorization request data is at the discretion of the authorization server and is out of scope of this specification. There is no need to make the authorization request data available to other parties via this URI.

expires_in

A JSON number that represents the lifetime of the request URI in seconds as a positive integer. The request URI lifetime is at the discretion of the authorization server but will typically be relatively short (e.g., between 5 and 600 seconds).

The format of the request_uri value is at the discretion of the authorization server, but it MUST contain some part generated using a cryptographically strong pseudorandom algorithm such that it is computationally infeasible to predict or guess a valid value (see for specifics). 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 request_uri value MUST be bound to the client that posted the authorization request. The following is an example of such a response: HTTP/1.1 201 Created Content-Type: application/json Cache-Control: no-cache, no-store { "request_uri": "urn:ietf:params:oauth:request_uri:6esc_11ACC5bwc014ltc14eY22c", "expires_in": 60 }

Error Response The authorization server returns an error response with the same format as is specified for error responses from the token endpoint in using the appropriate error code from therein or from . In those cases where prohibits automatic redirection with an error back to the requesting client and hence doesn't define an error code (for example, when the request fails due to a missing, invalid, or mismatching redirection URI), the invalid_request error code can be used as the default error code. Error codes defined by the OAuth extension can also be used when such an extension is involved in the initial processing of the authorization request that was pushed. Since initial processing of the pushed authorization request does not involve resource owner interaction, error codes related to user interaction, such as consent_required defined by , are never returned. If the client is required to use signed Request Objects, by either the authorization server or the client policy (see ), the authorization server MUST only accept requests complying with the definition given in and MUST refuse any other request with HTTP status code 400 and error code invalid_request. In addition to the above, the PAR endpoint can also make use of the following HTTP status codes:

405:

If the request did not use the POST method, the authorization server responds with an HTTP 405 (Method Not Allowed) status code.

413:

If the request size was beyond the upper bound that the authorization server allows, the authorization server responds with an HTTP 413 (Payload Too Large) status code.

429:

If the number of requests from a client during a particular time period exceeds the number the authorization server allows, the authorization server responds with an HTTP 429 (Too Many Requests) status code.

The following is an example of an error response from the PAR endpoint: HTTP/1.1 400 Bad Request Content-Type: application/json Cache-Control: no-cache, no-store { "error": "invalid_request", "error_description": "The redirect_uri is not valid for the given client" }

Management of Client Redirect URIs OAuth 2.0 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. However, the OAuth security BCP as well as the OAuth 2.1 specification require an authorization server to 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 PAR for clients that have established authentication credentials with the authorization server. This is possible since, in contrast to a conventional 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.

The "request" Request Parameter Clients MAY use the request parameter as defined in JAR to push a Request Object JWT to the authorization server. The rules for processing, signing, and encryption of the Request Object as defined in JAR apply. Request parameters required by a given client authentication method are included in the application/x-www-form-urlencoded request directly and are the only parameters other than request in the form body (e.g., mutual TLS client authentication uses the client_id HTTP request parameter, while JWT assertion-based client authentication uses client_assertion and client_assertion_type). All other request parameters, i.e., those pertaining to the authorization request itself, MUST appear as claims of the JWT representing the authorization request. The following is an example of a pushed authorization request using a signed Request Object with the same authorization request payload as the example in . The client is authenticated with JWT client assertion-based authentication (extra line breaks and spaces for display purposes only): POST /as/par HTTP/1.1 Host: as.example.com Content-Type: application/x-www-form-urlencoded client_assertion_type= urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer &client_assertion=eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3Mi OiJzNkJoZFJrcXQzIiwic3ViIjoiczZCaGRSa3F0MyIsImF1ZCI6Imh0dHBzOi8vc 2VydmVyLmV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY5Njc3fQ.te4IdnP_DK4hWrh TWA6fyhy3fxlAQZAhfA4lmzRdpoP5uZb-E90R5YxzN1YDA8mnVdpgj_Bx1lG5r6se f5TlckApA3hahhC804dcqlE4naEmLISmN1pds2WxTMOUzZY8aKKSDzNTDqhyTgE-K dTb3RafRj7tdZb09zWs7c_moOvfVcQIoy5zz1BvLQKW1Y8JsYvdpu2AvpxRPbcP8W yeW9B6PL6_fy3pXYKG3e-qUcvPa9kan-mo9EoSgt-YTDQjK1nZMdXIqTluK9caVJE RWW0fD1Y11_tlOcJn-ya7v7d8YmFyJpkhZfm8x1FoeH0djEicXTixEkdRuzsgUCm6 GQ &request=eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3MiOiJzNkJoZ FJrcXQzIiwiYXVkIjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJleHAiOj E2MjU4Njk2NzcsInJlc3BvbnNlX3R5cGUiOiJjb2RlIiwiY2xpZW50X2lkIjoiczZ CaGRSa3F0MyIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vY2xpZW50LmV4YW1wbGUu b3JnL2NiIiwic2NvcGUiOiJhY2NvdW50LWluZm9ybWF0aW9uIiwic3RhdGUiOiJhZ jBpZmpzbGRraiIsImNvZGVfY2hhbGxlbmdlIjoiSzItbHRjODNhY2M0aDBjOXc2RV NDX3JFTVRKM2J3dy11Q0hhb2VLMXQ4VSIsImNvZGVfY2hhbGxlbmdlX21ldGhvZCI 6IlMyNTYifQ.l9R3RC9bFBHry_8acObQjEf4fX5yfJkWUPfak3J3iiBm0aaQznPw5 BZ0B3VQZ9_KYdPt5bTkaflS5fSDklM3_7my9MyOSKFYmf46INk6ju_qUuC2crkOQX ZWYJB-0bnYEbdHpUjazFSUvN49cEGstNQeE-dKDWHNgEojgcuNA_pjKfL9VYp1dEA 6-WjXZ_OlJ7R_mBWpjFAzc0UkQwqX5hfOJoGTqB2tE4a4aB2z8iYlUJp0DeeYp_hP N6svtmdvte73p5bLGDFpRIlmrBQIAQuxiS0skORpXlS0cBcgHimXVnXOJG7E-A_lS _5y54dVLQPA1jKYx-fxbYSG7dp2fw &client_id=s6BhdRkqt3 The authorization server MUST take the following steps beyond the processing rules defined in :

1. If applicable, decrypt the Request Object as specified in JAR .
2. Validate the Request Object signature as specified in JAR .
3. If the client has authentication credentials established with the authorization server, reject the request if the authenticated client_id does not match the client_id claim in the Request Object. Additionally, requiring the iss claim to match the client_id is at the discretion of the authorization server.

The following RSA key pair, represented in JSON Web Key (JWK) format , can be used to validate or recreate the Request Object signature in the above example (extra line breaks and indentation 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" }

Authorization Request The client uses the request_uri value returned by the authorization server to build an authorization request as defined in . This is shown in the following example where the client directs the user agent to make the following HTTP request (extra line breaks and indentation for display purposes only): GET /authorize?client_id=s6BhdRkqt3&request_uri=urn%3Aietf%3Aparams %3Aoauth%3Arequest_uri%3A6esc_11ACC5bwc014ltc14eY22c HTTP/1.1 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. An expired request_uri MUST be rejected as invalid. The authorization server MUST validate authorization requests arising from a pushed request as it would any other 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 PAR be 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 PAR endpoint.

Authorization Server Metadata The following authorization server metadata parameters are introduced to signal the server's capability and policy with respect to PAR.

pushed_authorization_request_endpoint

The URL of the pushed authorization request endpoint at which a client can post an authorization request to exchange for a request_uri value usable at the authorization server.

require_pushed_authorization_requests

Boolean parameter indicating whether the authorization server accepts authorization request data only via PAR. If omitted, the default value is false.

Note that the presence of pushed_authorization_request_endpoint is sufficient for a client to determine that it may use the PAR flow. A request_uri value obtained from the PAR endpoint is usable at the authorization endpoint regardless of other authorization server metadata such as request_uri_parameter_supported or require_request_uri_registration .

Client Metadata The Dynamic Client Registration Protocol defines an API for dynamically registering OAuth 2.0 client metadata with authorization servers. The metadata defined by , 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 required 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 PAR. If omitted, the default value is false.

Security Considerations

Request URI Guessing An attacker could attempt to guess and replay a valid request URI value and try to impersonate the respective client. The authorization server MUST account for the considerations given in JAR , clause (d) on request URI entropy.

Open Redirection An attacker could try to register a redirect URI pointing to a site under their control in order to obtain authorization codes or launch other attacks towards the user. The authorization server MUST only accept new redirect URIs in the pushed authorization request from authenticated clients.

Request Object Replay An attacker could replay a request URI captured from a legitimate authorization request. In order to cope with such attacks, the authorization server SHOULD make the request URIs one-time use.

Client Policy Change The client policy might change between the lodging of the Request Object and the authorization request using a particular Request Object. Therefore, it is recommended that the authorization server check the request parameter against the client policy when processing the authorization request.

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.

Privacy Considerations OAuth 2.0 is a complex and flexible framework with broad-ranging privacy implications due to its very nature of 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. However, using PAR may improve privacy by reducing the potential for inadvertent information disclosure since it passes the authorization request data directly between the 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.

IANA Considerations

OAuth Authorization Server Metadata IANA has registered the following values in the IANA "OAuth Authorization Server Metadata" registry of established by .

Metadata Name:

pushed_authorization_request_endpoint

Metadata Description:

URL of the authorization server's pushed authorization request endpoint.

Change Controller:

IESG

Specification Document(s):

of RFC 9126

Metadata Name:

require_pushed_authorization_requests

Metadata Description:

Indicates whether the authorization server accepts authorization requests only via PAR.

Change Controller:

IESG

Specification Document(s):

of RFC 9126

OAuth Dynamic Client Registration Metadata IANA has registered the following value in the IANA "OAuth Dynamic Client Registration Metadata" registry of established by .

Client Metadata Name:

require_pushed_authorization_requests

Client Metadata Description:

Indicates whether the client is required to use PAR to initiate authorization requests.

Change Controller:

IESG

Specification Document(s):

of RFC 9126

OAuth URI Registration IANA has registered the following value in the "OAuth URI" registry of established by .

URN:

urn:ietf:params:oauth:request_uri:

Common Name:

A URN Sub-Namespace for OAuth Request URIs.

Change Controller:

IESG

Specification Document(s):

of RFC 9126

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that authorization request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that a) the communication through the user agents is not integrity protected and thus, the parameters can be tainted, b) the source of the communication is not authenticated, and c) the communication through the user agents can be monitored. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication, and confidentiality properties of the authorization request are attained. The request can be sent by value or by reference. Informative References IANA yes.com Yubico yes.com This document describes best current security practice for OAuth 2.0. It updates and extends the OAuth 2.0 Security Threat Model to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. Work in Progress The OAuth 2.1 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and an authorization service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 2.0 Authorization Framework described in RFC 6749. Work in Progress NRI Ping Identity Microsoft Google Salesforce Nomura Research Institute, Ltd. Ping Identity Microsoft Illumila This document establishes an IETF URN Sub-namespace for use with OAuth-related specifications. This document is not an Internet Standards Track specification; it is published for informational purposes. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication. This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy"). OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. This specification details the security and usability reasons why this is the case and how native apps and authorization servers can implement this best practice. This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access.

Acknowledgements This specification is based on the work on Pushed Request Object conducted at the Financial-grade API Working Group at the OpenID Foundation. We would like to thank the members of the WG for their valuable contributions. We would like to thank , , , , , , , , , , , , , , and for their valuable feedback on this document.

Authors' Addresses yes.com

torsten@lodderstedt.net

Ping Identity

bcampbell@pingidentity.com

NAT.Consulting

nat@sakimura.org

Moneyhub Financial Technology

dave@tonge.org

Auth0

panva.ip@gmail.com