idnits 2.17.1 draft-ietf-oauth-par-10.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 (29 July 2021) is 994 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 (-25) exists of draft-ietf-oauth-security-topics-18 == Outdated reference: A later version (-10) exists of draft-ietf-oauth-v2-1-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: 30 January 2022 Ping Identity 6 N. Sakimura 7 NAT.Consulting 8 D. Tonge 9 Moneyhub Financial Technology 10 F. Skokan 11 Auth0 12 29 July 2021 14 OAuth 2.0 Pushed Authorization Requests 15 draft-ietf-oauth-par-10 17 Abstract 19 This document defines the pushed authorization request (PAR) 20 endpoint, 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 call to the authorization 24 endpoint. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 30 January 2022. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Introductory Example . . . . . . . . . . . . . . . . . . 4 61 1.2. Conventions and Terminology . . . . . . . . . . . . . . . 5 62 2. Pushed Authorization Request Endpoint . . . . . . . . . . . . 6 63 2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.2. Successful Response . . . . . . . . . . . . . . . . . . . 9 65 2.3. Error Response . . . . . . . . . . . . . . . . . . . . . 10 66 2.4. Management of Client Redirect URIs . . . . . . . . . . . 11 67 3. The "request" Request Parameter . . . . . . . . . . . . . . . 12 68 4. Authorization Request . . . . . . . . . . . . . . . . . . . . 14 69 5. Authorization Server Metadata . . . . . . . . . . . . . . . . 15 70 6. Client Metadata . . . . . . . . . . . . . . . . . . . . . . . 16 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 72 7.1. Request URI Guessing . . . . . . . . . . . . . . . . . . 16 73 7.2. Open Redirection . . . . . . . . . . . . . . . . . . . . 16 74 7.3. Request Object Replay . . . . . . . . . . . . . . . . . . 16 75 7.4. Client Policy Change . . . . . . . . . . . . . . . . . . 17 76 7.5. Request URI Swapping . . . . . . . . . . . . . . . . . . 17 77 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 79 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 80 10.1. OAuth Authorization Server Metadata . . . . . . . . . . 18 81 10.2. OAuth Dynamic Client Registration Metadata . . . . . . . 18 82 10.3. OAuth URI Registration . . . . . . . . . . . . . . . . . 18 83 11. Normative References . . . . . . . . . . . . . . . . . . . . 18 84 12. Informative References . . . . . . . . . . . . . . . . . . . 19 85 Appendix A. Document History . . . . . . . . . . . . . . . . . . 21 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 88 1. Introduction 90 A pushed authorization request (PAR), defined by this document, 91 enables an OAuth [RFC6749] client to push the payload of an 92 authorization request directly to the authorization server. A 93 request URI value is received in in exchange, which is used as 94 reference to the authorization request payload data in a subsequent 95 call to the authorization endpoint via the user agent. 97 In OAuth [RFC6749] authorization request parameters are typically 98 sent as URI query parameters via redirection in the user agent. This 99 is simple but also yields challenges: 101 * There is no cryptographic integrity and authenticity protection. 102 An attacker could, for example, modify the scope of access 103 requested or swap the context of a payment transaction by changing 104 scope values. Although protocol facilities exist to enable 105 clients or users to detect some such changes, preventing 106 modifications early in the process is a more robust solution. 108 * There is no mechanism to ensure confidentiality of the request 109 parameters. Although HTTPS is required for the authorization 110 endpoint, the request data passes through the user agent in the 111 clear and query string data can inadvertently leak to web server 112 logs and to other sites via referer. The impact of such leakage 113 can be significant, if personally identifiable information or 114 other regulated data is sent in the authorization request (which 115 might well be the case in identity, open banking, and similar 116 scenarios). 118 * Authorization request URLs can become quite large, especially in 119 scenarios requiring fine-grained authorization data, which might 120 cause errors in request processing. 122 JWT Secured Authorization Request (JAR) [I-D.ietf-oauth-jwsreq] 123 provides solutions for the security challenges by allowing OAuth 124 clients to wrap authorization request parameters in a request object, 125 which is a signed and optionally encrypted JSON Web Token (JWT) 126 [RFC7519]. In order to cope with the size restrictions, JAR 127 introduces the "request_uri" parameter that allows clients to send a 128 reference to a request object instead of the request object itself. 130 This document complements JAR by providing an interoperable way to 131 push the payload of an authorization request directly to the 132 authorization server in exchange for a "request_uri" value usable at 133 the authorization server in a subsequent authorization request. 135 PAR fosters OAuth security by providing clients a simple means for a 136 confidential and integrity protected authorization request. Clients 137 requiring an even higher security level, especially cryptographically 138 confirmed non-repudiation, are able to use JWT-based request objects 139 as defined by [I-D.ietf-oauth-jwsreq] in conduction with PAR. 141 PAR allows the authorization server to authenticate the client before 142 any user interaction happens. The increased confidence in the 143 identity of the client during the authorization process allows the 144 authorization server to refuse illegitimate requests much earlier in 145 the process, which can prevent attempts to spoof clients or otherwise 146 tamper with or misuse an authorization request. 148 Note that HTTP "POST" requests to the authorization endpoint via the 149 user agent, as described in Section 3.1 of [RFC6749] and 150 Section 3.1.2.1 of [OIDC], could also be used to cope with the 151 request size limitations described above. However, it's only 152 optional per [RFC6749] and, even when supported, it is a viable 153 option for traditional web applications but is prohibitively 154 difficult to use with native mobile applications. As described in 155 [RFC8252] those apps use platform-specific APIs to open the 156 authorization request URI in the system browser. When a native app 157 launches a browser, however, the resultant initial request is 158 constrained to use the "GET" method. Using "POST" for the 159 authorization request would require the app to first direct the 160 browser to open a URI that the app controls via "GET" while somehow 161 conveying the sizable authorization request payload and then have the 162 resultant response contain content and script to initiate a cross- 163 site form "POST" towards the authorization server. PAR is simpler to 164 use and has additional security benefits described above. 166 1.1. Introductory Example 168 In traditional OAuth 2.0, a client typically initiates an 169 authorization request by directing the user agent to make an HTTP 170 request like the following to the authorization server's 171 authorization endpoint (extra line breaks and indentation for display 172 purposes only): 174 GET /authorize?response_type=code 175 &client_id=CLIENT1234&state=duk681S8n00GsJpe7n9boxdzen 176 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1 177 Host: as.example.com 179 Such a request could instead be pushed directly to the authorization 180 server by the client with a "POST" request to the PAR endpoint as 181 illustrated in the following example (extra line breaks and 182 whitespace for display purposes only). The client can authenticate 183 (e.g., using JWT client assertion based authentication as shown) 184 because the request is made directly to the authorization server. 186 POST /as/par HTTP/1.1 187 Host: as.example.com 188 Content-Type: application/x-www-form-urlencoded 190 &response_type=code 191 &client_id=CLIENT1234&state=duk681S8n00GsJpe7n9boxdzen 192 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb 193 &client_assertion_type= 194 urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer 195 &client_assertion=eyJraWQiOiI0MiIsImFsZyI6IkVTMjU2In0.eyJpc3MiOiJDTE 196 lFTlQxMjM0Iiwic3ViIjoiQ0xJRU5UMTIzNCIsImF1ZCI6Imh0dHBzOi8vc2VydmVyL 197 mV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY4ODc4fQ.Igw8QrpAWRNPDGoWGRmJumLBM 198 wbLjeIYwqWUu-ywgvvufl_0sQJftNs3bzjIrP0BV9rRG-3eI1Ksh0kQ1CwvzA 200 The authorization server responds with a request URI: 202 HTTP/1.1 201 Created 203 Cache-Control: no-cache, no-store 204 Content-Type: application/json 206 { 207 "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2", 208 "expires_in": 90 209 } 211 The client uses the request URI value to create the subsequent 212 authorization request by directing the user agent to make an HTTP 213 request to the authorization server's authorization endpoint like the 214 following (extra line breaks and indentation for display purposes 215 only): 217 GET /authorize?client_id=CLIENT1234 218 &request_uri=urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1 219 Host: as.example.com 221 1.2. Conventions and Terminology 223 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 224 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 225 "OPTIONAL" in this document are to be interpreted as described in BCP 226 14 [RFC2119] [RFC8174] when, and only when, they appear in all 227 capitals, as shown here. 229 This specification uses the terms "access token", "authorization 230 server", "authorization endpoint", "authorization request", "token 231 endpoint", and "client" defined by The OAuth 2.0 Authorization 232 Framework [RFC6749]. 234 2. Pushed Authorization Request Endpoint 236 The pushed authorization request endpoint is an HTTP API at the 237 authorization server that accepts HTTP "POST" requests with 238 parameters in the HTTP request message body using the "application/x- 239 www-form-urlencoded" format with a character encoding of UTF-8 as 240 described in Appendix B of [RFC6749]. The PAR endpoint URL MUST use 241 the "https" scheme. 243 Authorization servers supporting PAR SHOULD include the URL of their 244 pushed authorization request endpoint in their authorization server 245 metadata document [RFC8414] using the 246 "pushed_authorization_request_endpoint" parameter as defined in 247 Section 5. 249 The endpoint accepts the authorization request parameters defined in 250 [RFC6749] for the authorization endpoint as well as all applicable 251 extensions defined for the authorization endpoint. Some examples of 252 such extensions include PKCE [RFC7636], Resource Indicators 253 [RFC8707], and OpenID Connect [OIDC]. The endpoint MAY also support 254 sending the set of authorization request parameters as a request 255 object according to [I-D.ietf-oauth-jwsreq] and Section 3. 257 The rules for client authentication as defined in [RFC6749] for token 258 endpoint requests, including the applicable authentication methods, 259 apply for the PAR endpoint as well. If applicable, the 260 "token_endpoint_auth_method" client metadata [RFC7591] parameter 261 indicates the registered authentication method for the client to use 262 when making direct requests to the authorization server, including 263 requests to the PAR endpoint. Similarly, the 264 "token_endpoint_auth_methods_supported" authorization server metadata 265 [RFC8414] parameter lists client authentication methods supported by 266 the authorization server when accepting direct requests from clients, 267 including requests to the PAR endpoint. 269 Due to historical reasons there is potential ambiguity regarding the 270 appropriate audience value to use when employing JWT client assertion 271 based authentication (defined in Section 2.2 of [RFC7523] with 272 "private_key_jwt" or "client_secret_jwt" authentication method names 273 per Section 9 of [OIDC]). To address that ambiguity the issuer 274 identifier URL of the authorization server according to [RFC8414] 275 SHOULD be used as the value of the audience. In order to facilitate 276 interoperability the authorization server MUST accept its issuer 277 identifier, token endpoint URL, or pushed authorization request 278 endpoint URL as values that identify it as an intended audience. 280 2.1. Request 282 A client sends the parameters that comprise an authorization request 283 directly to the PAR endpoint. A typical parameter set might include: 284 "client_id", "response_type", "redirect_uri", "scope", "state", 285 "code_challenge", and "code_challenge_method" as shown in the example 286 below. However, the pushed authorization request can be composed of 287 any of the parameters applicable for use at authorization endpoint 288 including those defined in [RFC6749] as well as all applicable 289 extensions. The "request_uri" authorization request parameter is one 290 exception, which MUST NOT be provided. 292 The request also includes, as appropriate for the given client, any 293 additional parameters necessary for client authentication (e.g., 294 "client_secret", or "client_assertion" and "client_assertion_type"). 295 Such parameters are defined and registered for use at the token 296 endpoint but are applicable only for client authentication. When 297 present in a pushed authorization request, they are relied upon only 298 for client authentication and are not germane to the authorization 299 request itself. Any token endpoint parameters that are not related 300 to client authentication have no defined meaning for a pushed 301 authorization request. The "client_id" parameter is defined with the 302 same semantics for both authorization requests and requests to the 303 token endpoint; as a required authorization request parameter, it is 304 similarly required in a pushed authorization request. 306 The client constructs the message body of an HTTP "POST" request with 307 "x-www-form-urlencoded" formatted parameters using a character 308 encoding of UTF-8 as described in Appendix B of [RFC6749]. If 309 applicable, the client also adds its authentication credentials to 310 the request header or the request body using the same rules as for 311 token endpoint requests. 313 This is illustrated by the following example (extra line breaks in 314 the message body for display purposes only): 316 POST /as/par HTTP/1.1 317 Host: as.example.com 318 Content-Type: application/x-www-form-urlencoded 320 response_type=code&state=af0ifjsldkj&client_id=s6BhdRkqt3 321 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb 322 &code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U 323 &code_challenge_method=S256&scope=account-information 324 &client_assertion_type= 325 urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer 326 &client_assertion=eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3Mi 327 OiJzNkJoZFJrcXQzIiwic3ViIjoiczZCaGRSa3F0MyIsImF1ZCI6Imh0dHBzOi8vc 328 2VydmVyLmV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY5Njc3fQ.te4IdnP_DK4hWrh 329 TWA6fyhy3fxlAQZAhfA4lmzRdpoP5uZb-E90R5YxzN1YDA8mnVdpgj_Bx1lG5r6se 330 f5TlckApA3hahhC804dcqlE4naEmLISmN1pds2WxTMOUzZY8aKKSDzNTDqhyTgE-K 331 dTb3RafRj7tdZb09zWs7c_moOvfVcQIoy5zz1BvLQKW1Y8JsYvdpu2AvpxRPbcP8W 332 yeW9B6PL6_fy3pXYKG3e-qUcvPa9kan-mo9EoSgt-YTDQjK1nZMdXIqTluK9caVJE 333 RWW0fD1Y11_tlOcJn-ya7v7d8YmFyJpkhZfm8x1FoeH0djEicXTixEkdRuzsgUCm6 334 GQ 336 The authorization server MUST process the request as follows: 338 1. Authenticate the client in the same way as at the token endpoint 339 (Section 2.3 of [RFC6749]). 341 2. Reject the request if the "request_uri" authorization request 342 parameter is provided. 344 3. Validate the pushed request as it would an authorization request 345 sent to the authorization endpoint. For example, the 346 authorization server checks whether the redirect URI matches one 347 of the redirect URIs configured for the client and also checks 348 whether the client is authorized for the scope for which it is 349 requesting access. This validation allows the authorization 350 server to refuse unauthorized or fraudulent requests early. The 351 authorization server MAY omit validation steps that it is unable 352 to perform when processing the pushed request, however, such 353 checks MUST then be performed when processing the authorization 354 request at the authorization endpoint. 356 The authorization server MAY allow clients with authentication 357 credentials to establish per-authorization-request redirect URIs with 358 every pushed authorization request. Described in more detail in 359 Section 2.4, this is possible since, in contrast to [RFC6749], this 360 specification gives the authorization server the ability to 361 authenticate clients and validate client requests before the actual 362 authorization request is performed. 364 2.2. Successful Response 366 If the verification is successful, the server MUST generate a request 367 URI and provide it in the response with a "201" HTTP status code. 368 The following parameters are included as top-level members in the 369 message body of the HTTP response using the "application/json" media 370 type as defined by [RFC8259]. 372 * "request_uri" : The request URI corresponding to the authorization 373 request posted. This URI is a single-use reference to the 374 respective request data in the subsequent authorization request. 375 The way the authorization process obtains the authorization 376 request data is at the discretion of the authorization server and 377 out of scope of this specification. There is no need to make the 378 authorization request data available to other parties via this 379 URI. 381 * "expires_in" : A JSON number that represents the lifetime of the 382 request URI in seconds as a positive integer. The request URI 383 lifetime is at the discretion of the authorization server but will 384 typically be relatively short (e.g., between 5 and 600 seconds). 386 The format of the "request_uri" value is at the discretion of the 387 authorization server but it MUST contain some part generated using a 388 cryptographically strong pseudorandom algorithm such that it is 389 computationally infeasible to predict or guess a valid value (see 390 Section 10.10 of [RFC6749] for specifics). The authorization server 391 MAY construct the "request_uri" value using the form 392 "urn:ietf:params:oauth:request_uri:" with 393 "" as the random part of the URI that references the 394 respective authorization request data. 396 The "request_uri" value MUST be bound to the client that posted the 397 authorization request. 399 The following is an example of such a response: 401 HTTP/1.1 201 Created 402 Content-Type: application/json 403 Cache-Control: no-cache, no-store 405 { 406 "request_uri": 407 "urn:ietf:params:oauth:request_uri:6esc_11ACC5bwc014ltc14eY22c", 408 "expires_in": 60 409 } 411 2.3. Error Response 413 The authorization server returns an error response with the same 414 format as is specified for error responses from the token endpoint in 415 Section 5.2 of [RFC6749] using the appropriate error code from 416 therein or from Section 4.1.2.1 of [RFC6749]. In those cases where 417 Section 4.1.2.1 of [RFC6749] prohibits automatic redirection with an 418 error back to the requesting client and hence doesn't define an error 419 code, for example when the request fails due to a missing, invalid, 420 or mismatching redirection URI, the "invalid_request" error code can 421 be used as the default error code. Error codes defined by OAuth 422 extension can also be used when such an extension is involved in the 423 initial processing of authorization request that was pushed. Since 424 initial processing of the pushed authorization request does not 425 involve resource owner interaction, error codes related to user 426 interaction, such as "consent_required" defined by [OIDC], are never 427 returned. 429 If the client is required to use signed request objects, either by 430 authorization server or client policy (see [I-D.ietf-oauth-jwsreq], 431 section 10.5), the authorization server MUST only accept requests 432 complying with the definition given in Section 3 and MUST refuse any 433 other request with HTTP status code 400 and error code 434 "invalid_request". 436 In addition to the above, the PAR endpoint can also make use of the 437 following HTTP status codes: 439 * 405: If the request did not use the "POST" method, the 440 authorization server responds with an HTTP 405 (Method Not 441 Allowed) status code. 443 * 413: If the request size was beyond the upper bound that the 444 authorization server allows, the authorization server responds 445 with an HTTP 413 (Payload Too Large) status code. 447 * 429: If the number of requests from a client during a particular 448 time period exceeds the number the authorization server allows, 449 the authorization server responds with an HTTP 429 (Too Many 450 Requests) status code. 452 The following is an example of an error response from the PAR 453 endpoint: 455 HTTP/1.1 400 Bad Request 456 Content-Type: application/json 457 Cache-Control: no-cache, no-store 459 { 460 "error": "invalid_request", 461 "error_description": 462 "The redirect_uri is not valid for the given client" 463 } 465 2.4. Management of Client Redirect URIs 467 OAuth 2.0 [RFC6749] allows clients to use unregistered "redirect_uri" 468 values in certain circumstances or for the authorization server to 469 apply its own matching semantics to the "redirect_uri" value 470 presented by the client at the authorization endpoint. However, the 471 OAuth Security BCP [I-D.ietf-oauth-security-topics] as well as OAuth 472 2.1 [I-D.ietf-oauth-v2-1] require an authorization server exactly 473 match the "redirect_uri" parameter against the set of redirect URIs 474 previously established for a particular client. This is a means for 475 early detection of client impersonation attempts and prevents token 476 leakage and open redirection. As a downside, this can make client 477 management more cumbersome since the redirect URI is typically the 478 most volatile part of a client policy. 480 The exact matching requirement MAY be relaxed when using PAR for 481 clients that have established authentication credentials with the 482 authorization server. This is possible since, in contrast to a 483 traditional authorization request, the authorization server 484 authenticates the client before the authorization process starts and 485 thus ensures it is interacting with the legitimate client. The 486 authorization server MAY allow such clients to specify "redirect_uri" 487 values that were not previously registered with the authorization 488 server. This will give the client more flexibility (e.g., to mint 489 distinct redirect URI values per authorization server at runtime) and 490 can simplify client management. It is at the discretion of the 491 authorization server to apply restrictions on supplied "redirect_uri" 492 values, e.g., the authorization server MAY require a certain URI 493 prefix or allow only a query parameter to vary at runtime. 495 Note: The ability to set up transaction specific redirect URIs is 496 also useful in situations where client ids and corresponding 497 credentials and policies are managed by a trusted 3rd party, e.g. via 498 client certificates containing client permissions. Such an 499 externally managed client could interact with an authorization server 500 trusting the respective 3rd party without the need for an additional 501 registration step. 503 3. The "request" Request Parameter 505 Clients MAY use the "request" parameter as defined in JAR 506 [I-D.ietf-oauth-jwsreq] to push a request object JWT to the 507 authorization server. The rules for processing, signing, and 508 encryption of the request object as defined in JAR 509 [I-D.ietf-oauth-jwsreq] apply. Request parameters required by a 510 given client authentication method are included in the "application/ 511 x-www-form-urlencoded" request directly, and are the only parameters 512 other than "request" in the form body (e.g. Mutual TLS client 513 authentication [RFC8705] uses the "client_id" HTTP request parameter 514 while JWT assertion based client authentication [RFC7523] uses 515 "client_assertion" and "client_assertion_type"). All other request 516 parameters, i.e., those pertaining to the authorization request 517 itself, MUST appear as claims of the JWT representing the 518 authorization request. 520 The following is an example of a pushed authorization request using a 521 signed request object with the same authorization request payload as 522 the example in Section 2.1. The client is authenticated with JWT 523 client assertion based authentication [RFC7523] (extra line breaks 524 and whitespace for display purposes only): 526 POST /as/par HTTP/1.1 527 Host: as.example.com 528 Content-Type: application/x-www-form-urlencoded 530 client_assertion_type= 531 urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer 532 &client_assertion=eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3Mi 533 OiJzNkJoZFJrcXQzIiwic3ViIjoiczZCaGRSa3F0MyIsImF1ZCI6Imh0dHBzOi8vc 534 2VydmVyLmV4YW1wbGUuY29tIiwiZXhwIjoxNjI1ODY5Njc3fQ.te4IdnP_DK4hWrh 535 TWA6fyhy3fxlAQZAhfA4lmzRdpoP5uZb-E90R5YxzN1YDA8mnVdpgj_Bx1lG5r6se 536 f5TlckApA3hahhC804dcqlE4naEmLISmN1pds2WxTMOUzZY8aKKSDzNTDqhyTgE-K 537 dTb3RafRj7tdZb09zWs7c_moOvfVcQIoy5zz1BvLQKW1Y8JsYvdpu2AvpxRPbcP8W 538 yeW9B6PL6_fy3pXYKG3e-qUcvPa9kan-mo9EoSgt-YTDQjK1nZMdXIqTluK9caVJE 539 RWW0fD1Y11_tlOcJn-ya7v7d8YmFyJpkhZfm8x1FoeH0djEicXTixEkdRuzsgUCm6 540 GQ 541 &request=eyJraWQiOiJrMmJkYyIsImFsZyI6IlJTMjU2In0.eyJpc3MiOiJzNkJoZ 542 FJrcXQzIiwiYXVkIjoiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLCJleHAiOj 543 E2MjU4Njk2NzcsInJlc3BvbnNlX3R5cGUiOiJjb2RlIiwiY2xpZW50X2lkIjoiczZ 544 CaGRSa3F0MyIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vY2xpZW50LmV4YW1wbGUu 545 b3JnL2NiIiwic2NvcGUiOiJhY2NvdW50LWluZm9ybWF0aW9uIiwic3RhdGUiOiJhZ 546 jBpZmpzbGRraiIsImNvZGVfY2hhbGxlbmdlIjoiSzItbHRjODNhY2M0aDBjOXc2RV 547 NDX3JFTVRKM2J3dy11Q0hhb2VLMXQ4VSIsImNvZGVfY2hhbGxlbmdlX21ldGhvZCI 548 6IlMyNTYifQ.l9R3RC9bFBHry_8acObQjEf4fX5yfJkWUPfak3J3iiBm0aaQznPw5 549 BZ0B3VQZ9_KYdPt5bTkaflS5fSDklM3_7my9MyOSKFYmf46INk6ju_qUuC2crkOQX 550 ZWYJB-0bnYEbdHpUjazFSUvN49cEGstNQeE-dKDWHNgEojgcuNA_pjKfL9VYp1dEA 551 6-WjXZ_OlJ7R_mBWpjFAzc0UkQwqX5hfOJoGTqB2tE4a4aB2z8iYlUJp0DeeYp_hP 552 N6svtmdvte73p5bLGDFpRIlmrBQIAQuxiS0skORpXlS0cBcgHimXVnXOJG7E-A_lS 553 _5y54dVLQPA1jKYx-fxbYSG7dp2fw 554 &client_id=s6BhdRkqt3 556 The authorization server MUST take the following steps beyond the 557 processing rules defined in Section 2.1: 559 1. If applicable, decrypt the request object as specified in JAR 560 [I-D.ietf-oauth-jwsreq], section 6.1. 562 2. Validate the request object signature as specified in JAR 563 [I-D.ietf-oauth-jwsreq], section 6.2. 565 3. If the client has authentication credentials established with the 566 authorization server, reject the request if the authenticated 567 "client_id" does not match the "client_id" claim in the request 568 object. Additionally requiring the "iss" claim to match the 569 "client_id" is at the discretion of authorization server. 571 The following RSA key pair, represented in JWK [RFC7517] format, can 572 be used to validate or recreate the request object signature in the 573 above example (extra line breaks and indentation within values for 574 display purposes only): 576 { 577 "kty": "RSA", 578 "kid":"k2bdc", 579 "n": "y9Lqv4fCp6Ei-u2-ZCKq83YvbFEk6JMs_pSj76eMkddWRuWX2aBKGHAtKlE 580 5P7_vn__PCKZWePt3vGkB6ePgzAFu08NmKemwE5bQI0e6kIChtt_6KzT5Oa 581 aXDFI6qCLJmk51Cc4VYFaxgqevMncYrzaW_50mZ1yGSFIQzLYP8bijAHGVj 582 dEFgZaZEN9lsn_GdWLaJpHrB3ROlS50E45wxrlg9xMncVb8qDPuXZarvghL 583 L0HzOuYRadBJVoWZowDNTpKpk2RklZ7QaBO7XDv3uR7s_sf2g-bAjSYxYUG 584 sqkNA9b3xVW53am_UZZ3tZbFTIh557JICWKHlWj5uzeJXaw", 585 "e": "AQAB", 586 "d": "LNwG_pCKrwowALpCpRdcOKlSVqylSurZhE6CpkRiE9cpDgGKIkO9CxPlXOL 587 zjqxXuQc8MdMqRQZTnAwgd7HH0B6gncrruV3NewI-XQV0ckldTjqNfOTz1V 588 Rs-jE-57KAXI3YBIhu-_0YpIDzdk_wBuAk661Svn0GsPQe7m9DoxdzenQu9 589 O_soewUhlPzRrTH0EeIqYI715rwI3TYaSzoWBmEPD2fICyj18FF0MPy_SQz 590 k3noVUUIzfzLnnJiWy_p63QBCMqjRoSHHdMnI4z9iVpIwJWQ3jO5n_2lC2- 591 cSgwjmKsFzDBbQNJc7qMG1N6EssJUwgGJxz1eAUFf0w4YAQ", 592 "qi": "J-mG0swR4FTy3atrcQ7dd0hhYn1E9QndN- 593 -sDG4EQO0RnFj6wIefCvwIc4 594 7hCtVeFnCTPYJNc_JyV-mU-9vlzS5GSNuyR5qdpsMZXUMpEvQcwKt23ffPZ 595 YGaqfKyEesmf_Wi8fFcE68H9REQjnniKrXm7w2-IuG_IrVJA9Ox-uU", 596 "q": "4hlMYAGa0dvogdK1jnxQ7J_Lqpqi99e-AeoFvoYpMPhthChTzwFZO9lQmUo 597 BpMqVQTws_s7vWGmt7ZAB3ywkurf0pV7BD0fweJiUzrWk4KJjxtmP_auuxr 598 jvm3s2FUGn6f0wRY9Z8Hj9A7C72DnYCjuZiJQMYCWDsZ8-d-L1a-s", 599 "p": "5sd9Er3I2FFT9R-gy84_oakEyCmgw036B_nfYEEOCwpSvi2z7UcIVK3bSEL 600 5WCW6BNgB3HDWhq8aYPirwQnqm0K9mX1E-4xM10WWZ-rP3XjYpQeS0Snru5 601 LFVWsAzi-FX7BOqBibSAXLdEGXcXa44l08iec_bPD3xduq5V_1YoE", 602 "dq": "Nz2PF3XM6bEc4XsluKZO70ErdYdKgdtIJReUR7Rno_tOZpejwlPGBYVW19 603 zpAeYtCT82jxroB2XqhLxGeMxEPQpsz2qTKLSe4BgHY2ml2uxSDGdjcsrbb 604 NoKUKaN1CuyZszhWl1n0AT_bENl4bJgQj_Fh0UEsQj5YBBUJt5gr_k", 605 "dp": "Zc877jirkkLOtyTs2vxyNe9KnMNAmOidlUc2tE_-0gAL4Lpo1hSwKCtKwe 606 ZJ-gkqt1hT-dwNx_0Xtg_-NXsadMRMwJnzBMYwYAfjApUkfqABc0yUCJJl3 607 KozRCugf1WXkU9GZAH2_x8PUopdNUEa70ISowPRh04HANKX4fkjWAE" 608 } 610 4. Authorization Request 612 The client uses the "request_uri" value returned by the authorization 613 server to build an authorization request as defined in 614 [I-D.ietf-oauth-jwsreq]. This is shown in the following example 615 where the client directs the user agent to make the following HTTP 616 request (extra line breaks and indentation for display purposes 617 only): 619 GET /authorize?client_id=s6BhdRkqt3&request_uri=urn%3Aietf%3Aparams 620 %3Aoauth%3Arequest_uri%3A6esc_11ACC5bwc014ltc14eY22c HTTP/1.1 621 Host: as.example.com 623 Since parts of the authorization request content, e.g. the 624 "code_challenge" parameter value, are unique to a particular 625 authorization request, the client MUST only use a "request_uri" value 626 once. Authorization servers SHOULD treat "request_uri" values as 627 one-time use but MAY allow for duplicate requests due to a user 628 reloading/refreshing their user agent. An expired "request_uri" MUST 629 be rejected as invalid. 631 The authorization server MUST validate authorization requests arising 632 from a pushed request as it would any other authorization request. 633 The authorization server MAY omit validation steps that it performed 634 when the request was pushed, provided that it can validate that the 635 request was a pushed request, and that the request or the 636 authorization server's policy has not been modified in a way that 637 would affect the outcome of the omitted steps. 639 Authorization server policy MAY dictate, either globally or on a per- 640 client basis, that PAR is the only means for a client to pass 641 authorization request data. In this case, the authorization server 642 will refuse, using the "invalid_request" error code, to process any 643 request to the authorization endpoint that does not have a 644 "request_uri" parameter with a value obtained from the PAR endpoint. 646 Note: authorization server and clients MAY use metadata as defined in 647 Section 5 and Section 6 to signal the desired behavior. 649 5. Authorization Server Metadata 651 The following authorization server metadata [RFC8414] parameters are 652 introduced to signal the server's capability and policy with respect 653 to PAR. 655 "pushed_authorization_request_endpoint" The URL of the pushed 656 authorization request endpoint at which a client can post an 657 authorization request to exchange for a "request_uri" value usable 658 at the authorization server. 660 "require_pushed_authorization_requests" Boolean parameter indicating 661 whether the authorization server accepts authorization request 662 data only via PAR. If omitted, the default value is "false". 664 Note that the presence of "pushed_authorization_request_endpoint" is 665 sufficient for a client to determine that it may use the PAR flow. A 666 "request_uri" value obtained from the PAR endpoint is usable at the 667 authorization endpoint regardless of other authorization server 668 metadata such as "request_uri_parameter_supported" or 669 "require_request_uri_registration" [OIDC.Disco]. 671 6. Client Metadata 673 The Dynamic Client Registration Protocol [RFC7591] defines an API for 674 dynamically registering OAuth 2.0 client metadata with authorization 675 servers. The metadata defined by [RFC7591], and registered 676 extensions to it, also imply a general data model for clients that is 677 useful for authorization server implementations even when the Dynamic 678 Client Registration Protocol isn't in play. Such implementations 679 will typically have some sort of user interface available for 680 managing client configuration. The following client metadata 681 parameter is introduced by this document to indicate whether pushed 682 authorization requests are required for the given client. 684 "require_pushed_authorization_requests" Boolean parameter indicating 685 whether the only means of initiating an authorization request the 686 client is allowed to use is PAR. If omitted, the default value is 687 "false". 689 7. Security Considerations 691 7.1. Request URI Guessing 693 An attacker could attempt to guess and replay a valid request URI 694 value and try to impersonate the respective client. The 695 authorization server MUST consider the considerations given in JAR 696 [I-D.ietf-oauth-jwsreq], section 10.2, clause (d) on request URI 697 entropy. 699 7.2. Open Redirection 701 An attacker could try to register a redirect URI pointing to a site 702 under his control in order to obtain authorization codes or launch 703 other attacks towards the user. The authorization server MUST only 704 accept new redirect URIs in the pushed authorization request from 705 authenticated clients. 707 7.3. Request Object Replay 709 An attacker could replay a request URI captured from a legitimate 710 authorization request. In order to cope with such attacks, the 711 authorization server SHOULD make the request URIs one-time use. 713 7.4. Client Policy Change 715 The client policy might change between the lodging of the request 716 object and the authorization request using a particular request 717 object. It is therefore recommended that the authorization server 718 check the request parameter against the client policy when processing 719 the authorization request. 721 7.5. Request URI Swapping 723 An attacker could capture the request URI from one request and then 724 substitute it into a different authorization request. For example, 725 in the context of OpenID Connect, an attacker could replace a request 726 URI asking for a high level of authentication assurance with one that 727 requires a lower level of assurance. Clients SHOULD make use of PKCE 728 [RFC7636], a unique "state" parameter [RFC6749], or the OIDC "nonce" 729 parameter [OIDC] in the pushed request object to prevent this attack. 731 8. Privacy Considerations 733 OAuth 2.0 is a complex and flexible framework with broad-ranging 734 privacy implications due to the very nature of it having one entity 735 intermediate user authorization to data access between two other 736 entities. The privacy considerations of all of OAuth are beyond the 737 scope of this document, which only defines an alternative way of 738 initiating one message sequence in the larger framework. Using PAR, 739 however, may improve privacy by reducing the potential for 740 inadvertent information disclosure since it passes the authorization 741 request data directly between client and authorization server over a 742 secure connection in the message body of an HTTP request, rather than 743 in the query component of a URL that passes through the user agent in 744 the clear. 746 9. Acknowledgements 748 This specification is based on the work towards Pushed Request Object 749 (https://bitbucket.org/openid/fapi/src/master/ 750 Financial_API_Pushed_Request_Object.md) conducted at the Financial- 751 grade API working group at the OpenID Foundation. We would like to 752 thank the members of the WG for their valuable contributions. 754 We would like to thank Vladimir Dzhuvinov, Aaron Parecki, Justin 755 Richer, Sascha Preibisch, Daniel Fett, Michael B. Jones, Annabelle 756 Backman, Joseph Heenan, Sean Glencross, Maggie Hung, Neil Madden, 757 Karsten Meyer zu Selhausen, Roman Danyliw, Meral Shirazipour, and 758 Takahiko Kawasaki for their valuable feedback on this draft. 760 10. IANA Considerations 762 10.1. OAuth Authorization Server Metadata 764 This specification requests registration of the following values in 765 the IANA "OAuth Authorization Server Metadata" registry of 766 [IANA.OAuth.Parameters] established by [RFC8414]. 768 Metadata Name: "pushed_authorization_request_endpoint" 769 Metadata Description: URL of the authorization server's pushed 770 authorization request endpoint 771 Change Controller: IESG 772 Specification Document(s): Section 5 of [[ this document ]] 774 Metadata Name: "require_pushed_authorization_requests" 775 Metadata Description: Indicates whether the authorization server 776 accepts authorization requests only via PAR. 777 Change Controller: IESG 778 Specification Document(s): Section 5 of [[ this document ]] 780 10.2. OAuth Dynamic Client Registration Metadata 782 This specification requests registration of the following value in 783 the IANA "OAuth Dynamic Client Registration Metadata" registry of 784 [IANA.OAuth.Parameters] established by [RFC7591]. 786 Client Metadata Name: "require_pushed_authorization_requests" 787 Client Metadata Description: Indicates whether the client is 788 required to use the PAR to initiate authorization requests. 789 Change Controller: IESG 790 Specification Document(s): Section 6 of [[ this document ]] 792 10.3. OAuth URI Registration 794 This specification requests registration of the following value in 795 the "OAuth URI" registry of [IANA.OAuth.Parameters] established by 796 [RFC6755]. 798 URN: "urn:ietf:params:oauth:request_uri:" 799 Common Name: A URN Sub-Namespace for OAuth Request URIs. 800 Change Controller: IESG 801 Specification Document(s): Section 2.2 of [[ this document ]] 803 11. Normative References 805 [I-D.ietf-oauth-jwsreq] 806 Sakimura, N., Bradley, J., and M. B. Jones, "The OAuth 2.0 807 Authorization Framework: JWT Secured Authorization Request 808 (JAR)", Work in Progress, Internet-Draft, draft-ietf- 809 oauth-jwsreq-34, 8 April 2021, 810 . 813 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 814 Requirement Levels", BCP 14, RFC 2119, 815 DOI 10.17487/RFC2119, March 1997, 816 . 818 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 819 RFC 6749, DOI 10.17487/RFC6749, October 2012, 820 . 822 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 823 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 824 May 2017, . 826 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 827 Interchange Format", STD 90, RFC 8259, 828 DOI 10.17487/RFC8259, December 2017, 829 . 831 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 832 Authorization Server Metadata", RFC 8414, 833 DOI 10.17487/RFC8414, June 2018, 834 . 836 12. Informative References 838 [I-D.ietf-oauth-security-topics] 839 Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, 840 "OAuth 2.0 Security Best Current Practice", Work in 841 Progress, Internet-Draft, draft-ietf-oauth-security- 842 topics-18, 13 April 2021, 843 . 846 [I-D.ietf-oauth-v2-1] 847 Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1 848 Authorization Framework", Work in Progress, Internet- 849 Draft, draft-ietf-oauth-v2-1-02, 15 March 2021, 850 . 853 [IANA.OAuth.Parameters] 854 IANA, "OAuth Parameters", 855 . 857 [OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 858 C. Mortimore, "OpenID Connect Core 1.0 incorporating 859 errata set 1", 8 November 2014, 860 . 862 [OIDC.Disco] 863 Sakimura, N., Bradley, J., Jones, M.B., and E. Jay, 864 "OpenID Connect Discovery 1.0", 8 November 2014, 865 . 868 [RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace 869 for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012, 870 . 872 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 873 DOI 10.17487/RFC7517, May 2015, 874 . 876 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 877 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 878 . 880 [RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token 881 (JWT) Profile for OAuth 2.0 Client Authentication and 882 Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 883 2015, . 885 [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 886 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 887 RFC 7591, DOI 10.17487/RFC7591, July 2015, 888 . 890 [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key 891 for Code Exchange by OAuth Public Clients", RFC 7636, 892 DOI 10.17487/RFC7636, September 2015, 893 . 895 [RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", 896 BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017, 897 . 899 [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. 900 Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication 901 and Certificate-Bound Access Tokens", RFC 8705, 902 DOI 10.17487/RFC8705, February 2020, 903 . 905 [RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource 906 Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, 907 February 2020, . 909 Appendix A. Document History 911 [[ To be removed from the final specification ]] 913 -10 915 * Updates from mistakenly overlooked IESG evaluation comments 917 -09 919 * Editorial fixes from Genart last call review 921 * Updates from IESG evaluation comments 923 -08 925 * Updates to address feedback from AD Review 926 https://mailarchive.ietf.org/arch/msg/oauth/ 927 bGSyonUqsvJ1vtY7l_ohwov25SA/ 928 (https://mailarchive.ietf.org/arch/msg/oauth/ 929 bGSyonUqsvJ1vtY7l_ohwov25SA/) 931 -07 933 * updated references (however they did not actually update due to 934 tooling issues - some info in this thread: 935 https://mailarchive.ietf.org/arch/msg/xml2rfc/ 936 zqYiMxZ070SCIi7CRNF9vbDeYno/ 937 (https://mailarchive.ietf.org/arch/msg/xml2rfc/ 938 zqYiMxZ070SCIi7CRNF9vbDeYno/) ) 940 -06 942 * Add a note clarifying that the presence of 943 "pushed_authorization_request_endpoint" is sufficient for a client 944 to know that it can use the PAR flow 946 -05 948 * Mention use of "invalid_request" error code for cases, like a bad 949 "redirect_uri", that don't have a more specific one 951 -04 952 * Edits to address WGLC comments 954 * Replace I-D.ietf-oauth-mtls reference with now published RFC8705 956 * Moved text about redirect URI management from introduction into 957 separate section 959 -03 961 * Editorial updates 963 * Mention that https is required for the PAR endpoint 965 * Add some discussion of browser form posting an authz request vs. 966 the benefits of PAR for any application 968 * Added text about motivations behind PAR - integrity, 969 confidentiality and early client auth 971 * Better explain one-time use recommendation of the request_uri 973 * Drop the section on special error responses for request objects 975 * Clarify authorization request examples to say that the client 976 directs the user agent to make the HTTP GET request (vs. making 977 the request itself) 979 -02 981 * Update Resource Indicators reference to the somewhat recently 982 published RFC 8707 984 * Added metadata in support of pushed authorization requests only 985 feature 987 * Update to comply with draft-ietf-oauth-jwsreq-21, which requires 988 "client_id" in the authorization request in addition to the 989 "request_uri" 991 * Clarified timing of request validation 993 * Add some guidance/options on the request URI structure 995 * Add the key used in the request object example so that a reader 996 could validate or recreate the request object signature 998 * Update to draft-ietf-oauth-jwsreq-25 and added note regarding 999 "require_signed_request_object" 1001 -01 1003 * Use the newish RFC v3 XML and HTML format 1004 * Added IANA registration request for 1005 "pushed_authorization_request_endpoint" 1006 * Changed abbrev to "OAuth PAR" 1008 -00 (WG draft) 1010 * Reference RFC6749 sec 2.3.1 for client secret basic rather than 1011 RFC7617 1012 * further clarify that a request object JWT contains all the 1013 authorization request parameters while client authentication 1014 params, if applicable, are outside that JWT as regular form 1015 encoded params in HTTP body 1017 -01 1019 * List "client_id" as one of the basic parameters 1020 * Explicitly forbid "request_uri" in the processing rules 1021 * Clarification regarding client authentication and that public 1022 clients are allowed 1023 * Added option to let clients register per-authorization request 1024 redirect URIs 1025 * General clean up and wording improvements 1027 -00 1029 * first draft 1031 Authors' Addresses 1033 Torsten Lodderstedt 1034 yes.com 1036 Email: torsten@lodderstedt.net 1038 Brian Campbell 1039 Ping Identity 1041 Email: bcampbell@pingidentity.com 1043 Nat Sakimura 1044 NAT.Consulting 1046 Email: nat@sakimura.org 1047 Dave Tonge 1048 Moneyhub Financial Technology 1050 Email: dave@tonge.org 1052 Filip Skokan 1053 Auth0 1055 Email: panva.ip@gmail.com