idnits 2.17.1 draft-ietf-oauth-par-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (31 July 2020) is 1357 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-34) exists of draft-ietf-oauth-jwsreq-26 -- Possible downref: Non-RFC (?) normative reference: ref. 'OIDC' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Web Authorization Protocol T. Lodderstedt 3 Internet-Draft yes.com 4 Intended status: Standards Track B. Campbell 5 Expires: 1 February 2021 Ping Identity 6 N. Sakimura 7 NAT.Consulting 8 D. Tonge 9 Moneyhub Financial Technology 10 F. Skokan 11 Auth0 12 31 July 2020 14 OAuth 2.0 Pushed Authorization Requests 15 draft-ietf-oauth-par-03 17 Abstract 19 This document defines the pushed authorization request endpoint, 20 which allows clients to push the payload of an OAuth 2.0 21 authorization request to the authorization server via a direct 22 request and provides them with a request URI that is used as 23 reference to the data in a subsequent authorization request. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 1 February 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Conventions and Terminology . . . . . . . . . . . . . . . 5 60 2. Pushed Authorization Request Endpoint . . . . . . . . . . . . 5 61 2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.2. Successful Response . . . . . . . . . . . . . . . . . . . 8 63 2.3. Error Response . . . . . . . . . . . . . . . . . . . . . 9 64 3. "request" Parameter . . . . . . . . . . . . . . . . . . . . . 10 65 4. Authorization Request . . . . . . . . . . . . . . . . . . . . 12 66 5. Authorization Server Metadata . . . . . . . . . . . . . . . . 13 67 6. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 13 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 69 7.1. Request URI Guessing . . . . . . . . . . . . . . . . . . 14 70 7.2. Open Redirection . . . . . . . . . . . . . . . . . . . . 14 71 7.3. Request Object Replay . . . . . . . . . . . . . . . . . . 14 72 7.4. Client Policy Change . . . . . . . . . . . . . . . . . . 14 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 75 9.1. OAuth Authorization Server Metadata . . . . . . . . . . . 15 76 9.2. OAuth Dynamic Client Registration Metadata . . . . . . . 15 77 9.3. OAuth URI Registration . . . . . . . . . . . . . . . . . 15 78 10. Normative References . . . . . . . . . . . . . . . . . . . . 15 79 11. Informative References . . . . . . . . . . . . . . . . . . . 16 80 Appendix A. Document History . . . . . . . . . . . . . . . . . . 17 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 83 1. Introduction 85 In OAuth [RFC6749] authorization request parameters are typically 86 sent as URI query parameters via redirection in the user-agent. This 87 is simple but also yields challenges: 89 * There is no cryptographic integrity and authenticity protection. 90 An attacker could, for example, modify the ACR value requested by 91 the client or swap the context of a payment transaction 92 authorization by changing scope values. Although clients should 93 detect such changes by inspecting the token response data, 94 preventing such modifications early in the process would be a 95 better solution. 97 * There is no mechanism to ensure confidentiality of the request 98 parameters. This obviously is an issue if personal identifiable 99 information is sent in the authorization request, which might be 100 the case in identity and open banking scenarios. 102 * Authorization request URLs can become quite large, especially in 103 scenarios requiring fine-grained authorization data, which might 104 cause errors in request processing. 106 JWT Secured Authorization Request (JAR) [I-D.ietf-oauth-jwsreq] 107 provides solutions for the security challenges by allowing OAuth 108 clients to wrap authorization request parameters in a signed, and 109 optionally encrypted, JSON Web Token (JWT), the so-called "Request 110 Object". In order to cope with the size restrictions, JAR introduces 111 the "request_uri" parameter that allows clients to send a reference 112 to a request object instead of the request object itself. 114 This document complements JAR by providing an interoperable way to 115 push the payload of a request object directly to the authorization 116 server in exchange for a "request_uri". 118 It also allows for clients to push the form encoded authorization 119 request parameters to the authorization server in order to exchange 120 them for a request URI that the client can use in a subsequent 121 authorization request. 123 For example, a client typically initiates an authorization request by 124 directing the user-agent to make an HTTP request like the following: 126 GET /authorize?response_type=code 127 &client_id=s6BhdRkqt3&state=af0ifjsldkj 128 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1 129 Host: as.example.com 131 Such a request could instead be pushed directly to the authorization 132 server by the client as follows: 134 POST /as/par HTTP/1.1 135 Host: as.example.com 136 Content-Type: application/x-www-form-urlencoded 137 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 139 response_type=code 140 &client_id=s6BhdRkqt3&state=af0ifjsldkj 141 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb 143 The authorization server responds with a request URI: 145 HTTP/1.1 201 Created 146 Cache-Control: no-cache, no-store 147 Content-Type: application/json 149 { 151 "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2", 152 "expires_in": 90 153 } 155 The client uses the request URI value to create the subsequent 156 authorization request and directing the user-agent to make an HTTP 157 request like the following: 159 GET /authorize?client_id=s6BhdRkqt3& 160 request_uri=urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1 161 Host: as.example.com 163 The pushed authorization request endpoint fosters OAuth security by 164 providing all clients a simple means for a confidential and integrity 165 protected authorization request, but it also allows clients requiring 166 an even higher security level, especially cryptographically confirmed 167 non-repudiation, to explicitly adopt JWT-based request objects. 169 As a further benefit, the pushed authorization request allows the 170 authorization server to authenticate the clients before any user 171 interaction happens, i.e., the authorization server may refuse 172 unauthorized requests much earlier in the process and has much higher 173 confidence in the client's identity in the authorization process than 174 before. This generally improves security since it prevents attempts 175 to spoof confidential clients early in the process. 177 This is directly utilized by this draft to allow confidential clients 178 to set the redirect URI for every authorization request, which gives 179 them more flexibility in building redirect URI. And if the client 180 IDs and credentials are managed by some external authority (e.g. a 181 certification authority), explicit client registration with the 182 particular authorization server could practically be skipped. 184 Note: HTTP POST requests to the authorization endpoint as described 185 in Section 3.1 of [RFC6749] and Section 3.1.2.1 of [OIDC] could also 186 be used to cope with the request size limitations described above. 187 Although this is a viable option for traditional web applications, 188 it's difficult to use with mobile apps. Those apps typically invoke 189 a custom tab with an URL that is translated into a GET request. 190 Using POST would require the app to first open a web page under its 191 control in the custom tab that in turn would initiate the form POST 192 towards the authorization server. PAR is simpler to use and has 193 additional security benefits as described above. 195 1.1. Conventions and Terminology 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 199 "OPTIONAL" in this document are to be interpreted as described in BCP 200 14 [RFC2119] [RFC8174] when, and only when, they appear in all 201 capitals, as shown here. 203 This specification uses the terms "access token", "refresh token", 204 "authorization server", "resource server", "authorization endpoint", 205 "authorization request", "authorization response", "token endpoint", 206 "grant type", "access token request", "access token response", and 207 "client" defined by The OAuth 2.0 Authorization Framework [RFC6749]. 209 2. Pushed Authorization Request Endpoint 211 The pushed authorization request endpoint is an HTTP API at the 212 authorization server that accepts POST requests with parameters in 213 the HTTP request entity-body using the "application/x-www-form- 214 urlencoded" format with a character encoding of UTF-8 as described in 215 Appendix B of [RFC6749]. The pushed authorization request endpoint 216 URL MUST use the "https" scheme. 218 Authorization servers supporting pushed authorization requests SHOULD 219 include the URL of their pushed authorization request endpoint in 220 their authorization server metadata document [RFC8414] using the 221 "pushed_authorization_request_endpoint" parameter as defined in 222 Section 5. 224 The endpoint accepts the parameters defined in [RFC6749] for the 225 authorization endpoint as well as all applicable extensions defined 226 for the authorization endpoint. Some examples of such extensions 227 include PKCE [RFC7636], Resource Indicators [RFC8707], and OpenID 228 Connect [OIDC]. The endpoint also supports sending all authorization 229 request parameters as request object according to 230 [I-D.ietf-oauth-jwsreq]. 232 The rules for client authentication as defined in [RFC6749] for token 233 endpoint requests, including the applicable authentication methods, 234 apply for the pushed authorization request endpoint as well. If 235 applicable, the "token_endpoint_auth_method" client metadata 236 parameter indicates the registered authentication method for the 237 client to use when making direct requests to the authorization 238 server, including requests to the pushed authorization request 239 endpoint. 241 Note that there's some potential ambiguity around the appropriate 242 audience value to use when JWT client assertion based authentication 243 is employed. To address that ambiguity the issuer identifier URL of 244 the authorization server according to [RFC8414] SHOULD be used as the 245 value of the audience. In order to facilitate interoperability the 246 authorization server MUST accept its issuer identifier, token 247 endpoint URL, or pushed authorization request endpoint URL as values 248 that identify it as an intended audience. 250 2.1. Request 252 A client can send all the parameters that usually comprise an 253 authorization request to the pushed authorization request endpoint. 254 A basic parameter set will typically include: 256 * "client_id" 258 * "response_type" 260 * "redirect_uri" 262 * "scope" 264 * "state" 266 * "code_challenge" 268 * "code_challenge_method" 269 Depending on client type and authentication method, the request might 270 also include other parameters for client authentication such as the 271 "client_secret" parameter, the "client_assertion" parameter and the 272 "client_assertion_type" parameter. The "request_uri" authorization 273 request parameter MUST NOT be provided in this case (see Section 3). 275 The client adds the parameters in "x-www-form-urlencoded" format with 276 a character encoding of UTF-8 as described in Appendix B of [RFC6749] 277 to the body of an HTTP POST request. If applicable, the client also 278 adds client credentials to the request header or the request body 279 using the same rules as for token endpoint requests. 281 This is illustrated by the following example: 283 POST /as/par HTTP/1.1 284 Host: as.example.com 285 Content-Type: application/x-www-form-urlencoded 286 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 288 response_type=code& 289 state=af0ifjsldkj& 290 client_id=s6BhdRkqt3& 291 redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb& 292 code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U& 293 code_challenge_method=S256& 294 scope=ais 296 The authorization server MUST process the request as follows: 298 1. Authenticate the client in the same way as at the token endpoint. 300 2. Reject the request if the "request_uri" authorization request 301 parameter is provided. 303 3. Validate the pushed request as it would an authorization request 304 sent to the authorization endpoint. For example, the 305 authorization server checks whether the redirect URI matches one 306 of the redirect URIs configured for the client and also checks 307 whether the client is authorized for the scope for which it is 308 requesting access. This validation allows the authorization 309 server to refuse unauthorized or fraudulent requests early. The 310 authorization server MAY omit validation steps that it is unable 311 to perform when processing the pushed request, however such 312 checks MUST then be performed at the authorization endpoint. 314 The authorization server MAY allow confidential clients to establish 315 per-authorization request redirect URIs with every pushed 316 authorization request. This is possible since, in contrast to 318 [RFC6749], this specification gives the authorization server the 319 ability to authenticate and authorize clients before the actual 320 authorization request is performed. 322 This feature gives clients more flexibility in building redirect URIs 323 and, if the client IDs and credentials are managed by some authority 324 (CA or other type), the explicit client registration with the 325 particular authorization server (manually or via dynamic client 326 registration [RFC7591]) could practically be skipped. This makes 327 this mechanism especially useful for clients interacting with a 328 federation of authorization servers (or OpenID Connect Providers), 329 for example in Open Banking, where the certificate is provided as 330 part of a federated PKI. 332 2.2. Successful Response 334 If the verification is successful, the server MUST generate a request 335 URI and return a JSON response with the following members at the top 336 level with "201 Created" HTTP response code. 338 * "request_uri" : The request URI corresponding to the authorization 339 request posted. This URI is used as reference to the respective 340 request data in the subsequent authorization request only. The 341 way the authorization process obtains the authorization request 342 data is at the discretion of the authorization server and out of 343 scope of this specification. There is no need to make the 344 authorization request data available to other parties via this 345 URI. 347 * "expires_in" : A JSON number that represents the lifetime of the 348 request URI in seconds. The request URI lifetime is at the 349 discretion of the authorization server and will typically be 350 relatively short. 352 The format of the "request_uri" value is at the discretion of the 353 authorization server but it MUST contain some part generated using a 354 cryptographically strong pseudorandom algorithm such that it is 355 computationally infeasible to predict or guess a valid value. The 356 authorization server MAY construct the "request_uri" value using the 357 form "urn:ietf:params:oauth:request_uri:" with 358 "" as the random part of the URI that references the 359 respective authorization request data. The string representation of 360 a UUID as a URN per [RFC4122] is also an option for authorization 361 servers to construct "request_uri" values. 363 The "request_uri" MUST be bound to the client that posted the 364 authorization request. 366 Since parts of the request content, e.g. the "code_challenge" 367 parameter value, is unique to a certain authorization request, a 368 "request_uri" SHOULD be limited to one-time use. 370 The following is an example of such a response: 372 HTTP/1.1 201 Created 373 Content-Type: application/json 374 Cache-Control: no-cache, no-store 376 { 377 "request_uri": 378 "urn:ietf:params:oauth:request_uri:bwc4JK-ESC0w8acc191e-Y1LTC2", 379 "expires_in": 60 380 } 382 2.3. Error Response 384 For an error the authorization server sets an appropriate HTTP status 385 code and MAY include additional error parameters in the entity-body 386 of the HTTP response using the format specified for the token 387 endpoint in Section 5.2 of [RFC6749]. 389 If the authorization server sets an error code, it SHOULD be one of 390 the defined codes for the token endpoint in Section 5.2 or for the 391 authorization endpoint in Sections 4.1.2.1 and 4.2.2.1 of [RFC6749], 392 or by an OAuth extension if one is involved in the initial processing 393 of authorization request that was pushed. Since initial processing 394 of the pushed authorization request doesn't involve resource owner 395 interaction, error codes related to user interaction, such as 396 "consent_required" defined by [OIDC], are not returned. 398 If the client is required to use signed request objects, either by 399 authorization server or client policy (see [I-D.ietf-oauth-jwsreq], 400 section 10.5), the authorization server MUST only accept requests 401 complying with the definition given in Section 3 and MUST refuse any 402 other request with HTTP status code 400 and error code 403 "invalid_request". 405 In addition to the error codes above, the pushed authorization 406 request endpoint can also make use of the following HTTP status 407 codes: 409 * 405: If the request did not use POST, the authorization server 410 responds with an HTTP 405 (Method Not Allowed) status code. 412 * 413: If the request size was beyond the upper bound that the 413 authorization server allows, the authorization server responds 414 with an HTTP 413 (Payload Too Large) status code. 416 * 429: If the request from the client for a time period goes beyond 417 the number the authorization server allows, the authorization 418 server responds with an HTTP 429 (Too Many Requests) status code. 420 The following is an example of an error response from the pushed 421 authorization request endpoint: 423 HTTP/1.1 400 Bad Request 424 Content-Type: application/json 425 Cache-Control: no-cache, no-store 427 { 428 "error": "invalid_request", 429 "error_description": 430 "The redirect_uri is not valid for the given client" 431 } 433 3. "request" Parameter 435 Clients MAY use the "request" parameter as defined in JAR 436 [I-D.ietf-oauth-jwsreq] to push a request object JWT to the 437 authorization server. The rules for processing, signing, and 438 encryption of the request object as defined in JAR 439 [I-D.ietf-oauth-jwsreq] apply. When the "application/x-www-form- 440 urlencoded" HTTP entity-body "request" parameter is used, the request 441 object MUST contain all the authorization request parameters as 442 claims of the JWT. Additional request parameters as required by the 443 given client authentication method are to be included as 444 'application/x-www-form-urlencoded' parameters in the HTTP request 445 entity-body (e.g. Mutual TLS client authentication 446 [I-D.ietf-oauth-mtls] uses the "client_id" HTTP request parameter 447 while JWT assertion based client authentication [RFC7523] uses 448 "client_assertion" and "client_assertion_type"). 450 The following is an example of a pushed authorization request using a 451 signed request object. The client is authenticated by its client 452 secret using the HTTP Basic Authentication scheme specified in 453 Section 2.3.1 of [RFC6749]: 455 POST /as/par HTTP/1.1 456 Host: as.example.com 457 Content-Type: application/x-www-form-urlencoded 458 Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 460 request=eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3MiOiJzNkJoZ 461 FJrcXQzIiwiYXVkIjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJyZXNwb2 462 5zZV90eXBlIjoiY29kZSIsImNsaWVudF9pZCI6InM2QmhkUmtxdDMiLCJyZWRpcmV 463 jdF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsInNjb3BlIjoi 464 YWlzIiwic3RhdGUiOiJhZjBpZmpzbGRraiIsImNvZGVfY2hhbGxlbmdlIjoiSzItb 465 HRjODNhY2M0aDBjOXc2RVNDX3JFTVRKM2J3dy11Q0hhb2VLMXQ4VSIsImNvZGVfY2 466 hhbGxlbmdlX21ldGhvZCI6IlMyNTYifQ.O49ffUxRPdNkN3TRYDvbEYVr1CeAL64u 467 W4FenV3n9WlaFIRHeFblzv-wlEtMm8-tusGxeE9z3ek6FxkhvvLEqEpjthXnyXqqy 468 Jfq3k9GSf5ay74ml_0D6lHE1hy-kVWg7SgoPQ-GB1xQ9NRhF3EKS7UZIrUHbFUCF0 469 MsRLbmtIvaLYbQH_Ef3UkDLOGiU7exhVFTPeyQUTM9FF-u3K-zX-FO05_brYxNGLh 470 VkO1G8MjqQnn2HpAzlBd5179WTzTYhKmhTiwzH-qlBBI_9GLJmE3KOipko9TfSpa2 471 6H4JOlMyfZFl0PCJwkByS0xZFJ2sTo3Gkk488RQohhgt1I0onw 473 The authorization server needs to take the following steps beyond the 474 processing rules defined in Section 2.1: 476 1. If applicable, decrypt the request object as specified in JAR 477 [I-D.ietf-oauth-jwsreq], section 6.1. 479 2. Validates the request object signature as specified in JAR 480 [I-D.ietf-oauth-jwsreq], section 6.2. 482 3. If the client is a confidential client, the authorization server 483 MUST check whether the authenticated "client_id" matches the 484 "client_id" claim in the request object. If they do not match, 485 the authorization server MUST refuse to process the request. It 486 is at the authorization server's discretion to require the "iss" 487 claim to match the "client_id" as well. 489 The following RSA key pair, represented in JWK [RFC7517] format, can 490 be used to validate or recreate the request object signature in the 491 above example (line wraps within values for display purposes only): 493 { 494 "kty": "RSA", 495 "kid":"k2bdc", 496 "n": "y9Lqv4fCp6Ei-u2-ZCKq83YvbFEk6JMs_pSj76eMkddWRuWX2aBKGHAtKlE 497 5P7_vn__PCKZWePt3vGkB6ePgzAFu08NmKemwE5bQI0e6kIChtt_6KzT5Oa 498 aXDFI6qCLJmk51Cc4VYFaxgqevMncYrzaW_50mZ1yGSFIQzLYP8bijAHGVj 499 dEFgZaZEN9lsn_GdWLaJpHrB3ROlS50E45wxrlg9xMncVb8qDPuXZarvghL 500 L0HzOuYRadBJVoWZowDNTpKpk2RklZ7QaBO7XDv3uR7s_sf2g-bAjSYxYUG 501 sqkNA9b3xVW53am_UZZ3tZbFTIh557JICWKHlWj5uzeJXaw", 502 "e": "AQAB", 503 "d": "LNwG_pCKrwowALpCpRdcOKlSVqylSurZhE6CpkRiE9cpDgGKIkO9CxPlXOL 504 zjqxXuQc8MdMqRQZTnAwgd7HH0B6gncrruV3NewI-XQV0ckldTjqNfOTz1V 505 Rs-jE-57KAXI3YBIhu-_0YpIDzdk_wBuAk661Svn0GsPQe7m9DoxdzenQu9 506 O_soewUhlPzRrTH0EeIqYI715rwI3TYaSzoWBmEPD2fICyj18FF0MPy_SQz 507 k3noVUUIzfzLnnJiWy_p63QBCMqjRoSHHdMnI4z9iVpIwJWQ3jO5n_2lC2- 508 cSgwjmKsFzDBbQNJc7qMG1N6EssJUwgGJxz1eAUFf0w4YAQ", 509 "qi": "J-mG0swR4FTy3atrcQ7dd0hhYn1E9QndN- 510 -sDG4EQO0RnFj6wIefCvwIc4 511 7hCtVeFnCTPYJNc_JyV-mU-9vlzS5GSNuyR5qdpsMZXUMpEvQcwKt23ffPZ 512 YGaqfKyEesmf_Wi8fFcE68H9REQjnniKrXm7w2-IuG_IrVJA9Ox-uU", 513 "q": "4hlMYAGa0dvogdK1jnxQ7J_Lqpqi99e-AeoFvoYpMPhthChTzwFZO9lQmUo 514 BpMqVQTws_s7vWGmt7ZAB3ywkurf0pV7BD0fweJiUzrWk4KJjxtmP_auuxr 515 jvm3s2FUGn6f0wRY9Z8Hj9A7C72DnYCjuZiJQMYCWDsZ8-d-L1a-s", 516 "p": "5sd9Er3I2FFT9R-gy84_oakEyCmgw036B_nfYEEOCwpSvi2z7UcIVK3bSEL 517 5WCW6BNgB3HDWhq8aYPirwQnqm0K9mX1E-4xM10WWZ-rP3XjYpQeS0Snru5 518 LFVWsAzi-FX7BOqBibSAXLdEGXcXa44l08iec_bPD3xduq5V_1YoE", 519 "dq": "Nz2PF3XM6bEc4XsluKZO70ErdYdKgdtIJReUR7Rno_tOZpejwlPGBYVW19 520 zpAeYtCT82jxroB2XqhLxGeMxEPQpsz2qTKLSe4BgHY2ml2uxSDGdjcsrbb 521 NoKUKaN1CuyZszhWl1n0AT_bENl4bJgQj_Fh0UEsQj5YBBUJt5gr_k", 522 "dp": "Zc877jirkkLOtyTs2vxyNe9KnMNAmOidlUc2tE_-0gAL4Lpo1hSwKCtKwe 523 ZJ-gkqt1hT-dwNx_0Xtg_-NXsadMRMwJnzBMYwYAfjApUkfqABc0yUCJJl3 524 KozRCugf1WXkU9GZAH2_x8PUopdNUEa70ISowPRh04HANKX4fkjWAE" 525 } 527 4. Authorization Request 529 The client uses the "request_uri" value returned by the authorization 530 server to build an authorization request as defined in 531 [I-D.ietf-oauth-jwsreq]. This is shown in the following example 532 where the client directs the user-agent to make the following HTTP 533 request: 535 GET /authorize?client_id=s6BhdRkqt3&request_uri=urn%3Aietf%3Aparams 536 %3Aoauth%3Arequest_uri%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1 537 Host: as.example.com 539 The authorization server MUST validate authorization requests arising 540 from a pushed request as it would any other authorization request. 541 The authorization server MAY omit validation steps that it performed 542 when the request was pushed, provided that it can validate that the 543 request was a pushed request, and that the request or the 544 authorization server's policy has not been modified in a way that 545 would affect the outcome of the omitted steps. 547 Authorization server policy MAY dictate, either globally or on a per- 548 client basis, that pushed authorization requests are the only means 549 for a client to pass authorization request data. In this case, the 550 authorization server will refuse, using the "invalid_request" error 551 code, to process any request to the authorization endpoint that does 552 not have a "request_uri" parameter with a value obtained from the 553 pushed authorization request endpoint. 555 Note: authorization server and clients MAY use metadata as defined in 556 Section 5 and Section 6 to signal the desired behavior. 558 5. Authorization Server Metadata 560 The following authorization server metadata [RFC8414] parameters are 561 introduced to signal the server's capability and policy with respect 562 to pushed authorization requests. 564 "pushed_authorization_request_endpoint" The URL of the pushed 565 authorization request endpoint at which the client can post an 566 authorization request and get a request URI in exchange. 568 "require_pushed_authorization_requests" Boolean parameter indicating 569 whether the authorization server accepts authorization request 570 data only via the pushed authorization request method. If 571 omitted, the default value is "false". 573 6. Client Metadata 575 The Dynamic Client Registration Protocol [RFC7591] defines an API for 576 dynamically registering OAuth 2.0 client metadata with authorization 577 servers. The metadata defined by [RFC7591], and registered 578 extensions to it, also imply a general data model for clients that is 579 useful for authorization server implementations even when the Dynamic 580 Client Registration Protocol isn't in play. Such implementations 581 will typically have some sort of user interface available for 582 managing client configuration. The following client metadata 583 parameter is introduced by this document to indicate whether pushed 584 authorization requests are reqired for the given client. 586 "require_pushed_authorization_requests" Boolean parameter indicating 587 whether the only means of initiating an authorization request the 588 client is allowed to use is a pushed authorization request. 590 7. Security Considerations 592 7.1. Request URI Guessing 594 An attacker could attempt to guess and replay a valid request URI 595 value and try to impersonate the respective client. The 596 authorization server MUST consider the considerations given in JAR 597 [I-D.ietf-oauth-jwsreq], section 10.2, clause (d) on request URI 598 entropy. 600 7.2. Open Redirection 602 An attacker could try register a redirect URI pointing to a site 603 under his control in order to obtain authorization codes or lauch 604 other attacks towards the user. The authorization server MUST only 605 accept new redirect URIs in the PAR request from confidential clients 606 after successful authentication and authorization. 608 7.3. Request Object Replay 610 An attacker could replay a request URI captured from a legitimate 611 authorization request. In order to cope with such attacks, the 612 authorization server SHOULD make the request URIs one-time use. 614 7.4. Client Policy Change 616 The client policy might change between the lodging of the request 617 object and the authorization request using a particular request 618 object. It is therefore recommended that the authorization server 619 check the request parameter against the client policy when processing 620 the authorization request. 622 8. Acknowledgements 624 This specification is based on the work towards Pushed Request Object 625 (https://bitbucket.org/openid/fapi/src/master/ 626 Financial_API_Pushed_Request_Object.md) conducted at the Financial- 627 grade API working group at the OpenID Foundation. We would like to 628 thank the members of the WG for their valuable contributions. 630 We would like to thank Vladimir Dzhuvinov, Aaron Parecki, Justin 631 Richer, Sascha Preibisch, Daniel Fett, Michael B. Jones, Annabelle 632 Backman, Joseph Heenan, Sean Glencross, Maggie Hung, Neil Madden, and 633 Takahiko Kawasaki for their valuable feedback on this draft. 635 9. IANA Considerations 637 9.1. OAuth Authorization Server Metadata 639 This specification requests registration of the following values in 640 the IANA "OAuth Authorization Server Metadata" registry of 641 [IANA.OAuth.Parameters] established by [RFC8414]. 643 Metadata Name: "pushed_authorization_request_endpoint" 644 Metadata Description: URL of the authorization server's pushed 645 authorization request endpoint 646 Change Controller: IESG 647 Specification Document(s): Section 5 of [[ this document ]] 649 Metadata Name: "require_pushed_authorization_requests" 650 Metadata Description: Indicates whether the authorization server 651 accepts authorization request only via the pushed authorization 652 request method. 653 Change Controller: IESG 654 Specification Document(s): Section 5 of [[ this document ]] 656 9.2. OAuth Dynamic Client Registration Metadata 658 This specification requests registration of the following value in 659 the IANA "OAuth Dynamic Client Registration Metadata" registry of 660 [IANA.OAuth.Parameters] established by [RFC7591]. 662 Metadata Name: "require_pushed_authorization_requests" 663 Metadata Description: Indicates whether the client is required to 664 use the pushed authorization request method to initiate 665 authorization requests. 666 Change Controller: IESG 667 Specification Document(s): Section 6 of [[ this document ]] 669 9.3. OAuth URI Registration 671 This specification requests registration of the following value in 672 the "OAuth URI" registry of [IANA.OAuth.Parameters] established by 673 [RFC6755]. 675 URN: "urn:ietf:params:oauth:request_uri:" 676 Common Name: A URN Sub-Namespace for OAuth Request URIs. 677 Change Controller: IESG 678 Specification Document(s): Section 2.2 of [[ this document ]] 680 10. Normative References 682 [I-D.ietf-oauth-jwsreq] 683 Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization 684 Framework: JWT Secured Authorization Request (JAR)", Work 685 in Progress, Internet-Draft, draft-ietf-oauth-jwsreq-26, 686 27 July 2020, 687 . 689 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 690 Requirement Levels", BCP 14, RFC 2119, 691 DOI 10.17487/RFC2119, March 1997, 692 . 694 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 695 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 696 May 2017, . 698 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 699 RFC 6749, DOI 10.17487/RFC6749, October 2012, 700 . 702 [OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 703 C. Mortimore, "OpenID Connect Core 1.0 incorporating 704 errata set 1", 8 November 2014, 705 . 707 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 708 Authorization Server Metadata", RFC 8414, 709 DOI 10.17487/RFC8414, June 2018, 710 . 712 11. Informative References 714 [RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token 715 (JWT) Profile for OAuth 2.0 Client Authentication and 716 Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 717 2015, . 719 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 720 Unique IDentifier (UUID) URN Namespace", RFC 4122, 721 DOI 10.17487/RFC4122, July 2005, 722 . 724 [I-D.ietf-oauth-mtls] 725 Campbell, B., Bradley, J., Sakimura, N., and T. 726 Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication 727 and Certificate-Bound Access Tokens", Work in Progress, 728 Internet-Draft, draft-ietf-oauth-mtls-17, 23 August 2019, 729 . 731 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 732 DOI 10.17487/RFC7517, May 2015, 733 . 735 [IANA.OAuth.Parameters] 736 IANA, "OAuth Parameters", 737 . 739 [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace 740 for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012, 741 . 743 [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key 744 for Code Exchange by OAuth Public Clients", RFC 7636, 745 DOI 10.17487/RFC7636, September 2015, 746 . 748 [RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource 749 Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, 750 February 2020, . 752 [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 753 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 754 RFC 7591, DOI 10.17487/RFC7591, July 2015, 755 . 757 Appendix A. Document History 759 [[ To be removed from the final specification ]] 761 -03 763 * Editorial updates 765 * Mention that https is required for the PAR endpoint 767 * Add some discussion of browser form posting an authz request vs. 768 the benefits of PAR for any application 770 * Added text about motivations behind PAR - integrity, 771 confidentiality and early client auth 773 * Better explain one-time use recommendation of the request_uri 775 * Drop the section on special error responses for request objects 776 * Clarify authorization request examples to say that the client 777 directs the user-agent to make the HTTP GET request (vs. making 778 the request itself) 780 -02 782 * Update Resource Indicators reference to the somewhat recently 783 published RFC 8707 785 * Added metadata in support of pushed authorization requests only 786 feature 788 * Update to comply with draft-ietf-oauth-jwsreq-21, which requires 789 "client_id" in the authorization request in addition to the 790 "request_uri" 792 * Clarified timing of request validation 794 * Add some guidance/options on the request URI structure 796 * Add the key used in the request object example so that a reader 797 could validate or recreate the request object signature 799 * Update to draft-ietf-oauth-jwsreq-25 and added note regarding 800 "require_signed_request_object" 802 -01 804 * Use the newish RFC v3 XML and HTML format 805 * Added IANA registration request for 806 "pushed_authorization_request_endpoint" 807 * Changed abbrev to "OAuth PAR" 809 -00 (WG draft) 811 * Reference RFC6749 sec 2.3.1 for client secret basic rather than 812 RFC7617 813 * further clarify that a request object JWT contains all the 814 authorization request parameters while client authentication 815 params, if applicable, are outside that JWT as regular form 816 encoded params in HTTP body 818 -01 820 * List "client_id" as one of the basic parameters 821 * Explicitly forbid "request_uri" in the processing rules 822 * Clarification regarding client authentication and that public 823 clients are allowed 825 * Added option to let clients register per-authorization request 826 redirect URIs 827 * General clean up and wording improvements 829 -00 831 * first draft 833 Authors' Addresses 835 Torsten Lodderstedt 836 yes.com 838 Email: torsten@lodderstedt.net 840 Brian Campbell 841 Ping Identity 843 Email: bcampbell@pingidentity.com 845 Nat Sakimura 846 NAT.Consulting 848 Email: nat@sakimura.org 850 Dave Tonge 851 Moneyhub Financial Technology 853 Email: dave@tonge.org 855 Filip Skokan 856 Auth0 858 Email: panva.ip@gmail.com