idnits 2.17.1 draft-ietf-oauth-access-token-jwt-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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 16, 2019) is 1593 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) == Unused Reference: 'RFC3986' is defined on line 587, but no explicit reference was found in the text == Unused Reference: 'RFC7644' is defined on line 634, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ResourceIndicators' -- Possible downref: Non-RFC (?) normative reference: ref. 'TokenExchange' Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth Working Group V. Bertocci 3 Internet-Draft Auth0 4 Intended status: Standards Track December 16, 2019 5 Expires: June 18, 2020 7 JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens 8 draft-ietf-oauth-access-token-jwt-03 10 Abstract 12 This specification defines a profile for issuing OAuth 2.0 access 13 tokens in JSON web token (JWT) format. Authorization servers and 14 resource servers from different vendors can leverage this profile to 15 issue and consume access tokens in interoperable manner. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 18, 2020. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Notation and Conventions . . . . . . . . . . 3 53 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. JWT Access Token Header and Data Structure . . . . . . . . . 4 55 2.1. Header . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.2. Data Structure . . . . . . . . . . . . . . . . . . . . . 4 57 2.2.1. Identity Claims . . . . . . . . . . . . . . . . . . . 5 58 2.2.2. Authorization Claims . . . . . . . . . . . . . . . . 6 59 2.2.2.1. Claims for Authorization Outside of Delegation 60 Scenarios . . . . . . . . . . . . . . . . . . . . 6 61 3. Requesting a JWT Access Token . . . . . . . . . . . . . . . . 6 62 4. Validating JWT Access Tokens . . . . . . . . . . . . . . . . 7 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 7.1. Media Type Registration . . . . . . . . . . . . . . . . . 10 67 7.1.1. Registry Content . . . . . . . . . . . . . . . . . . 10 68 7.2. Claims Registration . . . . . . . . . . . . . . . . . . . 11 69 7.2.1. Registry Contents . . . . . . . . . . . . . . . . . . 12 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 72 8.2. Informative References . . . . . . . . . . . . . . . . . 14 73 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 74 Appendix B. Document History . . . . . . . . . . . . . . . . . . 15 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 77 1. Introduction 79 The original OAuth 2.0 Authorization Framework [RFC6749] 80 specification does not mandate any specific format for access tokens. 81 While that remains perfectly appropriate for many important scenario, 82 in-market use has shown that many commercial OAuth2 implementations 83 elected to issue access tokens using a format that can be parsed and 84 validated by resource servers directly, without further authorization 85 server involvement. The approach is particularly common in 86 topologies where the authorization server and resource server are not 87 co-located, are not ran by the same entity, or are otherwise 88 separated by some boundary. All of the known commercial 89 implementations known at this time leverage the JSON Web Tokens(JWT) 90 [RFC7519] format. 92 Most vendor specific JWT access tokens share the same functional 93 layout, including information in forms of claims meant to support the 94 same scenarios: token validation, transporting authorization 95 information in forms of scopes and entitlements, carrying identity 96 information about the subject, and so on. The differences are mostly 97 confined to the claim names and syntax used to represent the same 98 entities, suggesting that interoperability could be easily achieved 99 by standardizing on a common set of claims and validation rules. 101 The assumption that access tokens are associated to specific 102 information doesn't appear only in commercial implementations. 103 Various specifications in the OAuth2 family (such as resource 104 indicators [ResourceIndicators], OAuth 2.0 bearer token usage 105 [RFC6750] and others) postulate the presence in access tokens of 106 scoping mechanisms, such as an audience. The family of 107 specifications associated to introspection also indirectly suggest a 108 fundamental set of information access tokens are expected to carry or 109 at least be associated with. 111 This specification aims to provide a standardized and interoperable 112 profile as an alternative to the proprietary JWT access tokens 113 layouts going forward. Besides defining a common set of mandatory 114 and optional claims, the profile provides clear indications on how 115 authorization requests parameters determine the content of the issued 116 JWT access token, how an authorization server can publish metadata 117 relevant to the JWT access tokens it issues, and how a resource 118 server should validate incoming JWT access tokens. 120 Finally, this specification provides security and privacy 121 considerations meant to prevent common mistakes and anti patterns 122 that are likely to occur in naive use of the JWT format to represent 123 access tokens. 125 1.1. Requirements Notation and Conventions 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 1.2. Terminology 135 JWT access token An OAuth 2.0 access token encoded in JWT format and 136 complying with the requirements described in this specification. 138 This specification uses the terms "access token", "refresh token", 139 "authorization server", "resource server", "authorization endpoint", 140 "authorization request", "authorization response", "token endpoint", 141 "grant type", "access token request", "access token response", and 142 "client" defined by The OAuth 2.0 Authorization Framework [RFC6749]. 144 2. JWT Access Token Header and Data Structure 146 JWT access tokens are regular JWT tokens complying with the 147 requirements described in this section. 149 2.1. Header 151 Although JWT access tokens can use any signing algorithm, use of 152 asymmetric algorithms is RECOMMENDED as it simplifies the process of 153 acquiring validation information for resource servers (see 154 Section 4). 156 NOTE: there were discussions about adding a reference to 157 authenticated encryption methods as well, but there's no internet 158 draft specifying interoperable public key methods at this time 160 The typ header parameter for a JWT access token MUST be at+jwt. See 161 the security considerations section for details on the importance of 162 preventing JWT access tokens to be interpreted as id_tokens. 164 2.2. Data Structure 166 The following claims are used in the JWT access token data structure. 168 iss REQUIRED - as defined in section 4.1.1 of [RFC7519]. 170 exp REQUIRED - as defined in section 4.1.4 of [RFC7519]. 172 aud REQUIRED - as defined in section 4.1.3 of [RFC7519]. See 173 Section 3 for indications on how an authorization server should 174 determine the value of aud depending on the request. The aud 175 claim MAY include a list of individual resource indicators if they 176 are all aliases referring to the same requested resource known by 177 the authorization server. 179 sub REQUIRED - as defined in section 4.1.2 of [RFC7519]. In case of 180 access tokens obtained through grants where no resource owner is 181 involved, such as the client credentials grant, the value of sub 182 SHOULD correspond to an identifier the authorization server uses 183 to indicate the client application. Please see Section 5 for more 184 details on this scenario. 186 client_id REQUIRED - as defined in section 4.3 of [TokenExchange]. 188 iat OPTIONAL - as defined in section 4.1.6 of [RFC7519]. 190 auth_time OPTIONAL - as defined in section 2 of [OpenID.Core]. 191 Important: as this claim represents the time at which the end user 192 last authenticated, its value will either remain the same for all 193 the JWT access tokens issued within that session or be updated to 194 the time of latest authentication if reauthentication occurred 195 mid-session (as it is the case for step up authenticaiton and 196 similar occurrences). For example: all the JWT access tokens 197 obtained with a given refresh token will all have the same value 198 of auth_time, corresponding to the instant in which the user first 199 authenticated to obtain the refresh token. 201 jti OPTIONAL - as defined in section 4.1.7 of [RFC7519]. 203 acr, amr OPTIONAL - as defined in section 2 of [OpenID.Core]. The 204 same considerations presented for auth_time apply to acr and amr: 205 those values reflect the authentication context and method used 206 when the end user originally authenticated, and will remain 207 unchanged for the JWT access tokens issued within the context of 208 that session. 210 2.2.1. Identity Claims 212 Commercial authorization servers will often include resource owner 213 attributes directly in access tokens, so that resource servers can 214 consume them directly for authorization or other purposes without any 215 further roudtrips to introspection ([RFC7662]) or userinfo 216 ([OpenID.Core]) endpoints. This is particularly common in scenarios 217 where the client and the resource server belong to the same entity 218 and are part of the same solution, as it is the case for first party 219 clients invoking their own backend API. 221 This profile does not introduce any mechanism for a client to 222 directly request the presence of specific claims in JWT access 223 tokens, as the authorization server can determine what additional 224 claims are required by a particular resource server by taking in 225 consideration the client_id of the client, the scope and the resource 226 parameters included in the request. 228 Any additional attributes whose semantic is well described by the 229 attributes description found in section 5.1 of [OpenID.Core] SHOULD 230 be codified in JWT access tokens via the corresponding claim names in 231 that section of the OpenID Connect specification. The same holds for 232 attributes defined in [RFC7662] and other identity related 233 specifications. 235 Authorization server MAY return arbitrary attributes not defined in 236 any existing specification, as long as the corresponding claim names 237 are collision resistant or the access tokens are meant to be used 238 only within a private subsystem. 240 Authorization servers including resource owner attributes in JWT 241 access tokens should exercise care and verify that all privacy 242 requirements are met, as discussed in Section 6. 244 2.2.2. Authorization Claims 246 If an authorization request includes a scope parameter, the 247 corresponding issued JWT access token SHOULD include a scope claim as 248 defined in section 4.2 of [TokenExchange]. 250 All the individual scopes strings in the scope claim MUST have 251 meaning for the resource indicated in the aud claim. 253 2.2.2.1. Claims for Authorization Outside of Delegation Scenarios 255 Many authorization servers embed in the access tokens they issue 256 authorization attributes that go beyond the delegated scenarios 257 described by [RFC7519]. Typical examples include resource owner 258 memberships in roles and groups that are relevant to the resource 259 being accessed, entitlements assigned to the resource owner for the 260 targeted resource that the authorization server knows about, and so 261 on. 263 An authorization server wanting to include such attributes in a JWT 264 access token SHOULD use as claim types the attributes described by 265 section 4.1.2 of SCIM Core ([RFC7643]) and in particular roles, 266 groups and entitlements. As in their original definition in 267 [RFC7643] , this profile does not provide a specific vocabulary for 268 those entities. The Section 7 section of this document does provide 269 entries for registering the roles, groups and entitlements attributes 270 from [RFC7643] as claim types to be used in this profile. 272 3. Requesting a JWT Access Token 274 An authorization server can issue a JWT access token in response to 275 any authorization grant defined by [RFC6749] and subsequent 276 extensions meant to result in an access token. 278 Every JWT access token MUST include an aud claim (see Section 2.2). 280 If the request includes a resource parameter (as defined in 281 [ResourceIndicators]), the resulting JWT access token aud claim MUST 282 have the same value as the resource parameter in the request. 284 Example request below: 286 GET /as/authorization.oauth2?response_type=code 287 &client_id=s6BhdRkqt3&state=laeb 288 &scope=openid%20profile%20reademail 289 &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb 290 &resource=https%3A%2F%2Frs.example.com%2F HTTP/1.1 291 Host: authorization-server.example.com 293 Figure 1: Authorization Request with Resource and Scope Parameters 295 Once redeemed, the code obtained from the request above will result 296 in a JWT access token in the form shown below: 298 {"typ":"at+JWT","alg":"RS256","kid":"RjEwOwOA"} 299 { 300 "iss": "https://authorization-server.example.com/", 301 "sub": " 5ba552d67", 302 "aud": "https://rs.example.com/", 303 "exp": 1544645174, 304 "client_id": "s6BhdRkqt3_", 305 "scope": "openid profile reademail" 306 } 308 Figure 2: A JWT Access Token 310 If it receives a request for an access token containing more than one 311 resource parameter, an authorization server issuing JWT access tokens 312 MUST reject the request and fail with "invalid_request" as described 313 in section 4.1.2.1 of [RFC6749] or with "invalid_target" as defined 314 in section 2 of [ResourceIndicators]. See Section 2.2 and Section 5 315 for more details on how this measure ensures there's no confusion on 316 to what resource the access token granted scopes apply. 318 If the request does not include a resource parameter, the 319 authorization server MUST use in the aud claim a default resource 320 indicator. If a scope parameter is present in the request, the 321 authorization server SHOULD use it to infer the value of the default 322 resource indicator to be used in the aud claim. The mechanism 323 through which scopes are associated to default resource indicator 324 values is outside the scope of this specification. If the values in 325 the scope parameter refer to different default resource indicator 326 values, the authorization server SHOULD reject the request with 327 invalid_scope as described in section 4.1.2.1 of [RFC6749]. 329 4. Validating JWT Access Tokens 331 For the purpose of facilitating validation data retrieval, it is 332 RECOMMENDED that authorization servers sign JWT access tokens with an 333 asymmetric algorithm. 335 Authorization servers SHOULD implement OAuth 2.0 Authorization Server 336 Metadata [RFC8414] to advertise to resource servers its signing keys 337 via jwks_uri and what iss claim value to expect via the issuer 338 metadata value. Alternatively, authorization servers implementing 339 OpenID Connect MAY use the OpenID Connect discovery document for the 340 same purpose. If an authorization server supports both AS metadata 341 and Openid discovery, the values provided MUST be consistent across 342 the two publication methods. 344 An authorization server MAY elect to use different keys to sign 345 id_tokens and JWT access tokens. 347 When invoked as described in OAuth 2.0 Bearer Token Usage [RFC6750], 348 resource servers receiving a JWT access token MUST validate it in the 349 following manner. 351 1. The resource server MUST verify that the typ header value is 352 at+jwt and reject tokens carrying any other value. 354 2. If the JWT access token is encrypted, decrypt it using the keys 355 and algorithms that the resource server specified during 356 registration. If encryption was negotiated with the 357 authorization server at registration time and the incoming JWT 358 access token is not encrypted, the resource server SHOULD reject 359 it. 361 3. The Issuer Identifier for the authorization server (which is 362 typically obtained during discovery) MUST exactly match the value 363 of the iss claim. 365 4. The resource server MUST validate that the aud claim contains the 366 resource indicator value corresponding to the identifier the 367 resource server expects for itself. The aud claim MAY contain an 368 array with more than one element. The JWT access token MUST be 369 rejected if aud does not list the resource indicator of the 370 current resource server as a valid audience, or if it contains 371 additional audiences that are not known aliases of the resource 372 indicator of the current resource server. 374 5. The resource server MUST validate the signature of all incoming 375 JWT access tokens according to [RFC7515] using the algorithm 376 specified in the JWT alg Header Parameter. The resource server 377 MUST reject any JWT in which the value of "alg" is "none". The 378 resource server MUST use the keys provided by the authorization 379 server. 381 6. The current time MUST be before the time represented by the exp 382 claim. 384 7. If the auth_time claim is present, the resource server SHOULD 385 check the auth_time value and request re-authentication if it 386 determines too much time has elapsed since the last resource 387 owner authentication. 389 If the JWT access token includes authorization claims as described in 390 the authorization claims section, the resource server SHOULD use them 391 in combination with any other contextual information available to 392 determine whether the current call should be authorized or rejected. 393 Details about how a resource server performs those checks is beyond 394 the scope of this profile specification. 396 5. Security Considerations 398 The JWT access token data layout described here is very similar to 399 the one of the id_token as defined by [OpenID.Core]. The explicit 400 typing required in this profile, in line with the recommendations in 401 [JWT.BestPractices] helps the resource server to distinguish between 402 JWT access tokens and id_tokens. 404 Authorization servers should prevent scenarios where clients can 405 affect the value of the sub claim in ways that could confuse resource 406 servers. For example: if the authorization server elects to use the 407 client_id as the sub value for access tokens issued client 408 credentials grant, the authorization server should prevent clients to 409 register an arbitrary client_id value, as this would allow malicious 410 clients to select the sub of a high privilege resource owner and 411 confuse any authorization logic on the resource server relying on the 412 sub value. For more details please refer to section 4.13 of 413 [OAuth2.Security.BestPractices]. 415 To preventing cross-JWT confusion, authorization servers MUST use a 416 distinct identifier as "aud" claim value to uniquely identify access 417 tokens issued by the same issuer for distinct resources. 419 This profile explicitly forbids the use of multi value aud claim when 420 the individual values refer to different resources, as that would 421 introduce confusion about what scopes apply to which resource- 422 possibly opening up avenues for elevation of delegated privileges 423 attacks. Alternative techniques to prevent scope confusion include 424 "scope stuffing", imposing to every individual scope string to 425 include a reference to the resource they are meant to be applied to, 426 but its application is problematic (scope opacity violations, size 427 inflation, more error conditions become possible when the combination 428 of requested scopes and resource indicators is invalid) and the 429 observed frequency of the scenario doesn't warrant complicating the 430 more common cases. 432 6. Privacy Considerations 434 As JWT access tokens carry information by value, it now becomes 435 possible for requestors and receivers to directly peek inside the 436 token claims collection. The client MUST NOT inspect the content of 437 the access token: the authorization server and the resource server 438 might decide to change token format at any time (for example by 439 switching from this profile to opaque tokens) hence any logic in the 440 client relying on the ability to read the access token content would 441 break without recourse. Nonetheless, authorization servers should 442 not assume that clients will comply with the above. Whenever client 443 access to the access token content presents privacy issues for a 444 given scenario, the authorization server should take explicit steps 445 to prevent it as described below. 447 In scenarios in which JWT access tokens are accessible to the end 448 user, it should be evaluated whether the information can be accessed 449 without privacy violations (for example, if an end user would simply 450 access his or her own personal information) or if steps must be taken 451 to enforce cofidentiality. Possible measures include: encrypting the 452 access token, encrypting the sensitive claims, omitting the sensitive 453 claims or not using this profile, falling back on opaque access 454 tokens. 456 In every scenario, the content of the JWT access token will 457 eventually be accessible to the resource server. It's important to 458 evaluate whether the resource server gained the proper entitlement to 459 have access to any content received in form of claims, for example 460 through user consent in some form, policies and agreements with the 461 organization running the authorization servers, and so on. 463 7. IANA Considerations 465 7.1. Media Type Registration 467 7.1.1. Registry Content 469 This section registers the "application/at+jwt" media type [RFC2046] 470 in the "Media Types" registry [IANA.MediaTypes] in the manner 471 described in [RFC6838], which can be used to indicate that the 472 content is an access token encoded in JWT format. 474 o Type name: application 476 o Subtype name: at+jwt 478 o Required parameters: N/A 479 o Optional parameters: N/A 481 o Encoding considerations: binary; JWT values are encoded as a 482 series of base64url-encoded values (with trailing '=' characters 483 removed), some of which may be the empty string, separated by 484 period ('.') characters. 486 o Security considerations: See the Security Considerations 487 Section of [[TODO: update once there's a RFC number for the JWT AT 488 profile]] 490 o Interoperability considerations: N/A 492 o Published specification: [[TODO: update once there's a RFC number 493 for the JWT AT profile]] 495 o Applications that use this media type: Applications that access 496 resource servers using OAuth2 access tokens encoded in JTW format 498 o Fragment identifier considerations: N/ 500 o Additional information: Magic number(s): N/A File extension(s): N/ 501 A Macintosh file type code(s): N/A 503 o Person and email address to contact for further information: 504 Vittorio Bertocci, vittorio@auth0.com 506 o Intended usage: COMMON 508 o Restrictions on usage: none 510 o Author: Vittorio Bertocci, vittorio@auth0.com 512 o Change controller: IESG 514 o Provisional registration? No 516 7.2. Claims Registration 518 Section Section 2.2.2.1 of this specification refers to the 519 attributes "roles","groups", "entitlements" defined in [RFC7643] to 520 express authorization information in JWT access tokens. This section 521 registers those attributes as claims in the JSON Web Token (JWT) IANA 522 registry introduced in [RFC7519]. 524 7.2.1. Registry Contents 526 o Claim Name: "roles" 528 o Claim Description: Roles 530 o Change Controller: IESG 532 o Specification Document(s): section 4.1.2 of [RFC7643] and section 533 2.2.2.1 of [[this specification]] 535 o Claim Name: "groups" 537 o Claim Description: Groups 539 o Change Controller: IESG 541 o Specification Document(s): section 4.1.2 of [RFC7643] and section 542 2.2.2.1 of [[this specification]] 544 o Claim Name: "entitlements" 546 o Claim Description: Entitlements 548 o Change Controller: IESG 550 o Specification Document(s): section 4.1.2 of [RFC7643] and section 551 2.2.2.1 of [[this specification]] 553 8. References 555 8.1. Normative References 557 [IANA.OAuth.Parameters] 558 IANA, "OAuth Parameters", 559 . 561 [JWT.BestPractices] 562 Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best 563 Current Practices", November 2018. 565 [OAuth2.Security.BestPractices] 566 Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, 567 "OAuth 2.0 Security Best Current Practice", July 2019. 569 [OpenID.Core] 570 Sakimura, N., Bradley, J., Jones, M., Medeiros, B., and C. 571 Mortimore, "OpenID Connect Core 1.0", November 2014. 573 [ResourceIndicators] 574 Campbell, B., Bradley, J., and H. Tschofenig, "OAuth 2.0 575 Token Exchange", November 2016. 577 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 578 Extensions (MIME) Part Two: Media Types", RFC 2046, 579 DOI 10.17487/RFC2046, November 1996, 580 . 582 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 583 Requirement Levels", BCP 14, RFC 2119, 584 DOI 10.17487/RFC2119, March 1997, 585 . 587 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 588 Resource Identifier (URI): Generic Syntax", STD 66, 589 RFC 3986, DOI 10.17487/RFC3986, January 2005, 590 . 592 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 593 RFC 6749, DOI 10.17487/RFC6749, October 2012, 594 . 596 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 597 Specifications and Registration Procedures", BCP 13, 598 RFC 6838, DOI 10.17487/RFC6838, January 2013, 599 . 601 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 602 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 603 2015, . 605 [RFC7643] Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C. 606 Mortimore, "System for Cross-domain Identity Management: 607 Core Schema", RFC 7643, DOI 10.17487/RFC7643, September 608 2015, . 610 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 611 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 612 May 2017, . 614 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 615 Authorization Server Metadata", RFC 8414, 616 DOI 10.17487/RFC8414, June 2018, 617 . 619 [TokenExchange] 620 Nadalin, A., Bradley, J., Jones, M., Campbell, B., and C. 621 Mortimore, "OAuth 2.0 Token Exchange", October 2018. 623 8.2. Informative References 625 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 626 Framework: Bearer Token Usage", RFC 6750, 627 DOI 10.17487/RFC6750, October 2012, 628 . 630 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 631 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 632 . 634 [RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E., 635 and C. Mortimore, "System for Cross-domain Identity 636 Management: Protocol", RFC 7644, DOI 10.17487/RFC7644, 637 September 2015, . 639 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", 640 RFC 7662, DOI 10.17487/RFC7662, October 2015, 641 . 643 Appendix A. Acknowledgements 645 The initial set of requirements informing this specification was 646 extracted by numerous examples of access tokens issued in JWT format 647 by production systems. Thanks to Dominick Bauer (IdentityServer), 648 Brian Campbell (Ping Identity), Daniel Dobalian (Microsoft), Karl 649 Guinness (Okta) for providing sample tokens issued by their products 650 and services. Brian Campbell and Filip Skokan provided early 651 feedback that shaped the direction of the specification. This 652 profile was discussed at lenght during the OAuth Security Workshop 653 2019, with several individuals contributing ideas and feedback. The 654 author would like to acknowledge the contributions of: 656 John Bradley, Brian Campbell, Vladimir Dzhuvinov, Torsten 657 Lodderstedt, Nat Sakimura, Hannes Tschofenig and everyone who 658 actively participated in the unconference discussions. 660 The following individuals contributed useful feedback and insights on 661 the initial draft, both on the IETF OAuth2 WG DL and during the IIW28 662 conference: 664 Dale Olds, George Fletcher, David Waite, Michael Engan, Mike Jones, 665 Hans Zandbelt, Vladimir Dzhuvinov, Martin Schanzenbach , Aaron 666 Parecki and everyone who actively participated in the IIW28 667 unconference discussions and the IETF OAuth2 WG DL discussions. 669 Appendix B. Document History 671 [[ to be removed by the RFC Editor before publication as an RFC ]] 673 draft-ietf-oauth-access-token-jwt-03 675 o Varios typos fixed. 676 o In the security considerations section, relaxed the claim that the 677 typ header value "at+jwt" will prevent RS from misinterpreting JWT 678 ATs as idtokens. 679 o In the "Requesting JWT Access Tokens" section, added 680 "invalid_target" as a possible error returned for the multiple 681 resources request case. 682 o In the Validating JWT Access Tokens" section, disallowed JWTs with 683 "alg":"none" 684 o in the IANA registration entries for the SCIM claim types, 685 complemented the reference to the SCIM spec with a reference to 686 this spec so that the eventual registration entries have better 687 context. 688 o Updated acknowledgements. 689 o In the section Section 3, the example request now has 690 response_type=code. 691 o Updated text in the Privacy Consideration section to clarify what 692 protection steps the text refers to. 694 draft-ietf-oauth-access-token-jwt-02 696 o In 2.2.1, opened the sources of identity attributes to any 697 identity related specification. 698 o In 2.2.2, relaxed from MUST to SHOULD the requirement that 699 requests including a scope always result in access tkens 700 containing a corresponding scope claim. 701 o In the security considerations setting, added a requirement for 702 the authorization server to assing unique identifiers for 703 different resources- to prevent cross JWT confusion. 704 o Added IANA registration for the authorization attributes borrowed 705 from SCIM CORE 707 draft-ietf-oauth-access-token-jwt-01 709 o Added note on authenticated encryption. 710 o Added a mention to the 1st party clients scenarios in the identity 711 claims section. 712 o Changed the definition reference for the iss, exp, aud, sub, iat 713 claims from OpenID.Core to RFC7519. 715 o Added a mention of the client_id==sub case in the security 716 considerations section, added a reference to draft-ietf-oauth- 717 security-topics-13. Added a reference to the security 718 considerations from the sub claim definition section. 719 o Specified invalid_request as the error code the authorization 720 server should return in case of multiple resources in the access 721 token request. 722 o Specified invalid_scope as the error code the authorization server 723 should return in case it isn;t possible to determine to which 724 resource the requested scopes refers to. 725 o In the identity claims section, added a reference to introspection 726 as possible source of claim types and added language explicitly 727 stating that the AS can add arbitrary attributes as long as they 728 are collision resistant or private. 729 o Updated language for the auth_time claim to include the case in 730 which the AS reauthenticates the user mid-session (e.g. during 731 step up auth). 732 o Removed note about adding a mechanism for extablishing whether the 733 token was obtained on behalf or the resource owner or of the 734 client itself (client credentials grant). 735 o Removed note about adding a mechanism for indicating whether the 736 authorization server sent the resource owner to authenticate with 737 a federated identity provider, and the identity of that federated 738 provider. 739 o Removed the note in the security consideration sections about 740 discussing the purpose of aud, iss, exp validation (redundant). 741 o In the authorization claims section, stated intent to register 742 roles, groups and entitlements as claim types in IANA 743 o Clarified in the privacy considerations that clients should not 744 inspect access tokens. 745 o Expanded the privacy considerations with more explicit guidance 746 about privacy preserving approaches. 747 o Added IANA registry content for the at+JWT MIME type. 748 o Updated acknowledgements. 750 draft-ietf-oauth-access-token-jwt-00 752 o Initial draft to define a JWTt profile for OAuth 2.0 access 753 tokens. 755 Author's Address 757 Vittorio Bertocci 758 Auth0 760 Email: vittorio@auth0.com