rfc9068xml2.original.xml   rfc9068.xml 
<?xml version="1.0" encoding="us-ascii"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml2rfc.tools.ietf.org/authoring/r <!DOCTYPE rfc [
fc2629.xslt' ?> <!ENTITY nbsp "&#160;">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!ENTITY zwsp "&#8203;">
<?rfc toc="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc tocompact="yes"?> <!ENTITY wj "&#8288;">
<?rfc tocdepth="4"?> ]>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-oauth-acces
<?rfc sortrefs="yes"?> s-token-jwt-13" number="9068" ipr="trust200902" obsoletes="" updates="" submissi
<?rfc comments="yes"?> onType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" to
<?rfc inline="yes"?> cDepth="4" symRefs="true" sortRefs="true" version="3">
<?rfc compact="yes"?>
<?rfc subcompact="no"?> <front>
<rfc category="std" docName="draft-ietf-oauth-access-token-jwt-13" ipr="trust200 <title abbrev="OAuth 2.0 Access Token JWT Profile">JSON Web Token (JWT) Prof
902"> ile for OAuth 2.0 Access Tokens</title>
<front> <seriesInfo name="RFC" value="9068"/>
<title abbrev="OAuth 2.0 Access Token JWT Profile">JSON Web Token (JWT) <author fullname="Vittorio Bertocci" initials="V." surname="Bertocci">
Profile for OAuth 2.0 Access Tokens</title> <organization>Auth0</organization>
<author fullname="Vittorio Bertocci" initials="V." surname="Bertocci"> <address>
<organization>Auth0</organization> <email>vittorio@auth0.com</email>
<address> </address>
<email>vittorio@auth0.com</email> </author>
</address> <date year="2021" month="October" />
</author> <area>Security</area>
<date /> <workgroup>OAuth</workgroup>
<area>Security</area> <keyword>OAuth</keyword>
<workgroup>OAuth Working Group</workgroup> <keyword>Resource</keyword>
<keyword>OAuth</keyword> <keyword>Access token</keyword>
<keyword>Resource</keyword> <keyword>JWT</keyword>
<keyword>Access token</keyword> <abstract>
<keyword>JWT</keyword> <t>
<abstract> This specification defines a profile for issuing OAuth 2.0 access tokens
<t> in JSON Web Token (JWT) format. Authorization
This specification defines a profile for issuing OAuth 2.0 access tokens servers
in JSON web token (JWT) format. Authorization servers
and resource servers from different vendors can leverage this pro file to issue and consume access tokens in an interoperable manner. and resource servers from different vendors can leverage this pro file to issue and consume access tokens in an interoperable manner.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="Introduction" title="Introduction"> <section anchor="Introduction" numbered="true" toc="default">
<t> <name>Introduction</name>
<t>
The original The original
<xref target="RFC6749">OAuth 2.0 Authorization Framework</xref> specification does not mandate any specific format for access tokens. <xref target="RFC6749" format="default">OAuth 2.0 Authorization Framework</xref> specification does not mandate any specific format for access t okens.
While that remains perfectly appropriate for many important scenarios, in-mark et use has shown that many commercial OAuth 2.0 While that remains perfectly appropriate for many important scenarios, in-mark et use has shown that many commercial OAuth 2.0
implementations elected to issue access tokens using a format that can be pars ed and validated by resource servers directly, without further authorization ser ver involvement. implementations elected to issue access tokens using a format that can be pars ed and validated by resource servers directly, without further authorization ser ver involvement.
The approach is particularly common in topologies where the authorization serv er and resource server are not co-located, The approach is particularly common in topologies where the authorization serv er and resource server are not co-located,
are not run by the same entity, or are otherwise separated by some boundary. A t the time of writing, many commercial implementations leverage the are not run by the same entity, or are otherwise separated by some boundary. A t the time of writing, many commercial implementations leverage the
<xref target="RFC7519">JSON Web Tokens (JWT)</xref> format. <xref target="RFC7519" format="default">JSON Web Token (JWT)</xr ef> format.
</t> </t>
<t> <t>
Many vendor specific JWT access tokens share the same functional layout, using Many vendor-specific JWT access tokens share the same functional layout, using
JWT claims to convey the information needed to support a common set of use case JWT claims to convey the information needed to support a common set of use case
s: token validation, transporting authorization information in forms of scopes a s: token validation, transporting authorization information in the form of scope
nd entitlements, s and entitlements,
carrying identity information about the subject, and so on. The differences ar e mostly confined to the claim names and syntax carrying identity information about the subject, and so on. The differences ar e mostly confined to the claim names and syntax
used to represent the same entities, suggesting that interoperability could be used to represent the same entities, suggesting that interoperability could be
easily achieved by standardizing on a common set of claims and validation rules easily achieved by standardizing a common set of claims and validation rules.
. </t>
</t> <t>
<t> The assumption that access tokens are associated with specific information doe
The assumption that access tokens are associated to specific information doesn sn't appear only in commercial implementations.
't appear only in commercial implementations.
Various specifications in the OAuth 2.0 family (such as Various specifications in the OAuth 2.0 family (such as
<xref target="RFC8707">resource indicators</xref>, <xref target="RFC8707" format="default">resource indicators</xre
<xref target="RFC6750">OAuth 2.0 bearer token usage</xref> and o f>,
thers) postulate the presence in access tokens of scoping mechanisms, such as an <xref target="RFC6750" format="default">OAuth 2.0 bearer token u
audience. The family of specifications associated to introspection also indirec sage</xref>, and others) postulate the presence of scoping mechanisms, such as a
tly n audience, in access tokens.
suggest a fundamental set of information access tokens are expected to carry o The family of specifications associated with introspection also indirectly
r at least be associated with. suggests a fundamental set of information that access tokens are expected to c
arry or at least be associated with.
</t> </t>
<t> <t>
This specification aims to provide a standardized and interoperable profile as an alternative to the proprietary JWT access token layouts going forward. This specification aims to provide a standardized and interoperable profile as an alternative to the proprietary JWT access token layouts going forward.
Besides defining a common set of mandatory and optional claims, the profile pro vides clear indications on how authorization request Besides defining a common set of mandatory and optional claims, the profile pro vides clear indications on how authorization request
parameters determine the content of the issued JWT access token, how an authori zation server can publish metadata relevant to the parameters determine the content of the issued JWT access token, how an authori zation server can publish metadata relevant to the
JWT access tokens it issues, and how a resource server should validate incoming JWT access tokens. JWT access tokens it issues, and how a resource server should validate incoming JWT access tokens.
</t> </t>
<t> <t>
Finally, this specification provides security and privacy considerations meant Finally, this specification provides security and privacy considerations meant
to prevent common mistakes and anti patterns to prevent common mistakes and anti-patterns
that are likely to occur in naive use of the JWT format to represent access toke ns. that are likely to occur in naive use of the JWT format to represent access toke ns.
</t> </t>
<t> <t indent="3">
Please note: although both this document and <xref target="RFC7523"/ Please note: Although both this document and <xref target="RFC7523" form
> use JSON Web Tokens in the context of the OAuth2 framework, the two specificat at="default"/> use JSON Web Tokens in the context of the OAuth2 framework, the t
ions differ in both intent and mechanics. Whereas <xref target=" RFC7523"/> defi wo specifications differ in both intent and mechanics. Whereas <xref target="RFC
nes how a JWT Bearer Token can be used to request an access token, this document 7523" format="default"/> defines how a JWT Bearer Token can be used to request a
s describes how to encode access tokens in JWT format. n access token, this document describes how to encode access tokens in JWT forma
</t> t.
<section anchor="RNC" title="Requirements Notation and Conventions"> </t>
<t> <section anchor="RNC" numbered="true" toc="default">
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <name>Requirements Notation and Conventions</name>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL <t>
" The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
in this document are to be interpreted as described in IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
BCP 14 NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<xref target="RFC2119"/> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
<xref target="RFC8174"/> be interpreted as
when, and only when, they appear in all capitals, as shown here. described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t> </t>
</section> </section>
<section anchor="Terminology" title="Terminology"> <section anchor="Terminology" numbered="true" toc="default">
<t> <name>Terminology</name>
<list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="JWT access token:"> <dt>JWT access token:</dt>
<dd>
An OAuth 2.0 access token encoded in JWT format and complying with the r equirements described in this specification. An OAuth 2.0 access token encoded in JWT format and complying with the r equirements described in this specification.
</t> </dd>
</list> </dl>
</t> <t>
<t>
This specification uses the terms This specification uses the terms
"access token", "access token",
"refresh token", "refresh token",
"authorization server", "authorization server",
"resource server", "resource server",
"authorization endpoint", "authorization endpoint",
"authorization request", "authorization request",
"authorization response", "authorization response",
"token endpoint", "token endpoint",
"grant type", "grant type",
"access token request", "access token request",
"access token response", "access token response",
and "client" and "client"
defined by defined by
<xref target="RFC6749">The OAuth 2.0 Authorization Framework <xref target="RFC6749" format="default">The OAuth 2.0 Author
</xref>. ization Framework</xref>.
</t> </t>
</section> </section>
</section> </section>
<section anchor="JWTATLayout" title="JWT Access Token Header and Data St <section anchor="JWTATLayout" numbered="true" toc="default">
ructure"> <name>JWT Access Token Header and Data Structure</name>
<section anchor="JWTATHeader" title="Header"> <section anchor="JWTATHeader" numbered="true" toc="default">
<t> <name>Header</name>
JWT access tokens MUST be signed. Although JWT ac <t>
cess tokens can use any signing algorithm, use of asymmetric cryptography is REC JWT access tokens <bcp14>MUST</bcp14> be signed.
OMMENDED as it simplifies the process of acquiring validation information for re Although JWT access tokens can use any signing algorithm, use of asymmetric cryp
source servers (see tography is <bcp14>RECOMMENDED</bcp14> as it simplifies the process of acquiring
<xref target="JWTATLValidate"/>). JWT access tokens MUST NOT validation information for resource servers (see
use "none" as the signing algorithm. See <xref target="JWTATLValidate" format="default"/>). JWT acces
<xref target="JWTATLValidate"/> for more details. s tokens <bcp14>MUST NOT</bcp14> use "none" as the signing algorithm. See
<xref target="JWTATLValidate" format="default"/> for more de
tails.
</t> </t>
<t> <t>
Authorization servers and resource servers conforming to this sp Authorization servers and resource servers conforming to this sp
ecification MUST include RS256 (as defined in <xref target="RFC7518"/>) among th ecification <bcp14>MUST</bcp14> include RS256 (as defined in <xref target="RFC75
eir supported signature algorithms. 18" format="default"/>) among their supported signature algorithms.
</t> </t>
<t> <t>
This specification registers the "application/at+jwt" media type, which can be u sed to indicate that the content is a JWT access token. This specification registers the "application/at+jwt" media type, which can be u sed to indicate that the content is a JWT access token.
JWT access tokens MUST include this media type in the "typ" header parameter JWT access tokens <bcp14>MUST</bcp14> include this media type in the "typ" he
to explicitly declare that the JWT represents an access token complying with thi ader parameter to explicitly declare that the JWT represents an access token com
s profile. plying with this profile.
Per the definition of "typ" in Section 4.1.9 of Per the definition of "typ" in <xref target="RFC7515" sectionFormat="of" sect
<xref target="RFC7515"/>, it is RECOMMENDED that the "applic ion="4.1.9"/>, it is <bcp14>RECOMMENDED</bcp14> that the "application/" prefix b
ation/" prefix be omitted. Therefore, the "typ" value used SHOULD be "at+jwt". e omitted. Therefore, the "typ" value used <bcp14>SHOULD</bcp14> be "at+jwt".
See the security considerations section for details on the importance of preven See the <xref target="SecurityConsiderations" format="title"/> section for deta
ting OpenID Connect ID Tokens (as defined by Section 2 of <xref target="OpenID.C ils on the importance of preventing OpenID Connect ID Tokens (as defined by Sect
ore"/>) from being accepted as access tokens by resource servers implementing th ion 2 of <xref target="OpenID.Core" format="default"/>) from being accepted as a
is profile. ccess tokens by resource servers implementing this profile.
</t> </t>
</section> </section>
<section anchor="JWTATDataStructure" title="Data Structure"> <section anchor="JWTATDataStructure" numbered="true" toc="default">
<t> <name>Data Structure</name>
<t>
The following claims are used in the JWT access t oken data structure. The following claims are used in the JWT access t oken data structure.
</t> </t>
<t> <dl newline="false" spacing="normal">
<list style="hanging"> <dt>iss</dt>
<t hangText="iss"> <dd>
REQUIRED - as defined in Section 4.1.1 of <bcp14>REQUIRED</bcp14> - as defined in <xref target="RFC7519" sectionFo
<xref target="RFC7519"/>. rmat="of" section="4.1.1"/>.
</t> </dd>
<t hangText="exp"> <dt>exp</dt>
REQUIRED - as defined in Section 4.1.4 of <dd>
<xref target="RFC7519"/>. <bcp14>REQUIRED</bcp14> - as defined in <xref target="RFC7519" sectionFo
rmat="of" section="4.1.4"/>.
</t> </dd>
<t hangText="aud"> <dt>aud</dt>
REQUIRED - as defined in Section 4.1.3 of <dd>
<xref target="RFC7519"/>. See <bcp14>REQUIRED</bcp14> - as defined in <xref target="RFC7519" sectionF
<xref target="JWTATLRequest"/> for indications on ho ormat="of" section="4.1.3"/>. See
w an authorization server should determine the value of "aud" depending on the r <xref target="JWTATLRequest" format="default"/> for
equest. indications on how an authorization server should determine the value of "aud" d
epending on the request.
</t> </dd>
<t hangText="sub"> <dt>sub</dt>
REQUIRED - as defined in Section 4.1.2 of <dd>
<xref target="RFC7519"/>. In case of access tokens o <bcp14>REQUIRED</bcp14> - as defined in <xref target="RFC7519" sectionF
btained through grants where a resource owner is involved, such as the authoriza ormat="of" section="4.1.2"/>. In cases of access tokens obtained through grants
tion code grant, the value of "sub" SHOULD correspond to the subject identifier where a resource owner is involved, such as the authorization code grant, the va
of the resource owner. In case of access tokens obtained through grants where no lue of "sub" <bcp14>SHOULD</bcp14> correspond to the subject identifier of the r
resource owner is involved, such as the client credentials grant, the value of esource owner. In cases of access tokens obtained through grants where no resour
"sub" SHOULD correspond to an identifier the authorization server uses to indica ce owner is involved, such as the client credentials grant, the value of "sub" <
te the client application. bcp14>SHOULD</bcp14> correspond to an identifier the authorization server uses t
o indicate the client application.
See See
<xref target="SecurityConsiderations"/> for more det <xref target="SecurityConsiderations" format="defaul
ails on this scenario. Also, see t"/> for more details on this scenario. Also, see
<xref target="PrivacyConsiderations"/> for a discuss <xref target="PrivacyConsiderations" format="default
ion about how different choices in assigning "sub" values can impact privacy. "/> for a discussion about how different choices in assigning "sub" values can i
mpact privacy.
</t> </dd>
<t hangText="client_id"> <dt>client_id</dt>
REQUIRED - as defined in Section 4.3 of <dd>
<xref target="RFC8693"/>. <bcp14>REQUIRED</bcp14> - as defined in <xref target="RFC8693" sectionF
ormat="of" section="4.3"/>.
</t> </dd>
<t hangText="iat"> <dt>iat</dt>
REQUIRED - as defined in Section 4.1.6 of <dd>
<xref target="RFC7519"/>. <bcp14>REQUIRED</bcp14> - as defined in <xref target="RFC7519" sectionFo
rmat="of" section="4.1.6"/>.
This claim identifies the time at which the JWT access token was issued. This claim identifies the time at which the JWT access token was issued.
</t> </dd>
<t hangText="jti"> <dt>jti</dt>
REQUIRED - as defined in Section 4.1.7 of <dd>
<xref target="RFC7519"/>. <bcp14>REQUIRED</bcp14> - as defined in <xref target="RFC7519" sectionF
ormat="of" section="4.1.7"/>.
</t>
</list>
</t>
<section anchor="AuthenticationInfoClaims" title="Authentication
Information Claims">
<t>
The claims listed in this section
MAY be issued in the context of authorization grants involving the resource own
er, and reflect in the access token the types and strength of authentication tha
t the authentication server enforced prior to returning the authorization respon
se to the client. Their values are fixed, and remain the same across all access
tokens that derive from a given authorization response, whether the access token
was obtained directly
in the response (e.g., via the implicit flow) or after o
ne or more token exchanges (e.g., obtaining a fresh access token using a refresh
token, or exchanging one access token for another via
<xref target="RFC8693"/> procedures).
<list style="hanging">
<t hangText="auth_time">
OPTIONAL
- as defined in Section 2 of
<xref target="OpenID.Core"/>.
</t>
<t hangText="acr">
OPTIONAL
- as defined in Section 2 of
<xref target="OpenID.Core"/>.
</t> </dd>
<t hangText="amr"> </dl>
OPTIONAL <section anchor="AuthenticationInfoClaims" numbered="true" toc="default"
- as defined in Section 2 of >
<xref target="OpenID.Core"/>. <name>Authentication Information Claims</name>
<t>The claims listed in this section <bcp14>MAY</bcp14> be issued in t
he context of authorization grants involving the resource owner and reflect the
types and strength of authentication in the access token that the authentication
server enforced prior to returning the authorization response to the client. Th
eir values are fixed and remain the same across all access tokens that derive fr
om a given authorization response, whether the access token was obtained directl
y
in the response (e.g., via the implicit flow) or after o
ne or more token exchanges (e.g., obtaining a fresh access token using a refresh
token or exchanging one access token for another via
<xref target="RFC8693" format="default"/> procedures).
</t> </t>
</list> <dl newline="false" spacing="normal">
</t> <dt>auth_time</dt>
</section> <dd>
<section anchor="IdentityClaims" title="Identity Claims"> <bcp14>OP
<t> TIONAL</bcp14> - as defined in Section 2 of
In the context of authorization grants in <xref target="OpenID.Core" format="default"/>.
volving the resource owner, commercial authorization servers will often include
resource owner attributes directly in access tokens, so that resource servers ca
n consume them directly for authorization or other purposes without any further
round trips to introspection (
<xref target="RFC7662"/>) or UserInfo ( </dd>
<dt>acr</dt>
<dd>
<bcp14>OP
TIONAL</bcp14> - as defined in Section 2 of
<xref target="OpenID.Core" format="default"/>.
<xref target="OpenID.Core"/>) endpoints. </dd>
This is particularly common in scenarios <dt>amr</dt>
where the client and the resource server belong to the same entity and are part <dd>
of the same solution, as is the case for first party clients invoking their own <bcp14>OP
backend API. TIONAL</bcp14> - as defined in Section 2 of
<xref target="OpenID.Core" format="default"/>.
</t> </dd>
<t>This profile does not introduce any mechanism for a clien </dl>
t to directly request the presence of specific claims in JWT access tokens, as t </section>
he authorization server can determine what additional claims are required by a p <section anchor="IdentityClaims" numbered="true" toc="default">
articular resource server by taking in consideration the client_id of the client <name>Identity Claims</name>
, the "scope" and the "resource" parameters included in the request.</t> <t>
<t> In the context of authorization grants in
Any additional identity attribute whose semantic is well des volving the resource owner, commercial authorization servers will often include
cribed by an entry in the JSON Web Token (JWT) IANA registry introduced in <xref resource owner attributes directly in access tokens so that resource servers can
target="RFC7519"/> SHOULD be encoded using the corresponding claim name, if tha consume them directly for authorization or other purposes without any further r
t attribute is to be included in the JWT access token. Note that the JWT IANA re ound trips to introspection (<xref target="RFC7662" format="default"/>) or UserI
gistry includes the claims found in Section 5.1 of <xref target="OpenID.Core"/>. nfo (<xref target="OpenID.Core" format="default"/>) endpoints.
</t> This is particularly common in scenarios
where the client and the resource server belong to the same entity and are part
of the same solution, as is the case for first-party clients invoking their own
backend API.
<t>Authorization servers MAY return arbitrary attributes not </t>
defined in any existing specification, as long as the corresponding claim names <t>This profile does not introduce any mechanism for a client to direc
are collision resistant or the access tokens are meant to be used only within a tly request the presence of specific claims in JWT access tokens, as the authori
private subsystem. Please refer to Sections 4.2 and 4.3 of zation server can determine what additional claims are required by a particular
<xref target="RFC7519"/> for details. resource server by taking the client_id of the client and the "scope" and the "r
</t> esource" parameters included in the request into consideration.</t>
<t>Authorization servers including resource owner attributes <t>
in JWT access tokens need to exercise care and verify that all privacy requirem Any additional identity attribute whose semantic is well des
ents are met, as discussed in cribed by an entry in the "JSON Web Token (JWT)" IANA registry introduced in <xr
ef target="RFC7519" format="default"/> <bcp14>SHOULD</bcp14> be encoded using th
e corresponding claim name, if that attribute is to be included in the JWT acces
s token. Note that the JWT IANA registry includes the claims found in Section 5.
1 of <xref target="OpenID.Core" format="default"/>.
</t>
<t>Authorization servers <bcp14>MAY</bcp14> return arbitrary attribute
s not defined in any existing specification, as long as the corresponding claim
names are collision resistant or the access tokens are meant to be used only wit
hin a private subsystem. Please refer to Sections <xref target="RFC7519" section
Format="bare" section="4.2"/> and <xref target="RFC7519" sectionFormat="bare" se
ction="4.3"/> of <xref target="RFC7519"/> for details.
</t>
<t>Authorization servers including resource owner attributes in JWT ac
cess tokens need to exercise care and verify that all privacy requirements are m
et, as discussed in
<xref target="PrivacyConsiderations"/>. <xref target="PrivacyConsiderations" format="default"/>.
</t> </t>
</section> </section>
<section anchor="AuthorizationClaims" title="Authorization Claim <section anchor="AuthorizationClaims" numbered="true" toc="default">
s"> <name>Authorization Claims</name>
<t> <t>
If an authorization request includes a sc If an authorization request includes a sc
ope parameter, the corresponding issued JWT access token SHOULD include a "scope ope parameter, the corresponding issued JWT access token <bcp14>SHOULD</bcp14> i
" claim as defined in Section 4.2 of nclude a "scope" claim as defined in <xref target="RFC8693" sectionFormat="of"
<xref target="RFC8693"/>. section="4.2"/>.
</t> </t>
<t> <t>
All the individual scope strings in the " All the individual scope strings in the "
scope" claim MUST have meaning for the resources indicated in the "aud" claim. S scope" claim <bcp14>MUST</bcp14> have meaning for the resources indicated in the
ee "aud" claim. See
<xref target="SecurityConsiderations"/> for more conside <xref target="SecurityConsiderations" format="default"/>
rations about the relationship between scope strings and resources indicated by for more considerations about the relationship between scope strings and resour
the "aud" claim. ces indicated by the "aud" claim.
</t> </t>
<section anchor="NDAuthorizationClaims" title="Claims for Au <section anchor="NDAuthorizationClaims" numbered="true" toc="default">
thorization Outside of Delegation Scenarios"> <name>Claims for Authorization Outside of Delegation Scenarios</name
<t> >
Many authorization servers embed <t>
in the access tokens they issue authorization attributes that go beyond the dele Many authorization servers embed
gated scenarios described by authorization attributes that go beyond the delegated scenarios described by
<xref target="RFC7519"/>. Typical examples include r <xref target="RFC7519" format="default"/> in the acc
esource owner memberships in roles and groups that are relevant to the resource ess tokens they issue. Typical examples include resource owner memberships in ro
being accessed, entitlements assigned to the resource owner for the targeted res les and groups that are relevant to the resource being accessed, entitlements as
ource that the authorization server knows about, and so on. signed to the resource owner for the targeted resource that the authorization se
rver knows about, and so on.
</t> </t>
<t> <t>
An authorization server wanting to include such attributes in a JWT access token An authorization server wanting to include such attributes in a JWT access token
SHOULD use as claim types the "groups","roles" and "entitlements" attributes of <bcp14>SHOULD</bcp14> use the "groups", "roles", and "entitlements" attributes
the "User" resource schema defined by Section 4.1.2 of <xref target="RFC7643"/> of the "User" resource schema defined by <xref target="RFC7643" sectionFormat="o
). f" section="4.1.2"/>) as claim types.
</t> </t>
<t> <t>
Authorization servers SHOULD encode the corresponding claim values according to Authorization servers <bcp14>SHOULD</bcp14> encode the corresponding claim value
the guidance defined in <xref target="RFC7643"/>. In particular, a non-normative s according to the guidance defined in <xref target="RFC7643" format="default"/>
example of "groups" attribute can be found in Section 8.2 of <xref target="RFC7 . In particular, a non-normative example of a "groups" attribute can be found in
643"/>. No specific vocabulary is provided for "roles" and "entitlements". <xref target="RFC7643" sectionFormat="of" section="8.2"/>. No specific vocabula
ry is provided for "roles" and "entitlements".
</t> </t>
<t> <t>
<xref target="IANA"/> of this document provides entr <xref target="IANAClaimsContent" format="default"/>
ies for registering "groups", "roles" and "entitlements" attributes from of this document provides entries for registering "groups", "roles", and "entitl
<xref target="RFC7643"/> as claim types to be used i ements" attributes from
n this profile. <xref target="RFC7643" format="default"/> as claim t
ypes to be used in this profile.
</t> </t>
</section> </section>
</section>
</section>
</section> </section>
<section anchor="JWTATLRequest" title="Requesting a JWT Access Token"> </section>
<t> </section>
<section anchor="JWTATLRequest" numbered="true" toc="default">
<name>Requesting a JWT Access Token</name>
<t>
An authorization server can issue a JWT access token in r esponse to any authorization grant defined by An authorization server can issue a JWT access token in r esponse to any authorization grant defined by
<xref target="RFC6749"/> and subsequent extensions meant to resu lt in an access token. <xref target="RFC6749" format="default"/> and subsequent extensi ons meant to result in an access token.
</t> </t>
<t>If the request includes a "resource" parameter (as defined in <t>If the request includes a "resource" parameter (as defined in
<xref target="RFC8707"/>), the resulting JWT access token "aud" <xref target="RFC8707" format="default"/>), the resulting JWT ac
claim SHOULD have the same value as the "resource" parameter in the request. cess token "aud" claim <bcp14>SHOULD</bcp14> have the same value as the "resourc
e" parameter in the request.
</t> </t>
<t>Example request below:</t> <t>Example request below:</t>
<t> <figure anchor="authz-endpoint-example-code">
<figure title="Authorization Request with Resource and Scope Par <name>Authorization Request with Resource and Scope Parameters</name>
ameters" anchor="authz-endpoint-example-code">
<artwork> <sourcecode name="" type=""><![CDATA[
<![CDATA[
GET /as/authorization.oauth2?response_type=code GET /as/authorization.oauth2?response_type=code
&client_id=s6BhdRkqt3 &client_id=s6BhdRkqt3
&state=xyz &state=xyz
&scope=openid%20profile%20reademail &scope=openid%20profile%20reademail
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&resource=https%3A%2F%2Frs.example.com%2F HTTP/1.1 &resource=https%3A%2F%2Frs.example.com%2F HTTP/1.1
Host: authorization-server.example.com Host: authorization-server.example.com
]]> ]]></sourcecode>
</artwork> </figure>
</figure> <t>
</t>
<t>
Once redeemed, the code obtained from the request above will resu lt in a JWT access token in the form shown below: Once redeemed, the code obtained from the request above will resu lt in a JWT access token in the form shown below:
</t> </t>
<t> <figure anchor="jwt-at-example-code">
<figure title="The Header and JWT Claims Set of a JWT Access Tok <name>The Header and JWT Claims Set of a JWT Access Token</name>
en" anchor="jwt-at-example-code"> <sourcecode name="" type="json"><![CDATA[
<artwork>
<![CDATA[
Header: Header:
{"typ":"at+JWT","alg":"RS256","kid":"RjEwOwOA"} {"typ":"at+JWT","alg":"RS256","kid":"RjEwOwOA"}
Claims: Claims:
{ {
"iss": "https://authorization-server.example.com/", "iss": "https://authorization-server.example.com/",
"sub": "5ba552d67", "sub": "5ba552d67",
"aud": "https://rs.example.com/", "aud": "https://rs.example.com/",
"exp": 1639528912, "exp": 1639528912,
"iat": 1618354090, "iat": 1618354090,
"jti" : "dbe39bf3a3ba4238a513f51d6e1691c4", "jti" : "dbe39bf3a3ba4238a513f51d6e1691c4",
"client_id": "s6BhdRkqt3", "client_id": "s6BhdRkqt3",
"scope": "openid profile reademail" "scope": "openid profile reademail"
} }
]]> ]]></sourcecode>
</artwork> </figure>
</figure> <t>
</t> The authorization server <bcp14>MUST NOT</bcp14> issue a JWT acce
<t> ss token if the authorization granted by the token would be ambiguous.
The authorization server MUST NOT issue a JWT access token if the
authorization granted by the token would be ambiguous.
See See
<xref target="SecurityConsiderations"/> for more details about c <xref target="SecurityConsiderations" format="default"/> for mor
ommon cases that might lead to ambiguity and strategies an authorization server e details about common cases that might lead to ambiguity and strategies an auth
can enact to prevent them. orization server can enact to prevent them.
</t> </t>
<t> <t>
If the request does not include a "resource" parameter, the autho If the request does not include a "resource" parameter, the autho
rization server MUST use in the "aud" claim a default resource indicator. If a " rization server <bcp14>MUST</bcp14> use a default resource indicator in the "aud
scope" parameter is present in the request, the authorization server SHOULD use " claim. If a "scope" parameter is present in the request, the authorization ser
it to infer the value of the default resource indicator to be used in the "aud" ver <bcp14>SHOULD</bcp14> use it to infer the value of the default resource indi
claim. The mechanism through which scopes are associated to default resource ind cator to be used in the "aud" claim. The mechanism through which scopes are asso
icator values is outside the scope of this specification. If the values in the " ciated with default resource indicator values is outside the scope of this speci
scope" parameter refer to different default resource indicator values, the autho fication. If the values in the "scope" parameter refer to different default reso
rization server SHOULD reject the request with "invalid_scope" as described in S urce indicator values, the authorization server <bcp14>SHOULD</bcp14> reject the
ection 4.1.2.1 of request with "invalid_scope" as described in <xref target="RFC6749" sectionForm
at="of" section="4.1.2.1"/>.
<xref target="RFC6749"/>.
</t>
</section>
<section anchor="JWTATLValidate" title="Validating JWT Access Tokens">
<t>
For the purpose of facilitating validation data retrieval
, it is here RECOMMENDED that authorization servers sign JWT access tokens with
an asymmetric algorithm.
</t>
<t>
Authorization servers SHOULD use
<xref target="RFC8414">OAuth 2.0 Authorization Server Metadata</ </t>
xref> to advertise to resource servers their signing keys via "jwks_uri" and wha </section>
t "iss" claim value to expect <section anchor="JWTATLValidate" numbered="true" toc="default">
via the "issuer" metadata value. Alternatively, authorization se <name>Validating JWT Access Tokens</name>
rvers implementing OpenID Connect MAY use the <xref target="OpenID.Discovery">"O <t>
penID Connect discovery</xref> document for the same purpose. If an authorizatio For the purpose of facilitating validation data retrieval
n server supports both OAuth 2.0 Authorization Server Metadata and OpenID Connec , it is <bcp14>RECOMMENDED</bcp14> here that authorization servers sign JWT acce
t discovery, the values provided MUST be consistent across the two publication m ss tokens with an asymmetric algorithm.
ethods. </t>
<t>
Authorization servers <bcp14>SHOULD</bcp14> use
<xref target="RFC8414" format="default">OAuth 2.0 Authorization
Server Metadata</xref> to advertise to resource servers their signing keys via "
jwks_uri" and what "iss" claim value to expect
via the "issuer" metadata value. Alternatively, authorization se
rvers implementing OpenID Connect <bcp14>MAY</bcp14> use the <xref target="OpenI
D.Discovery" format="default">OpenID Connect discovery</xref> document for the s
ame purpose. If an authorization server supports both OAuth 2.0 Authorization Se
rver Metadata and OpenID Connect discovery, the values provided <bcp14>MUST</bcp
14> be consistent across the two publication methods.
</t>
<t>
An authorization server <bcp14>MAY</bcp14> elect to use d
ifferent keys to sign OpenID Connect ID Tokens and JWT access tokens. This speci
fication does not provide a mechanism for identifying a specific key as the one
used to sign JWT access tokens. An authorization server can sign JWT access toke
ns with any of the keys advertised via authorization server (AS) metadata or Ope
nID Connect discovery. See
<xref target="SecurityConsiderations" format="default"/> for fur
ther guidance on security implications.
</t> </t>
<t> <t>
An authorization server MAY elect to use different keys t Resource servers receiving a JWT access token <bcp14>MUST
o sign OpenID Connect ID Tokens and JWT access tokens. This specification does n </bcp14> validate it in the following manner.
ot provide a mechanism for identifying a specific key as the one used to sign JW </t>
T access tokens. An authorization server can sign JWT access tokens with any of <ul spacing="normal">
the keys advertised via AS metadata or OpenID Connect discovery. See <li>
<xref target="SecurityConsiderations"/> for further guidance on The resource server <bcp14>MUST</bcp14> verify that the "typ" header value is "a
security implications. t+jwt" or "application/at+jwt" and reject tokens carrying any other value.
</li>
<li>
If the JWT access token is encrypted, decrypt it using the keys and algorithms t
hat the resource server specified during registration. If encryption was negotia
ted with the authorization server at registration time and the incoming JWT acce
ss token is not encrypted, the resource server <bcp14>SHOULD</bcp14> reject it.
</li>
<li>
The issuer identifier for the authorization server (which is typically obtained
during discovery) <bcp14>MUST</bcp14> exactly match the value of the "iss" claim
.
</li>
<li>
The resource server <bcp14>MUST</bcp14> validate that the "aud" claim contains a
resource indicator value corresponding to an identifier the resource server exp
ects for itself. The JWT access token <bcp14>MUST</bcp14> be rejected if "aud" d
oes not contain a resource indicator of the current resource server as a valid a
udience.
</li>
<li>
The resource server <bcp14>MUST</bcp14> validate the signature of all incoming J
WT access tokens according to
</t> <xref target="RFC7515" format="default"/> using the algo
<t> rithm specified in the JWT "alg" Header Parameter. The resource server <bcp14>MU
Resource servers receiving a JWT access token MUST valida ST</bcp14> reject any JWT in which the value of "alg" is "none". The resource se
te it in the following manner. rver <bcp14>MUST</bcp14> use the keys provided by the authorization server.
</t>
<t>
<list style="symbols">
<t>
The resource server MUST verify that the typ header value is "at+jwt" or "applic
ation/at+jwt" and reject tokens carrying any other value.
</t>
<t>
If the JWT access token is encrypted, decrypt it using the keys and algorithms t
hat the resource server specified during registration. If encryption was negotia
ted with the authorization server at registration time and the incoming JWT acce
ss token is not encrypted, the resource server SHOULD reject it.
</t>
<t>
The Issuer Identifier for the authorization server (which is typically obtained
during discovery) MUST exactly match the value of the "iss" claim.
</t>
<t>
The resource server MUST validate that the "aud" claim contains a resource indic
ator value corresponding to an identifier the resource server expects for itself
. The JWT access token MUST be rejected if "aud" does not contain a resource ind
icator of the current resource server as a valid audience.
</t>
<t>
The resource server MUST validate the signature of all incoming JWT access token
s according to
<xref target="RFC7515"/> using the algorithm specified i </li>
n the JWT alg Header Parameter. The resource server MUST reject any JWT in which <li>
the value of "alg" is "none". The resource server MUST use the keys provided by The current time <bcp14>MUST</bcp14> be before the time represented by the "exp"
the authorization server. claim. Implementers <bcp14>MAY</bcp14> provide for some small leeway, usually n
o more than a few minutes, to account for clock skew.
</li>
</ul>
<t>
The resource server <bcp14>MUST</bcp14> handle errors as described i
n <xref target="RFC6750" sectionFormat="of" section="3.1"/>. In particular, in c
ase of any failure in the validation checks listed above, the authorization serv
er response <bcp14>MUST</bcp14> include the error code "invalid_token".
</t> Please note that this requirement does not prevent JWT access to
<t> kens from using authentication schemes other than "Bearer".
The current time MUST be before the time represented by the "exp" claim. Impleme
nters MAY provide for some small leeway, usually no more than a few minutes, to
account for clock skew.
</t>
</list>
</t>
<t>
The resource server MUST handle errors as described in Section 3.1 o
f
<xref target="RFC6750"/>. In particular, in case of any failure
in the validation checks listed above the authorization server response MUST inc
lude the error code "invalid_token".
Please note that this requirement does not prevent JWT access to
kens to use authentications schemes other than Bearer.
</t> </t>
<t> <t>
If the JWT access token includes authorization claims as described in If the JWT access token includes authorization claims as described in
<xref target="AuthorizationClaims"/>, the resource server SHOULD use them in combination with any other contextual information available to dete rmine whether the current call should be authorized or rejected. Details about h ow a resource server performs those checks is beyond the scope of this profile s pecification. <xref target="AuthorizationClaims" format="default"/>, the resou rce server <bcp14>SHOULD</bcp14> use them in combination with any other contextu al information available to determine whether the current call should be authori zed or rejected. Details about how a resource server performs those checks is be yond the scope of this profile specification.
</t> </t>
</section> </section>
<section anchor="SecurityConsiderations" title="Security Considerations" <section anchor="SecurityConsiderations" numbered="true" toc="default">
> <name>Security Considerations</name>
<t> <t>
The JWT access token data layout described here is very s The JWT access token data layout described here is very s
imilar to the one of the id_token as defined by imilar to that of the id_token as defined by
<xref target="OpenID.Core"/>. The explicit typing required in th <xref target="OpenID.Core" format="default"/>. The explicit typi
is profile, in line with the recommendations in ng required in this profile, in line with the recommendations in
<xref target="RFC8725"/> helps the resource server to distinguis <xref target="RFC8725" format="default"/>, helps the resource se
h between JWT access tokens and OpenID Connect ID Tokens. rver to distinguish between JWT access tokens and OpenID Connect ID Tokens.
</t> </t>
<t> <t>
Authorization servers should prevent scenarios where clie nts can affect the value of the "sub" claim in ways that could confuse resource servers. Authorization servers should prevent scenarios where clie nts can affect the value of the "sub" claim in ways that could confuse resource servers.
For example, if the authorization server elects to use the client_id For example, if the authorization server elects to use the client_id
as the "sub" value for access tokens issued using the client credentials grant, as the "sub" value for access tokens issued using the client credentials grant,
the authorization server should prevent clients from registering an arbitrary c the authorization server should prevent clients from registering an arbitrary c
lient_id value, as this would allow malicious clients to select the sub of a hig lient_id value, as this would allow malicious clients to select the sub of a hig
h privilege resource owner and confuse any authorization logic on the resource s h-privilege resource owner and confuse any authorization logic on the resource s
erver relying on the "sub" value. erver relying on the "sub" value.
For more details please refer to Section 4.14 of For more details, please refer to <xref target="I-D.ietf-
<xref target="OAuth2.Security.BestPractices"/>. oauth-security-topics" sectionFormat="of" section="4.14"/>.
</t> </t>
<t> <t>
To prevent cross-JWT confusion, authorization servers MUST use a distinct identi To prevent cross-JWT confusion, authorization servers <bcp14>MUST</bcp14> use a
fier as "aud" claim value to uniquely identify access tokens issued by the same distinct identifier as an "aud" claim value to uniquely identify access tokens i
issuer for distinct resources. For more details on cross-JWT confusion please re ssued by the same issuer for distinct resources. For more details on cross-JWT c
fer to Section 2.8 of onfusion, please refer to <xref target="RFC8725" sectionFormat="of" section="2.8
<xref target="RFC8725"/>. "/>.
</t> </t>
<t> <t>
Authorization servers should use particular care when han Authorization servers should use particular care when han
dling requests that might lead to ambiguous authorization grants. For example: i dling requests that might lead to ambiguous authorization grants. For example, i
f a request includes multiple resource indicators, the authorization server shou f a request includes multiple resource indicators, the authorization server shou
ld ensure that each scope string included in the resulting JWT access token, if ld ensure that each scope string included in the resulting JWT access token, if
any, can be unambiguously correlated to a specific resource among the ones liste any, can be unambiguously correlated to a specific resource among the ones liste
d in the "aud" claim. The details on how to recognize and mitigate this and othe d in the "aud" claim. The details on how to recognize and mitigate this and othe
r ambiguous situations is highly scenario-dependent, hence out of scope for this r ambiguous situations is highly scenario dependent and hence is out of scope fo
profile. r this profile.
</t> </t>
<t> <t>
Authorization servers cannot rely on the use of different keys for s Authorization servers cannot rely on the use of different keys for s
igning OpenID Connect ID Tokens and JWT tokens as a method to safeguard against igning OpenID Connect ID Tokens and JWT tokens as a method to safeguard against
the consequences of leaking specific keys. Given that resource servers have no w the consequences of leaking specific keys. Given that resource servers have no w
ay of knowing what key should be used to validate JWT access tokens in particula ay of knowing what key should be used to validate JWT access tokens in particula
r, they have to accept signatures performed with any of the keys published in AS r, they have to accept signatures performed with any of the keys published in AS
metadata or OpenID Connect discovery: consequently, an attacker just needs to c metadata or OpenID Connect discovery; consequently, an attacker just needs to c
ompromise any key among the ones published to be able to generate and sign JWTs ompromise any key among the ones published to be able to generate and sign JWTs
that will be accepted as valid by the resource server. that will be accepted as valid by the resource server.
</t> </t>
</section> </section>
<section anchor="PrivacyConsiderations" title="Privacy Considerations"> <section anchor="PrivacyConsiderations" numbered="true" toc="default">
<t> <name>Privacy Considerations</name>
<t>
As JWT access tokens carry information by value, it now becomes possible for clients and potentially even end users to directly peek ins ide the token claims collection of unencrypted tokens. As JWT access tokens carry information by value, it now becomes possible for clients and potentially even end users to directly peek ins ide the token claims collection of unencrypted tokens.
</t> </t>
<t> <t>
The client MUST NOT inspect the content of the access tok The client <bcp14>MUST NOT</bcp14> inspect the content of
en: the authorization server and the resource server might decide to change toke the access token: the authorization server and the resource server might decide
n format at any time (for example by switching from this profile to opaque token to change the token format at any time (for example, by switching from this pro
s) hence any logic in the client relying on the ability to read the access token file to opaque tokens); hence, any logic in the client relying on the ability to
content would break without recourse. read the access token content would break without recourse.
The OAuth 2.0 framework assumes that access tokens are treated as op aque by clients. The OAuth 2.0 framework assumes that access tokens are treated as op aque by clients.
Administrators of authorization servers should also take into account that the content of an access token is visible to the client. Administrators of authorization servers should also take into account that the content of an access token is visible to the client.
Whenever client access to the access token content presents privacy Whenever client access to the access token content presents privacy
issues for a given scenario, the authorization server needs to take explicit ste issues for a given scenario, the authorization server needs to take explicit ste
ps to prevent it. ps to prevent them.
</t> </t>
<t> <t>
In scenarios in which JWT access tokens are accessible to the end user, it should be evaluated whether the information can be accessed wi thout privacy violations (for example, if an end user would simply access his or her own personal information) or if steps must be taken to enforce confidential ity. In scenarios in which JWT access tokens are accessible to the end user, it should be evaluated whether the information can be accessed wi thout privacy violations (for example, if an end user would simply access his or her own personal information) or if steps must be taken to enforce confidential ity.
</t> </t>
<t> <t>
Possible measures to prevent leakage of information to clients and e Possible measures to prevent leakage of information to clients and e
nd users include: encrypting the access token, encrypting the sensitive claims, nd users include: encrypting the access token, encrypting the sensitive claims,
omitting the sensitive claims or not using this profile, falling back on opaque omitting the sensitive claims or not using this profile, and falling back on opa
access tokens. que access tokens.
</t> </t>
<t> <t>
In every scenario, the content of the JWT access token wi ll eventually be accessible to the resource server. It's important to evaluate w hether In every scenario, the content of the JWT access token wi ll eventually be accessible to the resource server. It's important to evaluate w hether
the resource server gained the proper entitlement to have access to any content received in form of claims, for example through user cons ent the resource server gained the proper entitlement to have access to any content received in the form of claims, for example, through user consent
in some form, policies and agreements with the organizati on running the authorization servers, and so on. in some form, policies and agreements with the organizati on running the authorization servers, and so on.
For example, a user might not wish to consent to granting a given re For example, a user might not wish to consent to granting given reso
source server information about any of the non-mandatory claims enumerated in <x urce server information about any of the non-mandatory claims enumerated in <xre
ref target="JWTATLayout"/> (and subsections)." f target="JWTATLayout" format="default"/> (and its subsections).
</t>
</t> <t>
<t>
This profile mandates the presence of the "sub" claim in every JWT access token, making it possible for resource servers to rely on that informatio n for correlating incoming requests with data stored locally for the authenticat ed principal. This profile mandates the presence of the "sub" claim in every JWT access token, making it possible for resource servers to rely on that informatio n for correlating incoming requests with data stored locally for the authenticat ed principal.
Although the ability to correlate requests might be required by des ign in many scenarios, there are scenarios where the authorization server might want to prevent correlation. The "sub" claim should be populated by the authoriz ation servers according to a privacy impact assessment. Although the ability to correlate requests might be required by des ign in many scenarios, there are scenarios where the authorization server might want to prevent correlation. The "sub" claim should be populated by the authoriz ation servers according to a privacy impact assessment.
For instance, if a solution requires preventing tracking principal activities across multiple resource servers, the authorization server should ens ure that JWT access tokens meant for different resource servers have distinct "s ub" values that cannot be correlated in the event of resource servers collusion. For instance, if a solution requires preventing tracking of princip al activities across multiple resource servers, the authorization server should ensure that JWT access tokens meant for different resource servers have distinct "sub" values that cannot be correlated in the event of resource server collusio n.
Similarly, if a solution requires preventing a resource server from correlating the principal's activity within the resource itself, the authorizat ion server should assign different "sub" values for every JWT access token issue d. Similarly, if a solution requires preventing a resource server from correlating the principal's activity within the resource itself, the authorizat ion server should assign different "sub" values for every JWT access token issue d.
In turn, the client should obtain a new JWT access token for every In turn, the client should obtain a new JWT access token for every
call to the resource server, to ensure that the resource server receives differe call to the resource server to ensure that the resource server receives differen
nt "sub" and "jti" values at every call, thus preventing correlation between dis t "sub" and "jti" values at every call, thus preventing correlation between dist
tinct requests. inct requests.
</t> </t>
</section> </section>
<section anchor="IANA" title="IANA Considerations"> <section anchor="IANA" numbered="true" toc="default">
<section anchor="IANAMediaTypes" title="Media Type Registration" <name>IANA Considerations</name>
> <section anchor="IANAMediaTypes" numbered="true" toc="default">
<section anchor="IANAMediaTypesContent" title="Registry Cont <name>Media Type Registration</name>
ent"> <section anchor="IANAMediaTypesContent" numbered="true" toc="default">
<t> <name>Registry Content</name>
This section registers the "application/a <t>
t+jwt" media type This section registers "application/at+jwt", a new media type <xref t
arget="RFC2046" format="default"/> in the "Media Types" registry <xref target="I
<xref target="RFC2046"/> in the "Media Types" regist ANA.MediaTypes"/> in the
ry [IANA.MediaTypes] in the manner described in <xref target="RFC6838" format="default"/>. It can be used
manner described in to indicate that the
<xref target="RFC6838"/>, which can be used to indic
ate that the
content is an access token encoded in JWT format. content is an access token encoded in JWT format.
</t> </t>
<t> <dl spacing="normal">
<list style='symbols'> <dt>Type name:</dt><dd> Application</dd>
<t>Type name: application</t> <dt>Subtype name:</dt><dd>at+jwt</dd>
<t>Subtype name: at+jwt</t> <dt>Required parameters:</dt><dd>N/A</dd>
<t>Required parameters: N/A</t> <dt>Optional parameters:</dt><dd>N/A</dd>
<t>Optional parameters: N/A</t> <dt>Encoding considerations:</dt><dd> Binary; JWT values are
<t>Encoding considerations: binary; JWT values a
re
encoded as a series of base64url-encoded values (with trailing '=' encoded as a series of base64url-encoded values (with trailing '='
characters removed), some of which may be the empty string, characters removed), some of which may be the empty string,
separated by period ('.') characters.</t> separated by period ('.') characters.</dd>
<t>Security considerations: See the Security Con <dt>Security considerations:</dt><dd> See the Security Consideration
siderations Section of [[TODO: update once there's a RFC number for the JWT AT p s section of RFC 9068.</dd>
rofile]]</t> <dt>Interoperability considerations:</dt><dd>N/A</dd>
<t>Interoperability considerations: N/A</t> <dt>Published specification:</dt><dd>RFC 9068</dd>
<t>Published specification: [[TODO: update once <dt>Applications that use this media type:</dt><dd> Applications tha
there's a RFC number for the JWT AT profile]]</t> t access resource servers using OAuth 2.0 access tokens encoded in JWT format</d
<t>Applications that use this media type: Applic d>
ations that access resource servers using OAuth 2.0 access tokens encoded in JWT <dt>Fragment identifier considerations:</dt><dd>N/A</dd>
format</t>
<t>Fragment identifier considerations: N/A</t>
<t>Additional information:
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
</t>
<t>Person and email address to contact for furth
er information: Vittorio Bertocci, vittorio@auth0.com</t>
<t>Intended usage: COMMON</t>
<t>Restrictions on usage: none</t>
<t>Author: Vittorio Bertocci, vittorio@aut
h0.com</t>
<t>Change controller: IESG</t>
<t>Provisional registration? No</t>
</list>
</t>
</section>
</section>
<section anchor="IANAClaimTypes" title="Claims Registration">
<t>
<xref target="NDAuthorizationClaims"/> of this specifica
tion refers to the attributes "roles", "groups", "entitlements" defined in
<xref target="RFC7643"/> to express authorization inform
ation in JWT access tokens.
This section registers those attributes as claims in the
JSON Web Token (JWT) IANA registry introduced in
<xref target="RFC7519"/>.
</t>
<section anchor="IANAClaimsContent" title="Registry Contents
">
<section anchor="IANARoles" title="Roles">
<t>
<list style='symbols'>
<t>Claim Name: "roles"</t>
<t>Claim Description: Roles</t>
<t>Change Controller: IESG</t>
<t>Specification Document(s): Section 4.1.2
of <xref target="RFC7643"/> and <xref target="NDAuthorizationClaims"/> of [[this
specification]]</t>
</list>
</t>
</section>
<section anchor="IANAGroups" title="Groups">
<t>
<list style='symbols'>
<t>Claim Name: "groups"</t>
<t>Claim Description: Groups</t>
<t>Change Controller: IESG</t>
<t>Specification Document(s): Section 4.1.2 of <
xref target="RFC7643"/> and <xref target="NDAuthorizationClaims"/> of [[this sp
ecification]]</t>
</list>
</t>
</section>
<section anchor="IANAEntitlements" title="Entitlements">
<t>
<list style='symbols'>
<t>Claim Name: "entitlements"</t>
<t>Claim Description: Entitlements</t>
<t>Change Controller: IESG</t>
<t>Specification Document(s): Section 4.1.2 of <
xref target="RFC7643"/> and <xref target="NDAuthorizationClaims"/> of [[this sp
ecification]]</t>
</list>
</t>
</section>
</section>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/r
eference.RFC.7519.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/r
eference.RFC.2119.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/r
eference.RFC.6749.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/r
eference.RFC.8174.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/r
eference.RFC.7643.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/r
eference.RFC.7515.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/r
eference.RFC.8414.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/r
eference.RFC.2046.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/r
eference.RFC.6838.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/r
eference.RFC.8693.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/r
eference.RFC.8707.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/r
eference.RFC.8725.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/r
eference.RFC.7518.xml' ?>
<reference anchor='OpenID.Core' target='https://openid.net/specs
/openid-connect-core-1_0.html'>
<front>
<title>OpenID Connect Core 1.0</title>
<author initials='N' surname='Sakimura' fullname='Nat Sa
kimura'>
<organization />
</author>
<author initials='J' surname='Bradley' fullname='John Br
adley'>
<organization />
</author>
<author initials='M' surname='Jones' fullname='Mike Jone
s'>
<organization />
</author>
<author initials='B' surname='Medeiros' fullname='B Mede
iros'>
<organization />
</author>
<author initials='C' surname='Mortimore' fullname='Chuck
Mortimore'>
<organization />
</author>
<date month='November' year='2014' />
</front>
</reference>
<reference anchor='OpenID.Discovery' target='https://openid.net/
specs/openid-connect-discovery-1_0.html'>
<front>
<title>OpenID Connect Discovery 1.0</title>
<author initials='N' surname='Sakimura' fullname='Nat Sa
kimura'>
<organization />
</author>
<author initials='J' surname='Bradley' fullname='John Br
adley'>
<organization />
</author>
<author initials='M' surname='Jones' fullname='Mike Jone
s'>
<organization />
</author>
<author initials='J' surname='Jay' fullname='Edmund Jay'
>
<organization />
</author>
<date month='November' year='2014' />
</front>
</reference>
</references>
<references title="Informative References">
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/r
eference.RFC.7662.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/r
eference.RFC.6750.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/r
eference.RFC.7523.xml' ?>
<reference anchor='OAuth2.Security.BestPractices' target="https:
//datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-18">
<front>
<title>OAuth 2.0 Security Best Current Practice</title>
<author initials='T' surname='Lodderstedt' fullname='Tor
sten Lodderstedt'>
<organization />
</author>
<author initials='J' surname='Bradley' fullname='John Br
adley'>
<organization />
</author>
<author initials='A' surname='Labunets' fullname='Andrey
Labunets'>
<organization />
</author>
<author initials='D' surname='Fett' fullname='Daniel Fet
t'>
<organization />
</author>
<date month='July' year='2019' />
</front>
</reference>
</references>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
The initial set of requirements informing this specification was extract
ed by numerous examples of access tokens issued in JWT format by production syst
ems.
Thanks to Dominick Baier (IdentityServer), Brian Campbell (Ping Identity), Danie
l Dobalian (Microsoft), Karl Guinness (Okta) for providing sample tokens issued
by their products and services.
Brian Campbell and Filip Skokan provided early feedback that shap
ed the direction of the specification.
This profile was discussed at length during the OAuth Security Wo
rkshop 2019, with several individuals contributing ideas and feedback. The autho
r would like to acknowledge the contributions of:</t>
<t>
John Bradley,
Brian Campbell,
Vladimir Dzhuvinov,
Torsten Lodderstedt,
Nat Sakimura,
Hannes Tschofenig
and
everyone who actively participated in the unconference discussions.
</t>
<t>
The following individuals contributed useful feedback and
insights on the drafts, both on the IETF OAuth 2.0 WG DL and during the IIW28 c
onference:
</t>
<t>
Dale Olds,
George Fletcher,
David Waite,
Michael Engan,
Mike Jones,
Hans Zandbelt,
Vladimir Dzhuvinov,
Martin Schanzenbach ,
Aaron Parecki,
Annabelle Richard Backman,
Dick Hardt,
Denis Pinkas,
Benjamin Kaduk,
Dominick Baier,
Andrii Deinega,
Mike Jones
and
everyone who actively participated in the IIW28 unconference discussions
and the IETF OAuth 2.0 WG DL discussions.
Thanks to Roman Danyliw for the AD review, Joseph Salowey and Roni Even
for the SECDIR/GENART reviews, Francesca Palomini, Lars Eggert, Murray Kucherawy
, Roberto Polli, Martin Duke, Benjamin Kaduk for the IESG reviews.
</t>
</section>
<section anchor="History" title="Document History">
<?rfc subcompact="yes"?>
<t>
[[ to be removed by the RFC Editor before publication as an RFC ]]
</t>
<t>
draft-ietf-oauth-access-token-jwt-13
<list style='symbols'>
<t>
Added an explicit requirement for the JWT access tokens t
o be signed in <xref target="JWTATHeader"/>.
</t>
<t>
Added sections in <xref target="IANAClaimTypes"/> for imp
roving readability.
</t>
<t>
In <xref target="jwt-at-example-code"/>, added jti and ia
t claims.
</t>
<t>
Editorial fixes in <xref target="AuthenticationInfoClaims
"/> and <xref target="JWTATLValidate"/>.
</t>
<t>
Clarified that additional claims are to be added only if
necessary - in <xref target="IdentityClaims"/>. Editorial changes in the same s
ection.
</t>
<t>
Updates sample values in <xref target="JWTATLRequest"/>.
</t>
<t>
Added leeway language to the exp validation step in <xref
target="JWTATLValidate"/>.
</t>
<t>
In <xref target="JWTATLValidate"/>, clarified that the us
e of RFC6750 error codes does not imply that JWT ATs can only be Bearer tokens.
</t>
<t>
Various edits and nits in <xref target="SecurityConsidera
tions"/> and <xref target="PrivacyConsiderations"/>.
</t>
<t>
Added clarifying language in <xref target="PrivacyConside
rations"/> regarding what claims in the AT might require explicit user consent.
</t>
<t>
Added URLs for the OpenID references and the oauth securi
ty BCP. Moved RFC7523 to the informative references section.
</t>
</list>
</t>
<t>
draft-ietf-oauth-access-token-jwt-12
<list style='symbols'>
<t>
Editorial changes in the abstract.
</t>
<t>
Updated the client_id value in the figures in <xref targe
t="JWTATLRequest"/>.
</t>
<t>
Added clarifying language in <xref target="Introduction"/
> positioning this specification vs <xref target="RFC7523"/>.
</t>
<t>
In section <xref target="JWTATHeader"/> added a sentence
that makes RS256 support mandatory for AS and RS.
</t>
</list>
</t>
<t>
draft-ietf-oauth-access-token-jwt-11
<list style='symbols'>
<t>
Editorial updates and typo fixes in <xref target="Termino
logy"/>, <xref target="JWTATDataStructure"/>,
<xref target="AuthenticationInfoClaims"/>, <xref target=
"IdentityClaims"/>, <xref target="JWTATLRequest"/>,
<xref target="JWTATLValidate"/>, <xref target="Securit
yConsiderations"/>, <xref target="Acknowledgements"/>
</t>
<t>
Updated language in <xref target="IdentityClaims"/> to ex
plicitly refer to the JWT IANA registry.
</t>
<t>
Citation added in in <xref target="JWTATHeader"/>
</t>
<t>
Added a normative reference entry for OpenID Connect Disc
overy 1.0 and referenced it from <xref target="JWTATLValidate"/>
</t>
</list>
</t>
<t>
draft-ietf-oauth-access-token-jwt-10
<list style='symbols'>
<t>
Updated Figure 2 in <xref target="JWTATLRequest"/> to cla
rify that the intent of that snippet is to describe the content rather than exac
t JWT AT format.
</t>
<t>
Updated registry references in <xref target="IANACla
imsContent"/> to point to <xref target="NDAuthorizationClaims"/>
</t>
<t>
Modified <xref target="NDAuthorizationClaims"/> to make
it easier for the reader to understand what values and format is expected for th
e groups, roles and entitlement claims. Minor formatting issues fixed.
</t>
</list>
</t>
<t>
draft-ietf-oauth-access-token-jwt-09
<list style='symbols'>
<t>
Removed unused reference to http://www.iana.org/assignmen
ts/oauth-parameters; moved the OAuth2 security BCP to the informative references
section.
</t>
<t>
Restructured opening paragraphs in
<xref target="PrivacyConsiderations"/> for clarity.
</t>
</list>
</t>
<t>
draft-ietf-oauth-access-token-jwt-08
<list style='symbols'>
<t>
Numerous edits for correcting typos, improving clarity an
d precision of language.
</t>
<t>
Moved RFC7519 to the normative section; eliminated unused
references RFC7644 and RFC3986.
</t>
</list>
</t>
<t>
draft-ietf-oauth-access-token-jwt-07
<list style='symbols'>
<t>
In
<xref target="JWTATHeader"/>, added language that fo
rbids use of none as alg value, and references
<xref target="JWTATLValidate"/> where the same prohi
bition was already expressed from the RS perspective.
</t>
<t>
In the sub definition in
<xref target="JWTATDataStructure"/>, added a sentenc
e that clarifies what goes in the sub in the case of grants where a resource own
er is involved.
</t>
<t>
Updated acknowledgements.
</t>
<t>
Updated
<xref target="AuthenticationInfoClaims"/> to clarify
that acr, amr and auth_type can occur if the AT has been obtained by grants whe
re the resource owner is involved.
</t>
<t>
Updated
<xref target="IdentityClaims"/> to clarify that ide
ntity claims can occur if the AT has been obtained by grants where the resource
owner is involved.
</t>
<t>
In
<xref target="NDAuthorizationClaims"/> eliminated th
e claim that SCIM doesn't provide a vocabulary for the attributes listed there.
</t>
<t>
In
<xref target="SecurityConsiderations"/> added refere
nce to 8725.
</t>
<t>
In
<xref target="JWTATLValidate"/> added application/jw
t+at as accepted typ value.
</t>
<t>
Various typos and formatting issues fixed.
</t>
</list>
</t>
<t>
draft-ietf-oauth-access-token-jwt-06
<list style='symbols'>
<t>
In
<xref target="JWTATDataStructure"/> and
<xref target="PrivacyConsiderations"/> added a discu
ssion about how different sub values affect the privacy properties of a solution
.
</t>
<t>
In
<xref target="AuthorizationClaims"/> and
<xref target="JWTATLRequest"/> eliminated language p
rohibiting JWT AT requests featuring multiple resources, substituting it with th
e prohibition for the AS to emit JWT ATs expressing ambiguous authorization gran
ts.
In
<xref target="SecurityConsiderations"/>, added langu
age warning against scope confusion and mentioned the existence of other ambiguo
us authorization grant.
</t>
<t>
In
<xref target="JWTATDataStructure"/> promoted claims
iat and jti from RECOMMENDED to REQUIRED.
</t>
<t>
In
<xref target="JWTATHeader"/> eliminated temporary no
te on the lack of authenticated encryption methods specifications.
</t>
<t>
Updated acknowledgements.
</t>
</list>
</t>
<t>
draft-ietf-oauth-access-token-jwt-05
<list style='symbols'>
<t>
Varios typos, grammar issues and
improper abbreviations fixed.
</t>
<t>
Reworded the definition of at+jwt in
<xref target="JWTATHeader"/>.
</t>
<t>
In
<xref target="JWTATDataStructure"/>, clarified that
iat refers to the issuance time of the JWT itself.
</t>
<t>
In
<xref target="IdentityClaims"/>, added a reference t
o public/private claims definitions (Sections 4.2, 4.3) of
<xref target="RFC7519"/>.
</t>
<t>
In
<xref target="JWTATLRequest"/>, removed the paragrah
stating that every JWT AT MUST have an aud, as it is already defined in
<xref target="JWTATDataStructure"/>.
</t>
<t>
Reworded description of the JWT AT adoption landscape in
<xref target="Introduction"/>.
</t>
<t>
Simplified the individual descriptions of the claims list
in
<xref target="AuthenticationInfoClaims"/>.
</t>
<t>
Updated
<xref target="JWTATLValidate"/> and
<xref target="SecurityConsiderations"/> to clarify t
hat the AS can use any of the published keys to sign JWT access tokens, and that
the AS should not rely on use of different signing keys per token type as a sec
urity mechanism.
</t>
<t>
In
<xref target="JWTATDataStructure"/> promoted claims
iat and jti from OPTIONAL to RECOMMENDED
</t>
<t>
In
<xref target="JWTATLValidate"/>, switched the valida
tion steps list type from numbers to bullets.
</t>
<t>
In
<xref target="JWTATLValidate"/>, eliminated the auth
_time instructions from the validation steps list.
</t>
<t>
In
<xref target="IdentityClaims"/>, added a reference t
o the JWT claims registry as source of claims for JWT ATs
</t>
<t>
In
<xref target="JWTATLValidate"/>, clarified that fail
ures in JWT AT validation checks will result in invalid_token.
</t>
</list>
</t>
<t>
draft-ietf-oauth-access-token-jwt-04
<list style='symbols'>
<t>Eliminated reference to resource aliases list from th
e aud claim description in
<xref target="JWTATLayout"/>.
</t>
<t>Eliminated references to resource aliases list from t
he aud validation guidance in
<xref target="JWTATLValidate"/>.
</t>
<t>Introduced a new subsection
<xref target="AuthenticationInfoClaims"/>, moved the
definitions of auth_time, acr and amr there and incorporated the language propo
sed by Annabelle and Brian on the WG mailing list.
</t>
<t>In section
<xref target="JWTATLRequest"/> softened (from MUST t
o SHOULD) the requirement that ties the resource identifier in the request to th
e value in the aud claim of the issued access token.
</t> <dt>Additional information:</dt>
<t>Updated acknowledgements.</t> <dd><t><br/></t>
<t>In the section <dl spacing="compact" newline="false">
<dt>Magic number(s):</dt><dd>N/A</dd>
<dt>File extension(s):</dt><dd>N/A</dd>
<dt>Macintosh file type code(s):</dt><dd>N/A</dd>
</dl>
</dd>
<dt>Person &amp; email address to contact for further information:</
dt>
<dd><t><br/>Vittorio Bertocci &lt;vittorio@auth0.com&gt;</t></dd>
<xref target="JWTATLRequest"/>, the example request <dt>Intended usage:</dt><dd> COMMON</dd>
now has response_type=code. <dt>Restrictions on usage:</dt><dd> None</dd>
<dt>Author:</dt><dd>Vittorio Bertocci &lt;vittorio@auth0.com&gt;</dd
>
<dt>Change controller:</dt><dd>IETF</dd>
<dt>Provisional registration?</dt><dd>No</dd>
</dl>
</section>
</section>
<section anchor="IANAClaimTypes" numbered="true" toc="default">
<name>Claims Registration</name>
<t>
<xref target="NDAuthorizationClaims" format="default"/>
of this specification refers to the attributes "roles", "groups", "entitlements"
defined in
<xref target="RFC7643" format="default"/> to express aut
horization information in JWT access tokens.
This section registers those attributes as claims in the
"JSON Web Token (JWT)" IANA registry introduced in
<xref target="RFC7519" format="default"/>.
</t> </t>
<t>Updated text in the Privacy Consideration section to <section anchor="IANAClaimsContent" numbered="true" toc="default">
clarify what protection steps the text refers to.</t> <name>Registry Content</name>
<t>Updated the typ header discussion in <section anchor="IANARoles" numbered="true" toc="default">
<name>Roles</name>
<dl spacing="compact" newline="false">
<dt>Claim Name:</dt><dd>roles</dd>
<dt>Claim Description:</dt><dd> Roles</dd>
<dt>Change Controller:</dt><dd>IETF</dd>
<dt>Specification Document(s):</dt><dd> <xref target="RFC7643" sec
tionFormat="of" section="4.1.2"/> and <xref target="NDAuthorizationClaims" forma
t="default"/> of RFC 9068</dd>
</dl>
</section>
<section anchor="IANAGroups" numbered="true" toc="default">
<name>Groups</name>
<dl spacing="compact" newline="false">
<dt>Claim Name:</dt><dd> groups</dd>
<dt>Claim Description:</dt><dd>Groups</dd>
<dt>Change Controller:</dt><dd>IETF</dd>
<dt>Specification Document(s):</dt><dd> <xref target="RFC7643" sec
tionFormat="of" section="4.1.2"/> and <xref target="NDAuthorizationClaims" forma
t="default"/> of RFC 9068</dd>
</dl>
</section>
<section anchor="IANAEntitlements" numbered="true" toc="default">
<name>Entitlements</name>
<dl spacing="compact" newline="false">
<dt>Claim Name:</dt><dd> entitlements</dd>
<dt>Claim Description:</dt><dd> Entitlements</dd>
<dt>Change Controller:</dt><dd>IETF</dd>
<dt>Specification Document(s):</dt><dd> <xref target="RFC7643" sec
tionFormat="of" section="4.1.2"/> and <xref target="NDAuthorizationClaims" forma
t="default"/> of RFC 9068</dd>
</dl>
</section>
</section>
</section>
</section>
</middle>
<back>
<xref target="JWTATHeader"/> to clarify that it help s preventing resources from accepting OpenID Connect ID Tokens as JWT access tok ens. <displayreference target="I-D.ietf-oauth-security-topics" to="OAuth2.Security.Be stPractices"/>
</t> <references>
<t>Updated refrences to token exchange, resource indicat <name>References</name>
ors and JWT best practices to reflect their RFC status (8693,8707,8725). <references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7519.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6749.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7643.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7515.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8414.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2046.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6838.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8693.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8707.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8725.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7518.xml"/>
</t> <reference anchor="OpenID.Core" target="https://openid.net/specs/openid-
</list> connect-core-1_0.html">
</t> <front>
<t> <title>OpenID Connect Core 1.0 incorporating errata set 1</title>
draft-ietf-oauth-access-token-jwt-03 <author initials="N" surname="Sakimura" fullname="Nat Sakimura">
<organization/>
</author>
<author initials="J" surname="Bradley" fullname="John Bradley">
<organization/>
</author>
<author initials="M" surname="Jones" fullname="Mike Jones">
<organization/>
</author>
<author initials="B" surname="de Medeiros" fullname="Breno de Medeir
os">
<organization/>
</author>
<author initials="C" surname="Mortimore" fullname="Chuck Mortimore">
<organization/>
</author>
<date month="November" year="2014"/>
</front>
</reference>
<list style='symbols'> <reference anchor="OpenID.Discovery" target="https://openid.net/specs/op
<t> enid-connect-discovery-1_0.html">
Varios typos fixed. <front>
</t> <title>OpenID Connect Discovery 1.0 incorporating errata set 1</titl
<t>In the security considerations section, relaxed the c e>
laim that the typ header value "at+jwt" will prevent RS from misinterpreting JWT <author initials="N" surname="Sakimura" fullname="Nat Sakimura">
ATs as idtokens.</t> <organization/>
<t>In the "Requesting JWT Access Tokens" section, added </author>
"invalid_target" as a possible error returned for the multiple resources request <author initials="J" surname="Bradley" fullname="John Bradley">
case.</t> <organization/>
<t>In the Validating JWT Access Tokens" section, disallo </author>
wed JWTs with "alg":"none"</t> <author initials="M" surname="Jones" fullname="Mike Jones">
<t>in the IANA registration entries for the SCIM claim t <organization/>
ypes, complemented the reference to the SCIM spec with a reference to this spec </author>
so that the eventual registration entries have better context.</t> <author initials="E" surname="Jay" fullname="Edmund Jay">
<t>Updated acknowledgements.</t> <organization/>
<t>In the section </author>
<date month="November" year="2014"/>
</front>
</reference>
</references>
<references>
<name>Informative References</name>
<xref target="JWTATLRequest"/>, the example request <reference anchor="IANA.MediaTypes" target="https://www.iana.org/assignm
now has response_type=code. ents/media-types/">
<front>
<title>Media Types</title>
<author><organization>IANA</organization></author>
<date/>
</front>
</reference>
</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<t>Updated text in the Privacy Consideration section to FC.7662.xml"/>
clarify what protection steps the text refers to.</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</list> FC.6750.xml"/>
</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<t> FC.7523.xml"/>
draft-ietf-oauth-access-token-jwt-02
<list style='symbols'> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-oa
<t> uth-security-topics.xml"/>
In 2.2.1, opened the sour
ces of identity attributes to any identity related specification.
</t>
<t>
In 2.2.2, relaxed from MU
ST to SHOULD the requirement that requests including a scope always result in ac
cess tkens containing a corresponding scope claim.
</t>
<t>
In the security considerations setting, a
dded a requirement for the authorization server to assing unique identifiers for
different resources- to prevent cross JWT confusion.
</t>
<t>
Added IANA registration for the authoriza
tion attributes borrowed from SCIM CORE
</t>
</list>
</t>
<t>
draft-ietf-oauth-access-token-jwt-01
<list style='symbols'> </references>
<t> </references>
Added note on authenticat <section anchor="Acknowledgements" numbered="false" toc="default">
ed encryption. <name>Acknowledgements</name>
</t> <t>
<t> The initial set of requirements informing this specification was extract
Added a mention to the 1st party clients ed by numerous examples of access tokens issued in JWT format by production syst
scenarios in the identity claims section. ems.
</t> Thanks to <contact fullname="Dominick Baier"/> (IdentityServer), <contact fullna
<t> me="Brian Campbell"/> (Ping Identity), <contact fullname="Daniel Dobalian"/> (Mi
Changed the definition reference for the iss, exp, aud, s crosoft), and <contact fullname="Karl Guinness"/> (Okta) for providing sample to
ub, iat claims from OpenID.Core to RFC7519. kens issued by their products and services.
</t> <contact fullname="Brian Campbell"/> and <contact fullname="Filip
<t> Skokan"/> provided early feedback that shaped the direction of the specificatio
Added a mention of the client_id==sub cas n.
e in the security considerations section, added a reference to draft-ietf-oauth- This profile was discussed at length during the OAuth Security Wo
security-topics-13. Added a reference to the security considerations from the su rkshop 2019, with several individuals contributing ideas and feedback. The autho
b claim definition section. r would like to acknowledge the contributions of:</t>
</t> <t>
<t> <contact fullname="John Bradley"/>,
Specified invalid_request <contact fullname="Brian Campbell"/>,
as the error code the authorization server should return in case of multiple re <contact fullname="Vladimir Dzhuvinov"/>,
sources in the access token request. <contact fullname="Torsten Lodderstedt"/>,
</t> <contact fullname="Nat Sakimura"/>,
<t>Specified invalid_scope as the error code the authori <contact fullname="Hannes Tschofenig"/>,
zation server should return in case it isn;t possible to determine to which reso and
urce the requested scopes refers to.</t> everyone who actively participated in the unconference discussions.
<t> </t>
In the identity claims section, added a r
eference to introspection as possible source of claim types and added language e
xplicitly stating that the AS can add arbitrary attributes as long as they are c
ollision resistant or private.
</t>
<t>
Updated language for the auth_time claim
to include the case in which the AS reauthenticates the user mid-session (e.g. d
uring step up auth).
</t>
<t>
Removed note about adding
a mechanism for extablishing whether the token was obtained on behalf or the re
source owner or of the client itself (client credentials grant).
</t>
<t>
Removed note about adding
a mechanism for indicating whether the authorization server sent the resource o
wner to authenticate with a federated identity provider, and the identity of tha
t federated provider.
</t>
<t>
Removed the note in the s
ecurity consideration sections about discussing the purpose of aud, iss, exp val
idation (redundant).
</t>
<t>
In the authorization claims section, stat
ed intent to register roles, groups and entitlements as claim types in IANA
</t>
<t>
Clarified in the privacy considerations t
hat clients should not inspect access tokens.
</t>
<t>
Expanded the privacy considerations with
more explicit guidance about privacy preserving approaches.
</t>
<t>Added IANA registry content for the at+JWT MIME type.
</t>
<t>
Updated acknowledgements.
</t>
</list>
</t>
<t>
draft-ietf-oauth-access-token-jwt-00
<list style='symbols'> <t>
<t> The following individuals contributed useful feedback and
Initial draft to define a JWTt profile for OAuth 2.0 access tokens. insights on the drafts, both at the IETF OAuth 2.0 WG mailing list and during t
</t> he 28th Internet Identity Workshop (IIW 28):
</list> </t>
</t> <t>
<?rfc subcompact="no"?> <contact fullname="Dale Olds"/>,
</section> <contact fullname="George Fletcher"/>,
</back> <contact fullname="David Waite"/>,
</rfc> <contact fullname="Michael Engan"/>,
<contact fullname="Mike Jones"/>,
<contact fullname="Hans Zandbelt"/>,
<contact fullname="Vladimir Dzhuvinov"/>,
<contact fullname="Martin Schanzenbach"/>,
<contact fullname="Aaron Parecki"/>,
<contact fullname="Annabelle Richard Backman"/>,
<contact fullname="Dick Hardt"/>,
<contact fullname="Denis Pinkas"/>,
<contact fullname="Benjamin Kaduk"/>,
<contact fullname="Dominick Baier"/>,
<contact fullname="Andrii Deinega"/>,
<contact fullname="Mike Jones"/>,
and
everyone who actively participated in the IIW 28 unconference discussion
s and the IETF OAuth 2.0 WG mailing list discussions.
Thanks to <contact fullname="Roman Danyliw"/> for the AD review; <contac
t fullname="Joseph Salowey"/> and <contact fullname="Roni Even"/> for the SECDIR
and GENART reviews; and <contact fullname="Francesca Palomini"/>, <contact full
name="Lars Eggert"/>, <contact fullname="Murray Kucherawy"/>, <contact fullname=
"Roberto Polli"/>, <contact fullname="Martin Duke"/>, <contact fullname="Benjami
n Kaduk"/> for the IESG reviews.
</t>
</section>
</back>
</rfc>
 End of changes. 78 change blocks. 
1296 lines changed or deleted 748 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/