idnits 2.17.1 draft-bertocci-oauth2-tmi-bff-00.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 (12 February 2021) is 1168 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) == Outdated reference: A later version (-26) exists of draft-ietf-oauth-security-topics-16 == Outdated reference: A later version (-10) exists of draft-ietf-oauth-v2-1-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Web Authorization Protocol V. Bertocci 3 Internet-Draft auth0.com 4 Intended status: Standards Track B. Campbell 5 Expires: 16 August 2021 Ping Identity 6 12 February 2021 8 Token Mediating and session Information Backend For Frontend 9 draft-bertocci-oauth2-tmi-bff-00 11 Abstract 13 This document describes how a JavaScript frontend can delegate access 14 token acquisition to a backend component. In so doing, the frontend 15 can access resource servers directly without taking on the burden of 16 communicating with the authorization server, persisting tokens, and 17 performing operations that are fraught with security challenges when 18 executed in a user agent, but are safe and well proven when executed 19 by a confidential client running on a backend. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 16 August 2021. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Topology and Roles . . . . . . . . . . . . . . . . . . . 4 56 1.2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 5 57 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 7 58 3. Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 3.1. The bff-token Endpoint . . . . . . . . . . . . . . . . . 7 60 3.2. The bff-sessioninfo Endpoint . . . . . . . . . . . . . . 8 61 4. Requesting Access Tokens to the Backend . . . . . . . . . . . 8 62 4.1. Access Token Request . . . . . . . . . . . . . . . . . . 9 63 4.2. Access Token Response . . . . . . . . . . . . . . . . . . 9 64 4.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.3.1. No valid session found . . . . . . . . . . . . . . . 11 66 4.3.2. Backend cannot perform a request to the authorization 67 server . . . . . . . . . . . . . . . . . . . . . . . 11 68 4.3.3. The backend request to the authorization server 69 fails . . . . . . . . . . . . . . . . . . . . . . . . 11 70 5. Requesting Session Information from the Backend . . . . . . . 11 71 5.1. Session Information Request . . . . . . . . . . . . . . . 12 72 5.2. Session Information Response . . . . . . . . . . . . . . 12 73 5.3. Error . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 6.1. Frontend should not persist access tokens in local 76 storage . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 6.2. Mismatch between security characteristics of token 78 requestor and API caller . . . . . . . . . . . . . . . . 13 79 6.3. Mismatch between scopes in a request vs cached tokens . . 14 80 6.4. Resource server colocated with the backend . . . . . . . 14 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 8. Normative References . . . . . . . . . . . . . . . . . . . . 15 83 9. Informative References . . . . . . . . . . . . . . . . . . . 15 84 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 85 Appendix B. Document History . . . . . . . . . . . . . . . . . . 16 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 88 1. Introduction 90 A large portion of today's development stacks, practices and tools 91 for the web target the user agent itself as execution environment, 92 leveraging local resources to offer a rich, responsive user 93 experience that rivals native applications. 95 An important aspect of apps running in the user agent is their 96 reliance on HTTP APIs, served from the app's own backend component or 97 from third party providers on disparate domains. Whenever those API 98 are secured according to the OAuth2 Bearer Token Usage [RFC6750], the 99 user agent app needs to obtain suitable access tokens: however, the 100 task of implementing an OAuth2 [RFC6749] client executing in a user 101 agent is complicated by the many security challenges inherent in the 102 browser platform. The original OAuth2 [RFC6749] provided guidance 103 dedicated to user agent apps in section 4.2, via the implicit grant. 104 The approach proved to suffer from too many challenges, however, 105 leading subsequent documents (such as the OAuth2 security BCP 106 [I-D.ietf-oauth-security-topics] and OAuth 2.1 [I-D.ietf-oauth-v2-1]) 107 to recommend a more secure approach based on the authorization code 108 grant with PKCE [RFC7636], and relying on additional security 109 measures such as refresh token rotation and sender constraint. 111 Even the new guidance doesn't entirely eliminate some of the inherent 112 risks of implementing an OAuth2 client in a user agent. For example, 113 offering an acceptable experience for continuous use of the app 114 typically requires to persist tokens in local storage or to use 115 development patterns that are too complex for the average developer 116 to implement effectively. 118 In the attempt to avoid those limitations, developers are 119 increasingly pursuing approaches where their backend components (when 120 available) play a more active role. For example, there are many 121 solutions where the backend takes care of obtaining tokens from the 122 authorization server, using classic confidential client grants, and 123 provides a facade for every API the frontend needs to invoke: in that 124 way, the frontend can simply call the API via facade, securing 125 communications with its backend using mainstream methods such as any 126 cookie based web sign on technology. 128 That approach is not always viable, as in the absence of reverse 129 proxy deployments the creation and maintenance of a facade for 130 multiple APIs can be expensive. As a result, is is increasingly 131 common practice to use a simpler solution: rely on the backend 132 component for obtaining tokens from the authorization server, and 133 sending back to the frontend the resulting access tokens for direct 134 frontend to API communication. As long as the mechanism used for 135 transmitting tokens from the backend to the frontend is secure, the 136 approach is viable: however leaving the details of its implementation 137 to every application and stack developer results in the impossibility 138 to have frontend and backend development stacks to interoperate out 139 of the box. Furthermore, there are a number of security 140 considerations that, if disregarded in the implementation of the 141 pattern, might lead to elevation of privilege attacks and other 142 challenges. 144 This documents provides detailed guidance on how to implement the 145 pattern in which a frontend component can delegate token acquisition 146 to its backend component. By offering precise guidance on details 147 such as endpoints and messages format for each operation, this 148 specification will allow developers to create and consume off-the- 149 shelf components that will easily interoperate and allow mixing and 150 matching different frontend and backend SDKs, making it possible to 151 author single page apps consuming APIs on arbitrary domains without 152 suffering many of the security compromises normally associated to a 153 frontend-only approach. 155 Given that the pattern described here does not provide any artifact 156 that the frontend can use to obtain session information such as user 157 attributes, something traditional approaches to user agent apps 158 development do afford, this document also provides a mechanism for 159 the frontend to obtain session information from the backend. 161 1.1. Topology and Roles 163 This document describes how a single page application featuring a 164 backend can obtain tokens from an OAuth2 authorization server to 165 access a resource server, while minimizing reliance on browser 166 features known to suffer from security challenges. For what the 167 protocol flow is concerned, the topology can be broken down into four 168 roles: 170 Frontend: This represents the application code executing in the user 171 agent, controlling presentation and invoking one or more resource 172 servers. 174 Backend: The backed represents code executing on a server, in 175 particular on the same domain from where the frontend code has 176 been served. Backend and frontend are both under the control of 177 the same developer. 179 Resource Server: This represents a classic OAuth2 resource server as 180 described in Section 1.1 of OAuth2 [RFC6749], exposing the API the 181 frontend needs to invoke. See Section 6 for more details applying 182 to notable cases. 184 Authorization Server: This represents a classic OAuth2 authorization 185 server as described in Section 1.1 of OAuth2 [RFC6749], handling 186 authorization for the API the frontend needs to invoke. This 187 document does not introduce any changes in the standard 188 authorization server behavior, however see Section 6 for some 189 security considerations that might influence the policies of 190 individual servers. 192 1.2. Protocol Flow 194 This section provides a high level description of the way in which 195 the frontend can obtain and use access tokens with the help of its 196 backend. As a prerequisite for the flow described below, the backend 197 MUST have established a secure session with the user agent, so that 198 all requests from that user agent toward the backend occur over HTTPS 199 and carry a valid session artifact (such as a cookie) that the 200 backend can validate. This document does not mandate any specific 201 mechanism to establish and maintain that session. 203 [[ TODO SVG maybe someday... ]] 205 +---------------+ 206 | | 207 | Authorization | 208 | Server | 209 | | 210 +---------------+ 211 ^ | 212 | 213 | 214 (B) Token | 215 request | (C) Token 216 | response 217 | 218 | v 219 +-------------+ +---------------+ 220 | | | | 221 | |---(A) bff-token request-->| | 222 | Frontend | | Backend | 223 | |<--(D) bff-token response--| | 224 | | | | 225 +-------------+ +---------------+ 226 ^ | 227 | | 228 | | 229 | | +---------------+ 230 | | | | 231 | ----(E) Protected resource request---->| Resource | 232 | | Server | 233 ------(F) Protected resource response-------| | 234 | | 235 +---------------+ 237 Figure 1: An abstract diagram of the flow followed to obtain an 238 access token and access a protected resource 240 * (A) The frontend presents to the backend a request for an access 241 token for a given resource server 243 * (B) If the backend does not already have a suitable access token 244 obtained in previous flows and cached, it requests to the 245 authorization server a new access token with the required 246 characteristics, using any artifacts previousy obtained (eg 247 refresh token) and grants that will allow the authorization server 248 to issue the requested token without requiring user interaction. 250 * (C) The authorization server returns the requested token and any 251 additional information according to the grant used (eg validity, 252 actual scopes granted, etc) 254 * (D) The backend returns the requested access token to the frontend 256 * (E) The frontend presents the access token to the resource server 258 * (F) the resource server validates the incoming token and returns 259 the protected resource 261 2. Conventions and Definitions 263 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 264 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 265 "OPTIONAL" in this document are to be interpreted as described in BCP 266 14 [RFC2119] [RFC8174] when, and only when, they appear in all 267 capitals, as shown here. 269 3. Endpoints 271 This specification introduces "bff-token" and "bff-sessioninfo", two 272 specialized endpoints that the backend exposes to support the 273 frontend in acquiring tokens and user session information. For the 274 purpose of facilitating the implementation of the pattern with 275 minimal configuration requirements, these endpoints are published at 276 a ".well-known" location according to RFC 5785 [RFC5785]. Both 277 endpoint are meant to be used by the applications' frontend, and the 278 frontend only. As such, the backend MUST verify the the call is 279 occurring in the context of a secure session (e.g., by mandating the 280 presence of a valid session cookie received via HTTPS). 282 3.1. The bff-token Endpoint 284 The "bff-token" endpoint is exposed by the backend to allow the 285 frontend to request access tokens. By default, it is exposed at the 286 well-known relative URI "/.well-known/bff-token". The "bff-token" 287 endpoint URI MUST use the "https" scheme. The backend MUST support 288 the use of the HTTP "GET" method for the "bff-token" endpoint and MAY 289 support the use of the "POST" method as well. The backend MUST 290 ignore unrecognized request parameters. See Section 4 for more 291 details on how to use the "bff-token" endpoint. 293 3.2. The bff-sessioninfo Endpoint 295 The "bff-sessioninfo" endpoint is exposed by the backend to allow the 296 frontend to obtain information about the current user, so that it can 297 be accessed my the presentation code. 298 By default, it is exposed at the well-known relative URI "/.well- 299 known/bff-sessioninfo". The backend MUST support the use of the HTTP 300 "GET" method for the "bff-sessioninfo" endpoint. The backend MUST 301 ignore unrecognized request parameters. See Section 5 for more 302 details on how to use the "bff-sessioninfo" endpoint. 304 4. Requesting Access Tokens to the Backend 306 To obtain an access token, the frontend makes a request to the 307 backend at the "bff-token" endpoint URI. The flow includes the 308 following steps, as shown in Figure 1. 310 [[ TODO more granular error refs ]] 312 1. The frontend generates the request and sends it to the "bff- 313 token" endpoint as described in Section 4.1 (leg A in Figure 1). 315 2. The backend examines the request, validating whether it includes 316 a valid user session: if it doesn't, it rejects the request as 317 described in Section 4.3.1. 319 3. The backend extracts user information from the session, using 320 whatever mechanism it deems suitable, and verifies whether it 321 already has in storage a suitable access token satisfying the 322 request (see Section 6 for more details). If it does, it returns 323 it as described in (5). 325 4. If there is no suitable access token stored, the backend verifies 326 whether it has the necessary artifacts to request it to the 327 authorization server without requiring user interaction- for 328 example, by using a refresh token previously stored for the 329 current user. If it does, the backed contacts the authorization 330 server with a token request using the grant of choice (leg B in 331 Figure 1). In the absence of a suitable artifact required to 332 perform a request toward the authorization server, the backend 333 returns an error to the frontend as described in Section 4.3.2. 335 5. If the authorization server returns the requested token as 336 expected (leg C in Figure 1), the backend returns it to the 337 frontend, as shown in Leg D of Figure 1 and described in 338 Section 4.2. If the authorization server denies the request, the 339 backend returns an error to the frontend as described in 340 Section 4.3.3. 342 The following sections provide more details for each of the messages 343 described. 345 4.1. Access Token Request 347 The frontend requests an access token from the backend by specifying 348 the requirements the resulting token must meet. To do so, the 349 following parameters may be added to to the query component (or 350 request payload in the case of 'POST') of the "/.well-known/bff- 351 token" request URI using the "application/x-www-form-urlencoded" 352 format with a character encoding of UTF-8 as described in Appendix B 353 of [RFC6749]. 355 "resource" : The identifier of the desired resource server, as 356 defined in [RFC8707]. This parameter is OPTIONAL. 358 "scope" : The scope of the access request resulting in the desired 359 access token. This parameter follows the syntax described in 360 section 3.3 of [RFC6749]. This parameter is OPTIONAL. 362 Both parameters MAY be absent from the request. Given that the 363 frontend and the backend are components of the same application, it 364 is possible in some scenarios for the backend to determine what token 365 to return to the frontend without any specific requirement. For 366 example, the application might be consuming only one resource, with a 367 fixed set of scopes: that would make specifying that information in 368 the request from the frontend unnecessary. 370 The following is an example of request where both resource and scopes 371 are specified. 373 GET /.well-known/bff-token?scope=buy+sell 374 &resource=https%3A%2F%2Fapi.example.org%2Fstocks HTTP/1.1 375 Host: myapp.example.com 377 Note that the request does not need to specify any client attributes, 378 as those are all handled by the backend- and the presence of a pre- 379 existing session provides the context necessary for the backend to 380 select the right settings when crafting requests for the 381 authorization server. 383 4.2. Access Token Response 385 If the backend successfully obtains a suitable token, or has one 386 already cached, it returns it to the frontend in a message featuring 387 the following parameters. 389 "access_token" : The requested access token. This parameter is 390 REQUIRED. 392 "expires_in" : The lifetime in seconds of the access token, as 393 defined in section 5.1 of [RFC6749]. This parameter is REQUIRED, 394 if the information was made available from the authorization 395 server that originally issued the access token. 397 "scope" : The scope of the access token being returned as list of 398 space-delimited, case-sensitive strings, as defined in Section 3.3 399 of [RFC6749]. If the request contained a scope parameter, and the 400 scope of resulting token is different from the requested value, 401 this parameter is REQUIRED. In all other cases, the presence of 402 scope in the response is OPTIONAL. 404 The following is an example of access token response. 406 HTTP/1.1 200 OK 407 Content-Type: application/json 408 Cache-Control: no-cache, no-store 410 { 411 "access_token":"4bWc0ESC9aCc77LTC8EjR1pCfE4WxfNg", 412 "expires_in":3596, 413 "scope":"buy sell" 414 } 416 Note that if the backend elects to cache tokens, to serve future 417 requests from the frontend without contacting the authorization 418 server if still within the useful lifetime, it must also cache 419 expiration information and scopes in accordance to the requirements 420 expressed in this section. 422 4.3. Errors 424 When the backend fails to deliver to the frontend the requested 425 token, it responds with an HTTP 400 (Bad Request) status code and 426 includes the following parameters with the response: 428 "error" : An ASCII error code identifying the circumstances of the 429 error. See the next sections for details. This parameter is 430 REQUIRED. 432 "error_description" : OPTIONAL. A human-readable message describing 433 the error for troubleshooting purposes. 435 4.3.1. No valid session found 437 All requests to the backend MUST be performed in the context of a 438 valid authenticated session, typically by presenting a session cookie 439 over a TLS channel. If the backend cannot find or validate a 440 session, it must reject the request and return a message as described 441 in Section 4.3, with an error parameter value of "invalid_session". 443 4.3.2. Backend cannot perform a request to the authorization server 445 If the backend doesn't have the necessary artifacts (e.g., a refresh 446 token for the current user and/or requested resource) to request a 447 suitable access token to the authorization server without requiring 448 user interaction, it will reject the request and return a message as 449 described in Section 4.3, with an error parameter value of 450 "backend_not_ready". 452 4.3.3. The backend request to the authorization server fails 454 If the backend request to the authorization server fails, the backend 455 will return to the frontend a message as described in Section 4.3, 456 with as error parameter value the error parameter received in the 457 authorization server response (as described by section 5.2 of 458 [RFC6749] and, if present in the authorizations server response, will 459 include the error_description parameter with the same parameter value 460 as received by the authorization server. [[ TODO wow this sentence is 461 ugly. ]] 463 5. Requesting Session Information from the Backend 465 Application developers will often need to obtain information about 466 the current session (such as user attributes, session expiration, 467 etc) to display it to the end user, drive application behavior and 468 any other operation it would perform if the frontend would be in 469 charge of obtaining tokens directly. In the topology described in 470 this specification, most of the user experience is driven by the 471 frontend: however, the session information is inaccessible to the 472 user agent, as it is either kept in artifacts that the user agent 473 cannot inspect (opaque sessions cookies) or on the backend side. The 474 "/.well-known/bff-sessioninfo" endpoint is meant to restore the 475 developer's ability to access the session information they need, 476 without compromising the security of the solution. At any time, the 477 frontend can leverage the current secure session to send to the "bff- 478 sessioninfo" endpoint a request, and receive the needed session 479 information. The following sections provide details on request and 480 response messages. 482 5.1. Session Information Request 484 The frontend sends a request for session information via an HTTP GET, 485 using the "https" scheme in the context of a secure session. The 486 request has no parameters. The following is an example of session 487 information request. 489 GET /.well-known/bff-sessioninfo HTTP/1.1 490 Host: myapp.example.com 492 5.2. Session Information Response 494 If the request is executed in the context of a secure session, the 495 backend returns a JSON object containing any information it deems 496 appropriate to share with the frontend about the content of the 497 session. For example, if the session was established via OpenID 498 Connect [OIDC] the response might contain the session and user 499 attribute claims as defined in sections 2 and 5.1 of [OIDC]. The 500 following is a non-normative example of such a session information 501 response. 503 HTTP/1.1 200 OK 504 Content-Type: application/json 505 Cache-Control: no-cache, no-store 507 { 508 "iss": "https://as.example.com", 509 "sub": "24400320", 510 "exp": 1311281970, 511 "auth_time": 1311280969, 512 "preferred_username": "johnny", 513 "email_verified: "johnny@foo.com", 514 "given_name": "Jonathan", 515 "family_name" : "Swift" 516 } 518 It is worth noting that the backend isn't bound to any specific rule 519 and is free to return any information it deems necessary in this 520 message in the context of the application (frontend and backend) own 521 requirements. 523 5.3. Error 525 In case the frontend sends a request to bff-sessioninfo in the 526 absence of a valid secure session, the backend will return an error 527 as described in Section 4.3.2. For any other error situation, the 528 backend is free to determine what to signal to the frontend. [[ TODO 529 seems a bit weak... maybe a generic error? ]] 531 6. Security Considerations 533 The simplicity of the described pattern notwithstanding, there are a 534 number of important considerations that frontend, backend and SDK 535 implementers should keep in mind while implementing this approach. 537 6.1. Frontend should not persist access tokens in local storage 539 Part of the reason for which the pattern herein described was devised 540 is to help application developers to limit the attack surface of 541 their code executing in the user agent. Access tokens SHOULD NOT be 542 saved in local storage: they SHOULD be kept in memory, and retrieved 543 anew when necessary from the backend following Section 4. 545 6.2. Mismatch between security characteristics of token requestor and 546 API caller 548 Some authorization servers might express in their access tokens 549 whether the client obtaining it authenticated itself, or it behaved 550 as a public client. Resource servers might rely on that information 551 to infer the nature and security characteristics of the application 552 presenting the access token to them, and use that to drive 553 authorization decisions (e.g., only allow certain operations if the 554 caller is a confidential client). The pattern described here obtains 555 an access token through the backend, a confidential client, but the 556 access token is ultimately used by code executing in a far less 557 secure environment. Resource servers knowing that their clients will 558 use this pattern SHOULD refrain from using the client authentication 559 type as a factor in authorization decision, or, whenever possible, 560 should use whatever extensions the authorization server of choice 561 offers to signal that the requested access tokens will not be used by 562 a confidential client. As there are no standards to express in an 563 access token the nature of the client authentication used in 564 obtaining the token itself, this document does not provide a specific 565 mechanism to influence the authorization server and leaves the task, 566 in the rare cases it might be necessary, to individual 567 implementations. 569 6.3. Mismatch between scopes in a request vs cached tokens 571 The backend will likely cache token responses from the authorization 572 server, so that the backend can promptly serve equivalent requests 573 from the frontend without further roundtrips toward the authorization 574 server. That is a powerful optimization, but it presents scopes 575 elevation risks if applied indiscriminately. If the token cached by 576 the authorization server features a superset of the scopes requested 577 by the frontend, the backend SHOULD NOT return it to the frontend and 578 perform a new request with the smaller scopes set to the 579 authorization server. 581 6.4. Resource server colocated with the backend 583 If the only API invoked by the frontend happens to be colocated with 584 the backend, the frontend doesn't need to obtain access tokens to it: 585 it can simply use the same secure session leveraged to protect 586 requests to the token endpoints described here. The "bff-token" 587 isn't necessary in that scenario, although "bff-sessioninfo" retains 588 its usefulness to surface session and user information to the user 589 agent code. Also note that the presence of the "bff-token" endpoint 590 makes it possible to easily accommodate possible future evolutions 591 where the frontend needs to invoke APIs protected by resource servers 592 hosted elsewhere, without engendering changes in the security 593 property of the application. 595 7. IANA Considerations 597 This specification requests registration of the following two well- 598 known URIs in the IANA "Well-Known URIs" registry [IANA.well-known] 599 established by [RFC5785]. 601 The bff-token Endpoint 603 * URI suffix: bff-token 605 * Change Controller: IESG 607 * Specification Document: Section 3.1 [[ of this specification ]] 609 * Related information: (none) 611 The bff-sessioninfo Endpoint 613 * URI suffix: bff-sessioninfo 615 * Change Controller: IESG 616 * Specification Document: Section 3.2 [[ of this specification ]] 618 * Related information: (none) 620 # Miscellaneous 622 [[ TODO Should we say something about: Requests could be more 623 complicated than just scopes (think RAR) and the frontend might need 624 to tell more than scopes to the backend. In that case, just add 625 custom params and stir. ]] 627 [[ TODO We mentioned another thing, but I can't remember now. ]] 629 8. Normative References 631 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 632 Uniform Resource Identifiers (URIs)", RFC 5785, 633 DOI 10.17487/RFC5785, April 2010, 634 . 636 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 637 Framework: Bearer Token Usage", RFC 6750, 638 DOI 10.17487/RFC6750, October 2012, 639 . 641 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 642 RFC 6749, DOI 10.17487/RFC6749, October 2012, 643 . 645 9. Informative References 647 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 648 Requirement Levels", BCP 14, RFC 2119, 649 DOI 10.17487/RFC2119, March 1997, 650 . 652 [OIDC] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 653 C. Mortimore, "OpenID Connect Core 1.0 incorporating 654 errata set 1", 8 November 2014, 655 . 657 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 658 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 659 May 2017, . 661 [RFC8707] Campbell, B., Bradley, J., and H. Tschofenig, "Resource 662 Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, 663 February 2020, . 665 [IANA.well-known] 666 IANA, "Well-Known URIs", 667 . 669 [I-D.ietf-oauth-security-topics] 670 Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, 671 "OAuth 2.0 Security Best Current Practice", Work in 672 Progress, Internet-Draft, draft-ietf-oauth-security- 673 topics-16, 5 October 2020, . 676 [I-D.ietf-oauth-v2-1] 677 Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1 678 Authorization Framework", Work in Progress, Internet- 679 Draft, draft-ietf-oauth-v2-1-00, 30 July 2020, 680 . 682 [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key 683 for Code Exchange by OAuth Public Clients", RFC 7636, 684 DOI 10.17487/RFC7636, September 2015, 685 . 687 Appendix A. Acknowledgements 689 I wanted to thank the Academy, the viewers at home, etc.. 691 Appendix B. Document History 693 [[ To be removed from the final specification ]] 695 -00 697 * Literally willed into existence by a long haired gentleman from 698 the Seattle area 700 Authors' Addresses 702 Vittorio Bertocci 703 auth0.com 705 Email: vittorio@auth0.com 707 Brian Campbell 708 Ping Identity 710 Email: bcampbell@pingidentity.com