rfc8693xml2.original.xml   rfc8693.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
fc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- [rfced] updated by Chris /08/06/19 -->
<?rfc toc="yes"?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc submissionType="IETF" category="std" consensus="yes" number="XXXX" ipr="tru <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
st200902"> category="std" consensus="yes" number="8693" ipr="trust200902"
docName="draft-ietf-oauth-token-exchange-19" obsoletes="" updates=""
xml:lang="en" tocInclude="true" tocDepth="4"
symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 2.37.1 -->
<front> <front>
<title abbrev="OAuth 2.0 Token Exchange">OAuth 2.0 Token Exchange</title> <title abbrev="OAuth 2.0 Token Exchange">OAuth 2.0 Token Exchange</title>
<!-- An STS for the REST of Us --> <seriesInfo name="RFC" value="8693"/>
<author fullname="Michael B. Jones" initials="M." surname="Jones">
<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization>Microsoft</organization> <organization>Microsoft</organization>
<address> <address>
<email>mbj@microsoft.com</email> <email>mbj@microsoft.com</email>
<uri>http://self-issued.info/</uri> <uri>https://self-issued.info/</uri>
</address> </address>
</author> </author>
<author fullname="Anthony Nadalin" initials="A." surname="Nadalin"> <author fullname="Anthony Nadalin" initials="A." surname="Nadalin">
<organization>Microsoft</organization> <organization>Microsoft</organization>
<address> <address>
<email>tonynad@microsoft.com</email> <email>tonynad@microsoft.com</email>
</address> </address>
</author> </author>
<author fullname="Brian Campbell" initials="B." surname="Campbell" role="edi tor"> <author fullname="Brian Campbell" initials="B." surname="Campbell" role="edi tor">
<organization>Ping Identity</organization> <organization>Ping Identity</organization>
<address><email>brian.d.campbell@gmail.com</email></address> <address>
<email>brian.d.campbell@gmail.com</email>
</address>
</author> </author>
<author fullname="John Bradley" initials="J." surname="Bradley"> <author fullname="John Bradley" initials="J." surname="Bradley">
<organization>Yubico</organization> <organization>Yubico</organization>
<address><email>ve7jtb@ve7jtb.com</email></address> <address>
<email>ve7jtb@ve7jtb.com</email>
</address>
</author> </author>
<author fullname="Chuck Mortimore" initials="C." surname="Mortimore"> <author fullname="Chuck Mortimore" initials="C." surname="Mortimore">
<organization abbrev="Salesforce">Salesforce</organization> <organization abbrev="Visa">Visa</organization>
<address> <address>
<email>cmortimore@salesforce.com</email> <email>chuck.mortimore@visa.com</email>
</address> </address>
</author> </author>
<date year="2020" month="January"/>
<date year="2019" month="August"/>
<area>Security</area> <area>Security</area>
<workgroup>OAuth Working Group</workgroup> <workgroup>OAuth Working Group</workgroup>
<keyword>
<keyword>RFC</keyword> JSON Web Token, JWT, Delegation, Impersonation, STS, Security Token
<keyword>Request for Comments</keyword> Service, Exchange, Token, OAuth
<keyword>I-D</keyword> </keyword>
<keyword>Internet-Draft</keyword>
<keyword>JSON Web Token</keyword>
<keyword>JWT</keyword>
<keyword>Delegation</keyword>
<keyword>Impersonation</keyword>
<keyword>STS</keyword>
<keyword>Security Token Service</keyword>
<keyword>Exchange</keyword>
<keyword>Token</keyword>
<keyword>OAuth</keyword>
<abstract> <abstract>
<t> <t>
This specification defines a protocol for an HTTP- and JSON- based This specification defines a protocol for an HTTP- and JSON-based
Security Token Service (STS) by defining how to request and obtain Security Token Service (STS) by defining how to request and obtain
security tokens from OAuth 2.0 authorization servers, security tokens from OAuth 2.0 authorization servers,
including security tokens employing impersonation and delegation. including security tokens employing impersonation and delegation.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="Introduction" title="Introduction"> <section anchor="Introduction" numbered="true" toc="default">
<t> <name>Introduction</name>
A security token is a set of information that facilitates <t>
the sharing of identity and security information in heterogeneous environments A security token is a set of information that facilitates the sharing of
or across security domains. identity and security information in heterogeneous environments or across
Examples of security tokens include security domains. Examples of security tokens include JSON Web Tokens
JSON Web Tokens (JWTs) <xref target="JWT"/> and (JWTs) <xref target="RFC7519" format="default"/> and Security Assertion Markup
SAML 2.0 Assertions <xref target="OASIS.saml-core-2.0-os"/>. Language (SAML)
Security tokens are typically signed to achieve integrity 2.0 assertions <xref target="OASIS.saml-core-2.0-os" format="default"/>. Secu
and sometimes also encrypted to achieve confidentiality. rity tokens are
Security tokens are also sometimes described as Assertions, such as in typically signed to achieve integrity and sometimes also encrypted to
<xref target="RFC7521"/>. achieve confidentiality. Security tokens are also sometimes described as
assertions, such as in <xref target="RFC7521" format="default"/>.
</t> </t>
<t>
<t>
A Security Token Service (STS) is a service capable of validating A Security Token Service (STS) is a service capable of validating
security tokens provided to it and issuing new security tokens in security tokens provided to it and issuing new security tokens in
response, which enables clients to obtain appropriate response, which enables clients to obtain appropriate
access credentials for resources in heterogeneous environments or across secur ity access credentials for resources in heterogeneous environments or across secur ity
domains. domains.
Web Service clients have used <xref target="WS-Trust">WS-Trust</xref> Web Service clients have used WS-Trust <xref target="WS-Trust" format="default "></xref>
as the protocol to interact with an STS for token exchange. as the protocol to interact with an STS for token exchange.
While WS-Trust While WS-Trust
uses XML and SOAP, the trend in modern Web development uses XML and SOAP, the trend in modern Web development
has been towards RESTful patterns and JSON. has been towards RESTful (Representational State Transfer) patterns and JSON.
<xref target="RFC6749">The OAuth 2.0 Authorization Framework</xref> The OAuth 2.0 Authorization Framework <xref target="RFC6749" format="default">
and <xref target="RFC6750">OAuth 2.0 Bearer Tokens</xref> </xref>
and OAuth 2.0 Bearer Tokens <xref target="RFC6750" format="default"></xref>
have emerged as popular standards for authorizing third-party have emerged as popular standards for authorizing third-party
applications' access to HTTP and RESTful resources. applications' access to HTTP and RESTful resources.
The conventional OAuth 2.0 interaction involves the exchange of some The conventional OAuth 2.0 interaction involves the exchange of some
representation of resource owner authorization for an access token, representation of resource owner authorization for an access token,
which has proven to be an extremely useful pattern in practice. However, which has proven to be an extremely useful pattern in practice. However,
its input and output are somewhat too constrained as is to fully its input and output are somewhat too constrained as is to fully
accommodate a security token exchange framework. accommodate a security token exchange framework.
</t> </t>
<t> <t>
This specification defines a protocol extending OAuth 2.0 that enables This specification defines a protocol extending OAuth 2.0 that enables
clients to request and obtain security tokens from authorization servers actin g in clients to request and obtain security tokens from authorization servers actin g in
the role of an STS. the role of an STS.
Similar to OAuth 2.0, this specification focuses on client developer simplicit y and Similar to OAuth 2.0, this specification focuses on client developer simplicit y and
requires only an HTTP client and JSON parser, which are nearly universally ava ilable requires only an HTTP client and JSON parser, which are nearly universally ava ilable
in modern development environments. The STS protocol defined in this specifica tion in modern development environments. The STS protocol defined in this specifica tion
is not itself RESTful (an STS doesn't lend itself particularly well to a REST is not itself RESTful (an STS doesn't lend itself particularly well to a REST
approach) but does utilize communication patterns and data formats that should be approach) but does utilize communication patterns and data formats that should be
familiar to developers accustomed to working with RESTful systems. familiar to developers accustomed to working with RESTful systems.
</t> </t>
<t> <t>
A new grant type for a token exchange request and the associated specific para meters for A new grant type for a token exchange request and the associated specific para meters for
such a request to the token endpoint are defined by this specification. such a request to the token endpoint are defined by this specification.
A token exchange response is a normal OAuth 2.0 response from the token endpoi nt A token exchange response is a normal OAuth 2.0 response from the token endpoi nt
with a few additional parameters defined herein to provide information to the client. with a few additional parameters defined herein to provide information to the client.
</t> </t>
<t> <t>
The entity that makes the request to exchange tokens is considered the client in the The entity that makes the request to exchange tokens is considered the client in the
context of the token exchange interaction. However, that does not restrict context of the token exchange interaction. However, that does not restrict
usage of this profile to traditional OAuth clients. An OAuth resource server, for example, might assume usage of this profile to traditional OAuth clients. An OAuth resource server, for example, might assume
the role of the client during token exchange in order to trade an the role of the client during token exchange in order to trade an
access token that it received in a protected resource request for access token that it received in a protected resource request for
a new token that is appropriate to include in a call to a backend a new token that is appropriate to include in a call to a backend
service. The new token might be an access token that is more service. The new token might be an access token that is more
narrowly scoped for the downstream service or it could be an entirely differen t kind narrowly scoped for the downstream service or it could be an entirely differen t kind
of token. of token.
</t> </t>
<t> <t>
The scope of this specification is limited to the definition of a The scope of this specification is limited to the definition of a
basic request-and-response protocol for an STS-style token exchange utilizing OAuth 2.0. basic request-and-response protocol for an STS-style token exchange utilizing OAuth 2.0.
Although a few new JWT claims are defined that enable delegation semantics to be expressed, Although a few new JWT claims are defined that enable delegation semantics to be expressed,
the specific syntax, semantics and security characteristics of the tokens them selves the specific syntax, semantics, and security characteristics of the tokens the mselves
(both those presented to the authorization server and those obtained by the cl ient) (both those presented to the authorization server and those obtained by the cl ient)
are explicitly out of scope and no requirements are placed on the trust model in are explicitly out of scope, and no requirements are placed on the trust model in
which an implementation might be deployed. Additional profiles may provide which an implementation might be deployed. Additional profiles may provide
more detailed requirements around the specific nature of the parties and trust involved, more detailed requirements around the specific nature of the parties and trust involved,
such as whether signing and/or encryption of tokens is needed or if proof-of-p such as whether signing and/or encryption of tokens is needed or if proof-of-p
ossession style ossession-style
tokens will be required or issued; however, such details tokens will be required or issued. However, such details
will often be policy decisions made with respect to the specific needs of indi vidual will often be policy decisions made with respect to the specific needs of indi vidual
deployments and will be configured or implemented accordingly. deployments and will be configured or implemented accordingly.
</t> </t>
<t> <t>
The security tokens obtained may be used in a number of contexts, The security tokens obtained may be used in a number of contexts,
the specifics of which are also beyond the scope of this specification. the specifics of which are also beyond the scope of this specification.
</t> </t>
<section anchor="DelegationImpersonation" numbered="true" toc="default">
<section anchor="DelegationImpersonation" title="Delegation vs. Impersonat <name>Delegation vs. Impersonation Semantics</name>
ion Semantics"> <t>
<t>
One common use case for an STS (as alluded to in the previous section) One common use case for an STS (as alluded to in the previous section)
is to allow a resource server A to make calls to a backend service C on is to allow a resource server A to make calls to a backend service C on
behalf of the requesting user B. Depending on the local site policy and behalf of the requesting user B. Depending on the local site policy and
authorization infrastructure, it may be desirable for A to use its own authorization infrastructure, it may be desirable for A to use its own
credentials to access C along with an annotation of some form that A is credentials to access C along with an annotation of some form that A is
acting on behalf of B ("delegation"), or for A to be granted a limited acces s acting on behalf of B ("delegation") or for A to be granted a limited access
credential to C but that continues to identify B as the authorized credential to C but that continues to identify B as the authorized
entity ("impersonation"). Delegation and impersonation can be useful entity ("impersonation"). Delegation and impersonation can be useful
concepts in other scenarios involving multiple participants as well. concepts in other scenarios involving multiple participants as well.
</t> </t>
<t> <t>
When principal A impersonates principal B, A is given all When principal A impersonates principal B, A is given all
the rights that B has within some defined rights context the rights that B has within some defined rights context
and is indistinguishable from B in that context. and is indistinguishable from B in that context.
Thus, when principal A impersonates principal B, then insofar Thus, when principal A impersonates principal B, then insofar
as any entity receiving such a token is concerned, they are as any entity receiving such a token is concerned, they are
actually dealing with B. It is true that some members of the actually dealing with B. It is true that some members of the
identity system might have awareness that impersonation is identity system might have awareness that impersonation is
going on, but it is not a requirement. going on, but it is not a requirement.
For all intents and purposes, when A is impersonating B, A is B within the For all intents and purposes, when A is impersonating B, A is B within the
context of the rights authorized by the token. A's ability to impersonate B could context of the rights authorized by the token. A's ability to impersonate B could
be limited in scope or time, or even with a one-time-use restriction, be limited in scope or time, or even with a one-time-use restriction,
whether via the contents of the token or an out-of-band mechanism. whether via the contents of the token or an out-of-band mechanism.
</t> </t>
<t> <t>
Delegation semantics are different than Delegation semantics are different than
impersonation semantics, though the two are closely related. impersonation semantics, though the two are closely related.
With delegation semantics, principal A still has its own identity With delegation semantics, principal A still has its own identity
separate from B and it is explicitly understood that while B separate from B, and it is explicitly understood that while B
may have delegated some of its rights to A, any actions taken are may have delegated some of its rights to A, any actions taken are
being taken by A representing B. In a sense, A is an agent for B. being taken by A representing B. In a sense, A is an agent for B.
</t> </t>
<t> <t>
Delegation and impersonation are not inclusive of all situations. Delegation and impersonation are not inclusive of all situations.
When a principal is acting directly on its own behalf, for example, When a principal is acting directly on its own behalf, for example,
neither delegation nor impersonation are in play. They are, however, neither delegation nor impersonation are in play. They are, however,
the more common semantics operating for token exchange and, as such, are the more common semantics operating for token exchange and, as such, are
given more direct treatment in this specification. given more direct treatment in this specification.
</t> </t>
<t> <t>
Delegation semantics are typically expressed in a token by including informa tion about both the Delegation semantics are typically expressed in a token by including informa tion about both the
primary subject of the token as well as the actor to whom that subject has d elegated some of its rights. primary subject of the token as well as the actor to whom that subject has d elegated some of its rights.
Such a token is sometimes referred to as a composite token because it is com posed of information Such a token is sometimes referred to as a composite token because it is com posed of information
about multiple subjects. Typically, in the request, the <spanx style="verb"> subject_token</spanx> about multiple subjects. Typically, in the request, the <tt>subject_token</t t>
represents the identity of the party on represents the identity of the party on
behalf of whom the token is being requested while the <spanx style="verb">ac tor_token</spanx> represents behalf of whom the token is being requested while the <tt>actor_token</tt> r epresents
the identity of the party to whom the access rights of the issued token are being delegated. the identity of the party to whom the access rights of the issued token are being delegated.
A composite token issued by the authorization server will contain informatio n about both parties. A composite token issued by the authorization server will contain informatio n about both parties.
When and if a composite token is issued is at the discretion of the authoriz ation server and When and if a composite token is issued is at the discretion of the authoriz ation server and
applicable policy and configuration. applicable policy and configuration.
</t> </t>
<t> <t>
The specifics of representing a composite token and even whether or not such The specifics of representing a composite token and even whether or not
a token will be issued depend on the details of the implementation and the kind such a token will be issued depend on the details of the implementation
of token. and the kind of token. The representations of composite tokens that are
The representations of composite tokens that are not JWTs are beyond the sco not JWTs are beyond the scope of this specification. The <tt>actor_token</t
pe of this specification. t> request parameter, however, does provide
The <spanx style="verb">actor_token</spanx> request parameter, however, does a means for providing information about the desired actor, and the JWT
provide a means <tt>act</tt> claim can provide a representation of a
for providing information about the desired actor and the JWT <spanx style=" chain of delegation.
verb">act</spanx> claim </t>
can provide a representation of a chain of delegation.
</t>
</section> </section>
<section anchor="RNC" numbered="true" toc="default">
<section anchor="RNC" title="Requirements Notation and Conventions"> <name>Requirements Notation and Conventions</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
" NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
in this document are to be interpreted as described in RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
when, and only when, they appear in all capitals, as shown here. be interpreted as
</t> described in BCP&nbsp;14 <xref target="RFC2119" format="default"/> <xref tar
get="RFC8174" format="default"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section anchor="Terminology" numbered="true" toc="default">
<section anchor="Terminology" title="Terminology"> <name>Terminology</name>
<t> <t>
This specification uses the terms This specification uses the terms
"access token type", "authorization server", "client", "client identifi er", "access token type", "authorization server", "client", "client identifi er",
"resource server", "token endpoint", "token request", and "token respon se" "resource server", "token endpoint", "token request", and "token respon se"
defined by <xref target="RFC6749">OAuth 2.0</xref>, defined by OAuth 2.0 <xref target="RFC6749" format="default"></xref>,
and the terms "Base64url Encoding", "Claim", and "JWT Claims Set" defin ed by and the terms "Base64url Encoding", "Claim", and "JWT Claims Set" defin ed by
<xref target="JWT">JSON Web Token (JWT)</xref>. JSON Web Token (JWT) <xref target="RFC7519" format="default"></xref>.
</t> </t>
</section> </section>
</section> </section>
<section anchor="Messages" numbered="true" toc="default">
<section anchor="Messages" title="Token Exchange Request and Response"> <name>Token Exchange Request and Response</name>
<section title="Request" anchor="Request"> <section anchor="Request" numbered="true" toc="default">
<t> <name>Request</name>
<t>
A client requests a security token by making a token request to the authorizat ion A client requests a security token by making a token request to the authorizat ion
server's token endpoint using the extension grant type mechanism defined server's token endpoint using the extension grant type mechanism defined
in Section 4.5 of <xref target="RFC6749"/>. in <xref target="RFC6749" sectionFormat="of" section="4.5"/>.
</t> </t>
<t> <t>
Client authentication to the authorization server is done using the normal Client authentication to the authorization server is done using the normal
mechanisms provided by OAuth 2.0. mechanisms provided by OAuth 2.0.
Section 2.3.1 of <xref target="RFC6749"/> <xref target="RFC6749" sectionFormat="of" section="2.3.1"/>
defines password-based authentication of the client, defines password-based authentication of the client,
however, client authentication is extensible and other mechanisms are possible . however, client authentication is extensible and other mechanisms are possible .
For example, <xref target="RFC7523"/> defines client authentication using bear For example, <xref target="RFC7523" format="default"/> defines client authenti
er cation using bearer
JSON Web Tokens (JWTs) <xref target="JWT"/>. JSON Web Tokens (JWTs) <xref target="RFC7519" format="default"/>.
The supported methods of client authentication and whether or not to allow The supported methods of client authentication and whether or not to allow
unauthenticated or unidentified clients are deployment decisions that are unauthenticated or unidentified clients are deployment decisions that are
at the discretion of the authorization server. at the discretion of the authorization server.
Note that omitting client authentication allows Note that omitting client authentication allows
for a compromised token to be leveraged via an STS into other tokens by for a compromised token to be leveraged via an STS into other tokens by
anyone possessing the compromised token. Thus client anyone possessing the compromised token. Thus, client
authentication allows for additional authorization checks by the STS as to whi ch authentication allows for additional authorization checks by the STS as to whi ch
entities are permitted to impersonate or receive delegations from other entities are permitted to impersonate or receive delegations from other
entities. entities.
</t> </t>
<t> <t>
The client makes a token exchange request to the token endpoint with an extens ion The client makes a token exchange request to the token endpoint with an extens ion
grant type using the HTTP <spanx style='verb'>POST</spanx> method. The grant type using the HTTP <tt>POST</tt> method. The
following parameters are included in the HTTP request entity-body following parameters are included in the HTTP request entity-body
using the <spanx style='verb'>application/x-www-form-urlencoded</spanx> using the <tt>application/x-www-form-urlencoded</tt>
format with a character encoding of UTF-8 as described in format with a character encoding of UTF-8 as described in
Appendix B of RFC6749 <xref target="RFC6749"/>. <xref target="RFC6749" sectionFormat="of" section="B"/>.
</t> </t>
<t> <dl newline="true" spacing="normal">
<list style="hanging"> <dt>grant_type</dt>
<dd>
<t hangText="grant_type"> <bcp14>REQUIRED</bcp14>. The value
<vspace/> <tt>urn:ietf:params:oauth:grant-type:token-exchange</tt>
REQUIRED. The value
<spanx style='verb'>urn:ietf:params:oauth:grant-type:token-exchange</spanx>
indicates that a token exchange is being performed. indicates that a token exchange is being performed.
</t> </dd>
<dt>resource</dt>
<t hangText="resource"> <dd>
<vspace/> <bcp14>OPTIONAL</bcp14>.
OPTIONAL.
A URI that indicates the target service or resource where the client intends to use A URI that indicates the target service or resource where the client intends to use
the requested security token. This enables the authorization server to apply policy as appropriate the requested security token. This enables the authorization server to apply policy as appropriate
for the target, such as determining the type and content of the token to be issued or if and how for the target, such as determining the type and content of the token to be issued or if and how
the token is to be encrypted. the token is to be encrypted.
In many cases, a client will not have knowledge of the logical organization of the systems with In many cases, a client will not have knowledge of the logical organization of the systems with
which it interacts and will only know a URI of the service where it intends to use the token. which it interacts and will only know a URI of the service where it intends to use the token.
The <spanx style="verb">resource</spanx> parameter allows the client to indi cate to the authorization server The <tt>resource</tt> parameter allows the client to indicate to the authori zation server
where it intends to use the issued token by providing the location, typicall y as an https URL, in the where it intends to use the issued token by providing the location, typicall y as an https URL, in the
token exchange request in the same form that will be used to access that res ource. token exchange request in the same form that will be used to access that res ource.
The authorization server will typically have the capability to map from a re source URI value to The authorization server will typically have the capability to map from a re source URI value to
an appropriate policy. The value of the <spanx style="verb">resource</spanx> an appropriate policy. The value of the <tt>resource</tt> parameter <bcp14>M
parameter MUST be an UST</bcp14> be an
absolute URI, as specified by Section 4.3 of <xref target="RFC3986"/>, absolute URI, as specified by <xref target="RFC3986"
which MAY include a query component and MUST NOT include a fragment componen sectionFormat="of" section="4.3"/>,
t. that <bcp14>MAY</bcp14> include a query component and <bcp14>MUST NOT</bcp14
Multiple <spanx style="verb">resource</spanx> parameters may be used to indi > include a fragment component.
cate Multiple <tt>resource</tt> parameters may be used to indicate
that the issued token is intended to be used at the multiple resources liste d. that the issued token is intended to be used at the multiple resources liste d.
See <xref target="OAUTH-RESOURCE"/> for additional See <xref target="I-D.ietf-oauth-resource-indicators" format="default"/> for
background and uses of the <spanx style="verb">resource</spanx> parameter. additional
</t> background and uses of the <tt>resource</tt> parameter.
</dd>
<t hangText="audience"> <dt>audience</dt>
<vspace/> <dd>
OPTIONAL. <bcp14>OPTIONAL</bcp14>. The logical name of the target service where the c
The logical name of the target service where the client intends to use lient intends
the requested security token. This serves a purpose similar to the to use the requested security token. This serves a purpose similar to the
<spanx style="verb">resource</spanx> parameter, but with the client providin <tt>resource</tt> parameter but with the client
g a logical name providing a logical name for the target service. Interpretation of the
for the target service. Interpretation of the name requires that the value b name requires that the value be something that both the client and the
e something authorization server understand. An OAuth client identifier, a SAML entity
that both the client and the authorization server understand. An OAuth clien identifier <xref target="OASIS.saml-core-2.0-os" format="default"/>, and an
t identifier, OpenID Connect
a SAML entity identifier <xref target="OASIS.saml-core-2.0-os"/>, Issuer Identifier <xref target="OpenID.Core" format="default"/> are examples
an OpenID Connect Issuer Identifier <xref target="OpenID.Core"/>, of things that
are examples of things that might be used as <tt>audience</tt> parameter values.
might be used as <spanx style="verb">audience</spanx> parameter values. However, <tt>audience</tt> values used with a given
However, <spanx style="verb">audience</spanx> values used with a given authorization server must be unique within that server to ensure that
authorization server must be unique within that server, to ensure that they they are properly interpreted as the intended type of value. Multiple
are properly interpreted as the intended type of value. <tt>audience</tt> parameters may be used to indicate
Multiple <spanx style="verb">audience</spanx> parameters may be used to indi that the issued token is intended to be used at the multiple audiences
cate listed. The <tt>audience</tt> and <tt>resource</tt> parameters may be used
that the issued token is intended to be used at the multiple audiences liste together to indicate
d. multiple target services with a mix of logical names and resource URIs.
The <spanx style="verb">audience</spanx> and <spanx style="verb">resource</s </dd>
panx> parameters may <dt>scope</dt>
be used together to indicate multiple target services with a mix of logical <dd>
names and resource URIs. <bcp14>OPTIONAL</bcp14>. A list of space-delimited, case-sensitive
</t> strings, as defined in <xref target="RFC6749"
sectionFormat="of" section="3.3"/>, that allow the client to specify the des
<t hangText="scope"> ired scope of
<vspace/> the requested security token in the context of the service or resource
OPTIONAL. where the token will be used. The values and associated semantics of scope
A list of space-delimited, case-sensitive strings, as defined in Section 3.3 are service specific and expected to be described in the relevant service
of <xref target="RFC6749"/>, that allow the client to documentation.</dd>
specify the desired scope of the requested security token in the context of <dt>requested_token_type</dt>
the <dd>
service or resource where the token will be used. The values and associated <bcp14>OPTIONAL</bcp14>.
semantics of scope An identifier, as described in <xref target="TokenTypeIdentifiers" format="d
are service specific and expected to be described in the relevant service do efault"/>, for the type of the requested security token.
cumentation.</t>
<t hangText="requested_token_type">
<vspace/>
OPTIONAL.
An identifier, as described in <xref target="TokenTypeIdentifiers"/>, for th
e type of the requested security token.
If the requested type is unspecified, the issued token type is at If the requested type is unspecified, the issued token type is at
the discretion of the authorization server and may be dictated by the discretion of the authorization server and may be dictated by
knowledge of the requirements of the service or resource knowledge of the requirements of the service or resource
indicated by the <spanx style='verb'>resource</spanx> or indicated by the <tt>resource</tt> or
<spanx style="verb">audience</spanx> parameter. <tt>audience</tt> parameter.
</t> </dd>
<dt>subject_token</dt>
<t hangText="subject_token"> <dd>
<vspace/> <bcp14>REQUIRED</bcp14>.
REQUIRED.
A security token that represents the A security token that represents the
identity of the party on behalf of whom the request is being made. identity of the party on behalf of whom the request is being made.
Typically, the subject of this token will be the subject of Typically, the subject of this token will be the subject of
the security token issued in response to the request. the security token issued in response to the request.
</t> </dd>
<dt>subject_token_type</dt>
<t hangText="subject_token_type"> <dd>
<vspace/> <bcp14>REQUIRED</bcp14>.
REQUIRED. An identifier, as described in <xref target="TokenTypeIdentifiers" format="d
An identifier, as described in <xref target="TokenTypeIdentifiers"/>, that i efault"/>, that indicates the type of the security token in
ndicates the type of the security token in the <tt>subject_token</tt> parameter.
the <spanx style="verb">subject_token</spanx> parameter. </dd>
</t> <dt>actor_token</dt>
<dd>
<t hangText="actor_token"> <bcp14>OPTIONAL</bcp14>.
<vspace/>
OPTIONAL.
A security token that represents A security token that represents
the identity of the acting party. Typically, this will be the party that is authorized to use the requested security token and act on behalf of the subject. the identity of the acting party. Typically, this will be the party that is authorized to use the requested security token and act on behalf of the subject.
</t> </dd>
<dt>actor_token_type</dt>
<t hangText="actor_token_type"> <dd>
<vspace/> An identifier, as described in <xref target="TokenTypeIdentifiers" format="d
An identifier, as described in <xref target="TokenTypeIdentifiers"/>, that i efault"/>, that indicates the type of the security token in the
ndicates the type of the security token in the <tt>actor_token</tt> parameter.
<spanx style="verb">actor_token</spanx> parameter. This is <bcp14>REQUIRED</bcp14> when the <tt>actor_token</tt> parameter
This is REQUIRED when the <spanx style="verb">actor_token</spanx> parameter is present in the request but <bcp14>MUST NOT</bcp14> be included otherwise.
is present in the request but MUST NOT be included otherwise. </dd>
</t> </dl>
</list> <t>
</t> In processing the request, the authorization server <bcp14>MUST</bcp14> perfor
<t> m the appropriate validation procedures for the indicated token
In processing the request, the authorization server MUST perform the appropria
te validation procedures for the indicated token
type and, if the actor token is present, also type and, if the actor token is present, also
perform the appropriate validation procedures for its indicated token type. perform the appropriate validation procedures for its indicated token type.
The validity criteria and details of any particular token are beyond the scope of The validity criteria and details of any particular token are beyond the scope of
this document and are specific to the respective type of token and its content . this document and are specific to the respective type of token and its content .
</t> </t>
<t> <t>
In the absence of one-time-use or other semantics specific to the token type, the act of performing In the absence of one-time-use or other semantics specific to the token type, the act of performing
a token exchange has no impact on the validity of the subject token or actor t oken. a token exchange has no impact on the validity of the subject token or actor t oken.
Furthermore, the exchange is a one-time event and does not create a tight link age Furthermore, the exchange is a one-time event and does not create a tight link age
between the input and output tokens, so that (for example) while the expiratio n between the input and output tokens, so that (for example) while the expiratio n
time of the output token may be influenced by that of the input token, time of the output token may be influenced by that of the input token,
renewal or extension of the input token is not expected to be reflected in renewal or extension of the input token is not expected to be reflected in
the output token's properties. It may still be appropriate or desirable to pr opagate the output token's properties. It may still be appropriate or desirable to pr opagate
token revocation events. However, doing so is not a general property of the ST token-revocation events. However, doing so is not a general property of the ST
S S
protocol and would be specific to a particular implementation, token type or d protocol and would be specific to a particular implementation, token type, or
eployment. deployment.
</t> </t>
<section title="Relationship Between Resource, Audience and Scope"> <section numbered="true" toc="default">
<t> <name>Relationship between Resource, Audience, and Scope</name>
When requesting a token, the client can indicate the desired target se <t>
rvice(s) When requesting a token, the client can indicate the desired target
where it intends to use that token service(s) where it intends to use that token by way of the <tt>audien
by way of the <spanx style="verb">audience</spanx> and <spanx style="v ce</tt> and <tt>resource</tt> parameters as well as indicate the
erb">resource</spanx> desired scope of the requested token using the <tt>scope</tt> paramete
parameters, as well as indicating the r.
desired scope of the requested token using the <spanx style="verb">sco
pe</spanx> parameter.
The semantics of such a request are that the client is asking for a to ken with the requested The semantics of such a request are that the client is asking for a to ken with the requested
scope that is usable at all the requested target services. Effectively , the requested access rights of scope that is usable at all the requested target services. Effectively , the requested access rights of
the token are the cartesian product of all the scopes at all the targe the token are the Cartesian product of all the scopes at all the targe
t services. t services.
</t> </t>
<t> <t>
An authorization server may be unwilling or unable to fulfill any toke An authorization server may be unwilling or unable to fulfill any toke
n request but the likelihood n request, but the likelihood
of an unfulfillable request is significantly higher when very broad ac cess rights are being solicited. of an unfulfillable request is significantly higher when very broad ac cess rights are being solicited.
As such, in the absence of specific knowledge about the relationship o f systems in a deployment, As such, in the absence of specific knowledge about the relationship o f systems in a deployment,
clients should exercise discretion in the breadth of the access reques ted, particularly the clients should exercise discretion in the breadth of the access reques ted, particularly the
number of target services. An authorization server can use the <spanx number of target services. An authorization server can use the <tt>inv
style="verb">invalid_target</spanx> alid_target</tt>
error code, defined in <xref target="ErrorResponse"/>, to inform a cli error code, defined in <xref target="ErrorResponse" format="default"/>
ent that it requested access to , to inform a client that it requested access to
too many target services simultaneously. too many target services simultaneously.
</t> </t>
</section>
</section> </section>
<section anchor="Response" numbered="true" toc="default">
</section> <name>Response</name>
<t>
<section title="Response" anchor="Response">
<t>
The authorization server responds to a token exchange request with a normal The authorization server responds to a token exchange request with a normal
OAuth 2.0 response from the token endpoint, as specified in OAuth 2.0 response from the token endpoint, as specified in
Section 5 of <xref target="RFC6749"/>. Additional details and <xref target="RFC6749" sectionFormat="of" section="5"/>. Additional details an d
explanation are provided in the following subsections. explanation are provided in the following subsections.
</t> </t>
<section title="Successful Response" anchor="SuccessfulResponse"> <section anchor="SuccessfulResponse" numbered="true" toc="default">
<t> <name>Successful Response</name>
<t>
If the request is valid and meets all policy and other criteria of the authori zation server, If the request is valid and meets all policy and other criteria of the authori zation server,
a successful token response is constructed by adding the following parameters a successful token response is constructed by adding the following parameters
to the entity-body of the HTTP response using the "application/json" to the entity-body of the HTTP response using the "application/json"
media type, as specified by <xref target="RFC8259"/>, and an HTTP 200 status c ode. The media type, as specified by <xref target="RFC8259" format="default"/>, and an HTTP 200 status code. The
parameters are serialized into a JavaScript Object Notation (JSON) parameters are serialized into a JavaScript Object Notation (JSON)
structure by adding each parameter at the top level. structure by adding each parameter at the top level.
Parameter names and string values are included as JSON strings. Parameter names and string values are included as JSON strings.
Numerical values are included as JSON numbers. The order of Numerical values are included as JSON numbers. The order of
parameters does not matter and can vary. parameters does not matter and can vary.
</t> </t>
<t> <dl newline="true" spacing="normal">
<list style="hanging"> <dt>access_token</dt>
<dd>
<t hangText="access_token"> <bcp14>REQUIRED</bcp14>. The security token issued by the authorization server
<vspace/> in response
REQUIRED. The security token issued by the authorization server in response
to the token exchange request. to the token exchange request.
The <spanx style="verb">access_token</spanx> parameter from The <tt>access_token</tt> parameter from
Section 5.1 of <xref target="RFC6749"/> is used here to carry the requested <xref target="RFC6749" sectionFormat="of" section="5.1"/> is used here to carr
y the requested
token, which allows this token exchange protocol to use the existing OAuth 2.0 request token, which allows this token exchange protocol to use the existing OAuth 2.0 request
and response constructs defined for the token endpoint. and response constructs defined for the token endpoint.
The identifier <spanx style="verb">access_token</spanx> is used for historical The identifier <tt>access_token</tt> is used for historical
reasons and the issued token need not be an OAuth access token. reasons and the issued token need not be an OAuth access token.
</t> </dd>
<dt>issued_token_type</dt>
<t hangText="issued_token_type"> <dd>
<vspace/> <bcp14>REQUIRED</bcp14>. An identifier, as described in <xref target="TokenTy
REQUIRED. An identifier, as described in <xref target="TokenTypeIdentifiers"/ peIdentifiers" format="default"/>,
>,
for the representation of the issued security token. for the representation of the issued security token.
</t> </dd>
<t hangText="token_type">
<vspace/>
REQUIRED.
A case-insensitive value specifying the method of using the access token issue
d,
as specified in Section 7.1 of <xref target="RFC6749"/>.
It provides the client
with information about how to utilize the access token to access protected res
ources.
For example, a value of <spanx style="verb">Bearer</spanx>,
as specified in <xref target="RFC6750"/>, indicates that
the issued security token is a bearer token and the client can simply present
it as is without any
additional proof of eligibility beyond the contents of the token itself.
Note that the meaning of this parameter is different from the meaning of
the <spanx style="verb">issued_token_type</spanx> parameter,
which declares the representation of the issued security token;
the term "token type" is more typically used with the aforementioned meaning a
s the structural or syntactical
representation of the security token, as it is in
all <spanx style="verb">*_token_type</spanx> parameters in this specification.
If the issued token is not an access token or usable as an access token,
then the <spanx style="verb">token_type</spanx> value <spanx style="verb">N_A<
/spanx> is used
to indicate that an OAuth 2.0
<spanx style="verb">token_type</spanx> identifier is not applicable in that co
ntext.
</t>
<t hangText="expires_in"> <dt>token_type</dt>
<vspace/> <dd>
RECOMMENDED. The validity lifetime, in seconds, of the token issued by the <bcp14>REQUIRED</bcp14>. A case-insensitive value specifying the method of us
authorization server. Oftentimes the client will not have the inclination or c ing the
apability access token issued, as specified in <xref target="RFC6749"
to inspect the content of the token and this parameter provides a consistent a sectionFormat="of" section="7.1"/>.
nd token-type-agnostic It provides the client with information about how to utilize the access
token to access protected resources. For example, a value of <tt>Bearer</tt>,
as specified in <xref target="RFC6750" format="default"/>,
indicates that the issued security token is a bearer token and the client
can simply present it as is without any additional proof of eligibility
beyond the contents of the token itself. Note that the meaning of this
parameter is different from the meaning of the <tt>issued_token_type</tt> para
meter, which declares the
representation of the issued security token; the term "token type" is more
typically used to mean the structural or syntactical representation of the sec
urity token, as it is in all <tt>*_token_type</tt> parameters in this specificat
ion. If the
issued token is not an access token or usable as an access token, then the
<tt>token_type</tt> value <tt>N_A</tt>
is used to indicate that an OAuth 2.0 <tt>token_type</tt>
identifier is not applicable in that context.
</dd>
<dt>expires_in</dt>
<dd>
<bcp14>RECOMMENDED</bcp14>. The validity lifetime, in seconds, of the token i
ssued by the
authorization server. Oftentimes, the client will not have the inclination or
capability
to inspect the content of the token, and this parameter provides a consistent
and token-type-agnostic
indication of how long the token can be expected to be valid. indication of how long the token can be expected to be valid.
For example, the value 1800 denotes that the token will For example, the value 1800 denotes that the token will
expire in thirty minutes from the time the response was generated. expire in thirty minutes from the time the response was generated.
</t> </dd>
<dt>scope</dt>
<t hangText="scope"> <dd>
<vspace/> <bcp14>OPTIONAL</bcp14> if the scope of the issued security token is identical
OPTIONAL, if the scope of the issued security token is identical to the scope to the scope requested by the client;
requested by the client; otherwise, it is <bcp14>REQUIRED</bcp14>.
otherwise, REQUIRED. </dd>
</t> <dt>refresh_token</dt>
<dd>
<t hangText="refresh_token"> <bcp14>OPTIONAL</bcp14>.
<vspace/>
OPTIONAL.
A refresh token will typically not be issued when the exchange is of one tempo rary A refresh token will typically not be issued when the exchange is of one tempo rary
credential (the subject_token) for a different temporary credential (the issue d token) credential (the subject_token) for a different temporary credential (the issue d token)
for use in some other context. for use in some other context.
A refresh token can be issued in cases where the client of the token exchange needs the A refresh token can be issued in cases where the client of the token exchange needs the
ability to access a resource even when the original credential is no longer va lid ability to access a resource even when the original credential is no longer va lid
(e.g., user-not-present or offline scenarios where there is no longer any user entertaining (e.g., user-not-present or offline scenarios where there is no longer any user entertaining
an active session with the client). an active session with the client).
Profiles or deployments of this specification should clearly document the cond itions Profiles or deployments of this specification should clearly document the cond itions
under which a client should expect a refresh token in response to under which a client should expect a refresh token in response to
<spanx style="verb">urn:ietf:params:oauth:grant-type:token-exchange</spanx> <tt>urn:ietf:params:oauth:grant-type:token-exchange</tt>
grant type requests. grant type requests.
</t> </dd>
</dl>
</list> </section>
</t> <section anchor="ErrorResponse" numbered="true" toc="default">
</section> <name>Error Response</name>
<section anchor="ErrorResponse" title="Error Response"> <t>
<t> If the request itself is not valid or if either the <tt>subject_token</tt> o
If the request itself is not valid or if either the <spanx style="verb">subj r <tt>actor_token</tt> are invalid for any reason, or are
ect_token</spanx> or <spanx style="verb">actor_token</spanx> unacceptable based on policy, the authorization server <bcp14>MUST</bcp14> c
are invalid for any reason, or are unacceptable based on policy, the authori onstruct an
zation server error response, as specified in <xref target="RFC6749"
MUST construct an error response, as specified in Section 5.2 of <xref targe sectionFormat="of" section="5.2"/>.
t="RFC6749"/>. The value of the <tt>error</tt> parameter <bcp14>MUST</bcp14> be the
The value of the <spanx style='verb'>error</spanx> <tt>invalid_request</tt> error code.
parameter MUST be the <spanx style='verb'>invalid_request</spanx> error code </t>
. <t>
</t>
<t>
If the authorization server is unwilling or unable to issue a token for any target service If the authorization server is unwilling or unable to issue a token for any target service
indicated by the <spanx style="verb">resource</spanx> or <spanx style="verb" indicated by the <tt>resource</tt> or <tt>audience</tt> parameters,
>audience</spanx> parameters, the <tt>invalid_target</tt> error code <bcp14>SHOULD</bcp14> be used in the
the <spanx style="verb">invalid_target</spanx> error code SHOULD be used in error response.
the error response. </t>
</t> <t>
<t>
The authorization The authorization
server MAY include additional information regarding the reasons for the erro server <bcp14>MAY</bcp14> include additional information regarding the reaso
r ns for the error
using the <spanx style='verb'>error_description</spanx> as discussed in Sect using the <tt>error_description</tt> as discussed in <xref
ion 5.2 of <xref target="RFC6749"/>. target="RFC6749" sectionFormat="of" section="5.2"/>.
</t> </t>
<t> <t>
Other error codes may also be used, as appropriate. Other error codes may also be used, as appropriate.
</t> </t>
</section>
</section> </section>
<section anchor="MainExample" numbered="true" toc="default">
</section> <name>Example Token Exchange</name>
<t>
<section title="Example Token Exchange" anchor="MainExample">
<t>
The following example demonstrates a hypothetical token exchange in which The following example demonstrates a hypothetical token exchange in which
an OAuth resource server an OAuth resource server
assumes the role of the client during the exchange. It assumes the role of the client during the exchange. It
trades an access token, which it received in a protected resource request, for a new trades an access token, which it received in a protected resource request, for a new
token that it will use to call to a backend service token that it will use to call to a backend service
(extra line breaks and indentation in the examples are for display purposes on ly). (extra line breaks and indentation in the examples are for display purposes on ly).
</t> </t>
<t> <t>
<xref target="main-prr"/> shows the resource server receiving a protected reso <xref target="main-prr" format="default"/> shows the resource server receiving
urce request containing a protected resource request containing
an OAuth access token in the Authorization header, as specified in an OAuth access token in the Authorization header, as specified in
Section 2.1 of <xref target="RFC6750"/>. <xref target="RFC6750" sectionFormat="of" section="2.1"/>.
</t> </t>
<figure anchor="main-prr">
<figure title="Protected Resource Request" anchor="main-prr"> <name>Protected Resource Request</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
GET /resource HTTP/1.1 GET /resource HTTP/1.1
Host: frontend.example.com Host: frontend.example.com
Authorization: Bearer accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC Authorization: Bearer accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC
]]></artwork> ]]></artwork>
</figure> </figure>
<t>
<t> In <xref target="main-tereq" format="default"/>, the resource server assumes t
In <xref target="main-tereq"/>, the resource server assumes the role of clien he role of
t for the token exchange client for the token exchange, and the access token from the request in
and the access token from the request in <xref target="main-prr"/> is sent <xref target="main-prr" format="default"/> is sent to the authorization server
to the authorization using a
server using a request as specified in <xref target="Request"/>. request as specified in <xref target="Request" format="default"/>. The value
The value of the <spanx style="verb">subject_token</spanx> parameter carries t of the <tt>subject_token</tt> parameter carries the access token, and
he the value of the <tt>subject_token_type</tt> parameter
access token and the value of indicates that it is an OAuth 2.0 access token. The resource server, acting
the <spanx style="verb">subject_token_type</spanx> parameter indicates that it in the role of the client, uses its identifier and secret to authenticate to
is the authorization server using the HTTP Basic authentication scheme. The
an OAuth 2.0 access token. <tt>resource</tt> parameter indicates the location of the
The resource server, acting in the role of the client, uses its identifier and backend service, &lt;https://backend.example.com/api&gt;, where the issued tok
secret to authenticate to en
the authorization server using the HTTP Basic authentication scheme. will be used.
The <spanx style="verb">resource</spanx> parameter indicates the location
of the backend service, https://backend.example.com/api,
where the issued token will be used.
</t> </t>
<figure anchor="main-tereq">
<figure title="Token Exchange Request" anchor="main-tereq"> <name>Token Exchange Request</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
POST /as/token.oauth2 HTTP/1.1 POST /as/token.oauth2 HTTP/1.1
Host: as.example.com Host: as.example.com
Authorization: Basic cnMwODpsb25nLXNlY3VyZS1yYW5kb20tc2VjcmV0 Authorization: Basic cnMwODpsb25nLXNlY3VyZS1yYW5kb20tc2VjcmV0
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&resource=https%3A%2F%2Fbackend.example.com%2Fapi &resource=https%3A%2F%2Fbackend.example.com%2Fapi
&subject_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC &subject_token=accVkjcJyb4BWCxGsndESCJQbdFMogUC5PbRDqceLTC
&subject_token_type= &subject_token_type=
urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token
]]></artwork> ]]></artwork>
</figure> </figure>
<t>
<t>
The authorization server validates the client credentials and the The authorization server validates the client credentials and the
<spanx style="verb">subject_token</spanx> presented in the token <tt>subject_token</tt> presented in the token
exchange request. From the <spanx style="verb">resource</spanx> exchange request. From the <tt>resource</tt>
parameter, the authorization server is able to determine the parameter, the authorization server is able to determine the
appropriate policy to apply to the request and issues a token appropriate policy to apply to the request and issues a token
suitable for use at https://backend.example.com. suitable for use at &lt;https://backend.example.com&gt;.
The <spanx style="verb">access_token</spanx> parameter of the The <tt>access_token</tt> parameter of the
response shown in <xref target="main-teresp"/> contains the new token, which i response shown in <xref target="main-teresp" format="default"/> contains the n
s itself a bearer OAuth ew token, which is itself a bearer OAuth
access token that is valid for one minute. The token happens to be access token that is valid for one minute. The token happens to be
a JWT; however, its structure and format are opaque to a JWT; however, its structure and format are opaque to
the client so the <spanx style="verb">issued_token_type</spanx> the client, so the <tt>issued_token_type</tt>
indicates only that it is an access token. indicates only that it is an access token.
</t> </t>
<figure anchor="main-teresp">
<figure title="Token Exchange Response" anchor="main-teresp"> <name>Token Exchange Response</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/json Content-Type: application/json
Cache-Control: no-cache, no-store Cache-Control: no-cache, no-store
{ {
"access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjllciJ9.eyJhdWQiOiJo "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjllciJ9.eyJhdWQiOiJo
dHRwczovL2JhY2tlbmQuZXhhbXBsZS5jb20iLCJpc3MiOiJodHRwczovL2FzLmV dHRwczovL2JhY2tlbmQuZXhhbXBsZS5jb20iLCJpc3MiOiJodHRwczovL2FzLmV
4YW1wbGUuY29tIiwiZXhwIjoxNDQxOTE3NTkzLCJpYXQiOjE0NDE5MTc1MzMsIn 4YW1wbGUuY29tIiwiZXhwIjoxNDQxOTE3NTkzLCJpYXQiOjE0NDE5MTc1MzMsIn
N1YiI6ImJkY0BleGFtcGxlLmNvbSIsInNjb3BlIjoiYXBpIn0.40y3ZgQedw6rx N1YiI6ImJkY0BleGFtcGxlLmNvbSIsInNjb3BlIjoiYXBpIn0.40y3ZgQedw6rx
f59WlwHDD9jryFOr0_Wh3CGozQBihNBhnXEQgU85AI9x3KmsPottVMLPIWvmDCM f59WlwHDD9jryFOr0_Wh3CGozQBihNBhnXEQgU85AI9x3KmsPottVMLPIWvmDCM
y5-kdXjwhw", y5-kdXjwhw",
"issued_token_type": "issued_token_type":
"urn:ietf:params:oauth:token-type:access_token", "urn:ietf:params:oauth:token-type:access_token",
"token_type":"Bearer", "token_type":"Bearer",
"expires_in":60 "expires_in":60
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t>
<t>
The resource server can then use the newly acquired access token in making The resource server can then use the newly acquired access token in making
a request to the backend server as illustrated in <xref target="main-beprr"/>. a request to the backend server as illustrated in <xref target="main-beprr" fo rmat="default"/>.
</t> </t>
<figure anchor="main-beprr">
<figure title="Backend Protected Resource Request" anchor="main-beprr"> <name>Backend Protected Resource Request</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
GET /api HTTP/1.1 GET /api HTTP/1.1
Host: backend.example.com Host: backend.example.com
Authorization: Bearer eyJhbGciOiJFUzI1NiIsImtpZCI6IjllciJ9.eyJhdWQ Authorization: Bearer eyJhbGciOiJFUzI1NiIsImtpZCI6IjllciJ9.eyJhdWQ
iOiJodHRwczovL2JhY2tlbmQuZXhhbXBsZS5jb20iLCJpc3MiOiJodHRwczovL2 iOiJodHRwczovL2JhY2tlbmQuZXhhbXBsZS5jb20iLCJpc3MiOiJodHRwczovL2
FzLmV4YW1wbGUuY29tIiwiZXhwIjoxNDQxOTE3NTkzLCJpYXQiOjE0NDE5MTc1M FzLmV4YW1wbGUuY29tIiwiZXhwIjoxNDQxOTE3NTkzLCJpYXQiOjE0NDE5MTc1M
zMsInN1YiI6ImJkY0BleGFtcGxlLmNvbSIsInNjb3BlIjoiYXBpIn0.40y3ZgQe zMsInN1YiI6ImJkY0BleGFtcGxlLmNvbSIsInNjb3BlIjoiYXBpIn0.40y3ZgQe
dw6rxf59WlwHDD9jryFOr0_Wh3CGozQBihNBhnXEQgU85AI9x3KmsPottVMLPIW dw6rxf59WlwHDD9jryFOr0_Wh3CGozQBihNBhnXEQgU85AI9x3KmsPottVMLPIW
vmDCMy5-kdXjwhw vmDCMy5-kdXjwhw
]]></artwork> ]]></artwork>
</figure> </figure>
<t>
<!-- JWT signing key Additional examples can be found in <xref target="AdditionalExamples" format
{"kty":"EC","kid":"9er","use":"sig","alg":"ES256", ="default"/>.
"x":"5yoR9FjZHn7kJDALhDzhZ8i8F06mc12YswUMTBv4BoA", </t>
"y":"4uxuIItWj5Duzspth5mUbpLXWrPFzFPQkOCeAGGI6KM", </section>
"crv":"P-256",
"d":"LncS7zrx6c8X5qZRxoSN18ZEYDeI2wfKfUvX_DgwRH8"}
-->
<t>
Additional examples can be found in <xref target="AdditionalExamples"/>.
</t>
</section>
</section> </section>
<section anchor="TokenTypeIdentifiers" title="Token Type Identifiers"> <section anchor="TokenTypeIdentifiers" numbered="true" toc="default">
<t> <name>Token Type Identifiers</name>
<t>
Several parameters in this specification utilize an identifier as the value to Several parameters in this specification utilize an identifier as the value to
describe the token in question. describe the token in question.
Specifically, they are the Specifically, they are the
<spanx style="verb">requested_token_type</spanx>, <tt>requested_token_type</tt>,
<spanx style="verb">subject_token_type</spanx>, <spanx style="verb">actor_toke <tt>subject_token_type</tt>, and <tt>actor_token_type</tt>
n_type</spanx> parameters of the request and the <tt>issued_token_type</tt> member of the res
parameters of the request and the <spanx style="verb">issued_token_type</spanx ponse.
> member of the response.
Token type identifiers are URIs. Token type identifiers are URIs.
Token Exchange can work with both tokens issued by other parties and tokens fr Token exchange can work with both tokens issued by other parties and tokens fr
om om
the given authorization server. For the former the token type identifier indic the given authorization server. For the former, the token type identifier indi
ates cates
the syntax (e.g., JWT or SAML 2.0) so the authorization server can parse it; f the syntax (e.g., JWT or SAML 2.0) so the authorization server can parse it; f
or the latter it indicates or the latter, it indicates
what the given authorization server issued it for (e.g., access_token or refre what the given authorization server issued it for (e.g., <tt>access_token</tt>
sh_token). or <tt>refresh_token</tt>).
</t> </t>
<t> <t>
The following token type identifiers are defined by this specification. The following token type identifiers are defined by this specification.
Other URIs MAY be used to indicate other token types. Other URIs <bcp14>MAY</bcp14> be used to indicate other token types.
</t> </t>
<t> <dl newline="true" spacing="normal">
<list style="hanging"> <dt>urn:ietf:params:oauth:token-type:access_token</dt>
<dd>
<t hangText="urn:ietf:params:oauth:token-type:access_token">
<vspace/>
Indicates that the token is an OAuth 2.0 access token issued by the given au thorization server. Indicates that the token is an OAuth 2.0 access token issued by the given au thorization server.
</t> </dd>
<dt>urn:ietf:params:oauth:token-type:refresh_token</dt>
<t hangText="urn:ietf:params:oauth:token-type:refresh_token"> <dd>
<vspace/>
Indicates that the token is an OAuth 2.0 refresh token issued by the given a uthorization server. Indicates that the token is an OAuth 2.0 refresh token issued by the given a uthorization server.
</t> </dd>
<dt>urn:ietf:params:oauth:token-type:id_token</dt>
<t hangText="urn:ietf:params:oauth:token-type:id_token"> <dd>
<vspace/> Indicates that the token is an ID Token as defined in Section 2 of <xref
Indicates that the token is an ID Token, as defined in Section 2 of <xref ta target="OpenID.Core" format="default"/>.
rget="OpenID.Core"/>. </dd>
</t> <dt>urn:ietf:params:oauth:token-type:saml1</dt>
<dd>
<t hangText="urn:ietf:params:oauth:token-type:saml1"> Indicates that the token is a base64url-encoded SAML 1.1 <xref target="OASIS
<vspace/> .saml-core-1.1" format="default"/> assertion.
Indicates that the token is a base64url-encoded SAML 1.1 <xref target="OASIS </dd>
.saml-core-1.1"/> assertion. <dt>urn:ietf:params:oauth:token-type:saml2</dt>
</t> <dd>
Indicates that the token is a base64url-encoded SAML 2.0 <xref target="OASIS
<t hangText="urn:ietf:params:oauth:token-type:saml2"> .saml-core-2.0-os" format="default"/> assertion.
<vspace/> </dd>
Indicates that the token is a base64url-encoded SAML 2.0 <xref target="OASIS </dl>
.saml-core-2.0-os"/> assertion. <t>
</t> The value <tt>urn:ietf:params:oauth:token-type:jwt</tt>, which is defined in
</list> <xref target="RFC7519" sectionFormat="of" section="9"/>, indicates that the to
</t> ken is a JWT.
<t>
The value <spanx style="verb">urn:ietf:params:oauth:token-type:jwt</spanx>, wh
ich is defined in
Section 9 of <xref target="JWT"/>, indicates that the token is a JWT.
</t> </t>
<t> <t>
The distinction between an access token and a JWT is subtle. The distinction between an access token and a JWT is subtle.
An access token represents a delegated authorization decision, whereas JWT is a token format. An access token represents a delegated authorization decision, whereas JWT is a token format.
An access token can be formatted as a JWT but doesn't necessarily have to be. And a An access token can be formatted as a JWT but doesn't necessarily have to be. And a
JWT might well be an access token but not all JWTs are access tokens. JWT might well be an access token, but not all JWTs are access tokens.
The intent of this specification is that <spanx style="verb">urn:ietf:params:o auth:token-type:access_token</spanx> The intent of this specification is that <tt>urn:ietf:params:oauth:token-type: access_token</tt>
be an indicator that the token is a typical OAuth access token issued by the a uthorization server in question, opaque to the client, be an indicator that the token is a typical OAuth access token issued by the a uthorization server in question, opaque to the client,
and usable the same manner as any other access token obtained from that author ization server. and usable the same manner as any other access token obtained from that author ization server.
(It could well be a JWT, but the client isn't and needn't be aware of that fac t.) (It could well be a JWT, but the client isn't and needn't be aware of that fac t.)
Whereas, <spanx style="verb">urn:ietf:params:oauth:token-type:jwt</spanx> is t Whereas, <tt>urn:ietf:params:oauth:token-type:jwt</tt> is to indicate specific
o indicate specifically that a JWT is ally that a JWT is
being requested or sent (perhaps in a cross-domain use-case where the JWT is u being requested or sent (perhaps in a cross-domain use case where the JWT is u
sed as an authorization grant to sed as an authorization grant to
obtain an access token from a different authorization server as is facilitated obtain an access token from a different authorization server as is facilitated
by <xref target="RFC7523"/>). by <xref target="RFC7523" format="default"/>).
</t> </t>
<t> <t>
Note that for tokens which are binary in nature, the URI used for conveying th Note that for tokens that are binary in nature, the URI used for conveying the
em m
needs to be associated with the semantics of a base64 or other needs to be associated with the semantics of a base64 or other
encoding suitable for usage with HTTP and OAuth. encoding suitable for usage with HTTP and OAuth.
</t> </t>
</section> </section>
<section anchor="JWTClaims" numbered="true" toc="default">
<section title="JSON Web Token Claims and Introspection Response Parameters" <name>JSON Web Token Claims and Introspection Response Parameters</name>
anchor="JWTClaims"> <t>
<t> It is useful to have defined mechanisms to express delegation within a
It is useful to have defined mechanisms to express delegation within a token token as well as to express authorization to delegate or
as well as to express impersonate. Although the token exchange protocol described herein can be
authorization to delegate or impersonate. Although the token exchange protoco used with any type of token, this section defines claims to express such
l described semantics specifically for JWTs and in an OAuth 2.0 Token Introspection <xref
herein can be used with any type of token, this section defines claims to exp target="RFC7662"
ress such format="default"></xref> response. Similar
semantics specifically for JWTs and in an <xref target="RFC7662">OAuth 2.0 To definitions for other types of tokens are possible but beyond the scope of
ken Introspection</xref> response. this specification.
Similar definitions for other types of tokens are possible but </t>
beyond the scope of this specification. <t>
</t>
<t>
Note that the claims not established herein but used in examples and descript ions, Note that the claims not established herein but used in examples and descript ions,
such as <spanx style="verb">iss</spanx>, <spanx style="verb">sub</spanx>, such as <tt>iss</tt>, <tt>sub</tt>,
<spanx style="verb">exp</spanx>, etc., are defined by <xref target="JWT"/>. <tt>exp</tt>, etc., are defined by <xref target="RFC7519" format="default"/>.
</t> </t>
<section title='"act" (Actor) Claim' anchor="actor"> <section anchor="actor" numbered="true" toc="default">
<t> <name>"act" (Actor) Claim</name>
The <spanx style="verb">act</spanx> (actor) claim provides a means within <t>
a JWT The <tt>act</tt> (actor) claim provides a means
to express that delegation has occurred and identify the acting party to w within a JWT to express that delegation has occurred and identify the
hom authority has been delegated. acting party to whom authority has been delegated. The <tt>act</tt> claim
The <spanx style="verb">act</spanx> claim value is a JSON object and value is a JSON object, and members in
members in the JSON object are claims that identify the actor. the JSON object are claims that identify the actor. The claims that
The claims that make up the <spanx style="verb">act</spanx> make up the <tt>act</tt> claim identify and possibly
claim identify and possibly provide additional information about the actor provide additional information about the actor. For example, the
. combination of the two claims <tt>iss</tt> and <tt>sub</tt> might be neces
For example, the combination of the two claims <spanx style="verb">iss</sp sary to uniquely identify an
anx> actor.
and <spanx style="verb">sub</spanx> might be necessary to uniquely identif </t>
y an actor. <t>
</t> However, claims within the <tt>act</tt> claim pertain only to the identity
<t> of the actor
However, claims within the <spanx style="verb">act</spanx> claim pertain o
nly to the identity of the actor
and are not relevant to the validity of the containing JWT in the same man ner as the top-level claims. and are not relevant to the validity of the containing JWT in the same man ner as the top-level claims.
Consequently, non-identity claims (e.g., <spanx style="verb">exp</spanx>, Consequently, non-identity claims (e.g., <tt>exp</tt>, <tt>nbf</tt>,
<spanx style="verb">nbf</spanx>, and <tt>aud</tt>) are not meaningful when used within an
and <spanx style="verb">aud</spanx>) are not meaningful when used within a <tt>act</tt> claim and are therefore not used.
n </t>
<spanx style="verb">act</spanx> claim, and therefore are not used. <t><xref target="act-ex" format="default"/> illustrates the <tt>act</tt>
</t> (actor) claim within a JWT Claims Set. The
claims of the token itself are about user@example.com while the <tt>act<
<figure title="Actor Claim" anchor="act-ex"> /tt> claim indicates that admin@example.com is the
<preamble> current actor.
<xref target="act-ex"/> illustrates the <spanx style="verb">act</spanx> </t>
(actor) claim within a JWT Claims Set. <figure anchor="act-ex">
The claims of the token itself are about user@example.com while the <spa <name>Actor Claim</name>
nx style="verb">act</spanx> claim indicates <sourcecode type="json"><![CDATA[
that admin@example.com is the current actor.
</preamble>
<artwork><![CDATA[
{ {
"aud":"https://consumer.example.com", "aud":"https://consumer.example.com",
"iss":"https://issuer.example.com", "iss":"https://issuer.example.com",
"exp":1443904177, "exp":1443904177,
"nbf":1443904077, "nbf":1443904077,
"sub":"user@example.com", "sub":"user@example.com",
"act": "act":
{ {
"sub":"admin@example.com" "sub":"admin@example.com"
} }
} }]]></sourcecode></figure>
]]></artwork> <t>
</figure> A chain of delegation can be expressed by nesting one <tt>act</tt> claim w
ithin
<t> another. The outermost <tt>act</tt> claim represents the current actor whi
A chain of delegation can be expressed by nesting one <spanx style="verb"> le nested
act</spanx> claim within <tt>act</tt> claims represent prior actors. The least recent actor is the
another. The outermost <spanx style="verb">act</spanx> claim represents th most deeply
e current actor while nested nested. The nested <tt>act</tt> claims
<spanx style="verb">act</spanx> claims represent prior actors. The least r
ecent actor is the most deeply
nested. The nested <spanx style="verb">act</spanx> claims
serve as a history trail that connects the initial request and subject serve as a history trail that connects the initial request and subject
through the various delegation steps undertaken before reaching the through the various delegation steps undertaken before reaching the
current actor. In this sense, the current actor is considered to current actor. In this sense, the current actor is considered to
include the entire authorization/delegation history, leading naturally include the entire authorization/delegation history, leading naturally
to the nested structure described here. to the nested structure described here.
</t> </t>
<t> <t>
For the purpose of applying access control policy, the consumer of a token For the purpose of applying access control policy, the consumer of a token
MUST only consider the token's <bcp14>MUST</bcp14> only consider the token's
top-level claims and the party identified as the current actor by the <spa top-level claims and the party identified as the current actor by the <tt>
nx style="verb">act</spanx> act</tt>
claim. Prior actors identified by any nested <spanx style="verb">act</span claim. Prior actors identified by any nested <tt>act</tt> claims are
x> claims are
informational only and are not to be considered in access control decision s. informational only and are not to be considered in access control decision s.
</t> </t>
<figure title="Nested Actor Claim" anchor="acts-ex"> <t>
<preamble> The following example in <xref target="acts-ex" format="default"/> illus
The following example in <xref target="acts-ex"/> illustrates nested <sp trates nested <tt>act</tt> (actor) claims within a JWT Claims Set.
anx style="verb">act</spanx> (actor) claims within a JWT Claims Set. The claims of the token itself are about user@example.com while the <tt>
The claims of the token itself are about user@example.com while the <spa act</tt> claim indicates
nx style="verb">act</spanx> claim indicates that the system &lt;https://service16.example.com&gt; is the current act
that the system https://service16.example.com is the current actor and h or and &lt;https://service77.example.com&gt; was a prior actor.
ttps://service77.example.com was a prior actor.
Such a token might come about as the result of service16 receiving a tok en in a call from service77 Such a token might come about as the result of service16 receiving a tok en in a call from service77
and exchanging it for a token suitable to call service26 while the autho rization server and exchanging it for a token suitable to call service26 while the autho rization server
notes the situation in the newly issued token. notes the situation in the newly issued token.
</preamble> </t>
<artwork><![CDATA[ <figure anchor="acts-ex">
<name>Nested Actor Claim</name>
<sourcecode type="json"><![CDATA[
{ {
"aud":"https://service26.example.com", "aud":"https://service26.example.com",
"iss":"https://issuer.example.com", "iss":"https://issuer.example.com",
"exp":1443904100, "exp":1443904100,
"nbf":1443904000, "nbf":1443904000,
"sub":"user@example.com", "sub":"user@example.com",
"act": "act":
{ {
"sub":"https://service16.example.com", "sub":"https://service16.example.com",
"act": "act":
{ {
"sub":"https://service77.example.com" "sub":"https://service77.example.com"
} }
} }
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t> <t>
When included as a top-level member of an OAuth token introspection respon When included as a top-level member of an OAuth token introspection respon
se, <spanx style="verb">act</spanx> se, <tt>act</tt>
has the same semantics and format as the claim of the same name. has the same semantics and format as the claim of the same name.
</t> </t>
</section> </section>
<section title='"scope" (Scopes) Claim' anchor="scopes"> <section anchor="scopes" numbered="true" toc="default">
<t> <name>"scope" (Scopes) Claim</name>
The value of the <spanx style="verb">scope</spanx> claim is a <t>
The value of the <tt>scope</tt> claim is a
JSON string containing a space-separated list of JSON string containing a space-separated list of
scopes associated with the token, in the format described in scopes associated with the token, in the format described in
Section 3.3 of <xref target="RFC6749"/>. <xref target="RFC6749" sectionFormat="of" section="3.3"/>.
</t> </t>
<figure title="Scopes Claim" anchor="scope-ex"> <t><xref target="scope-ex" format="default"/> illustrates the <tt>scope<
<preamble> /tt> claim within a JWT Claims Set.
<xref target="scope-ex"/> illustrates the <spanx style="verb">scope</spa </t>
nx> claim within a JWT Claims Set. <figure anchor="scope-ex">
</preamble> <name>Scopes Claim</name>
<artwork><![CDATA[ <sourcecode type="json"><![CDATA[
{ {
"aud":"https://consumer.example.com", "aud":"https://consumer.example.com",
"iss":"https://issuer.example.com", "iss":"https://issuer.example.com",
"exp":1443904177, "exp":1443904177,
"nbf":1443904077, "nbf":1443904077,
"sub":"dgaf4mvfs75Fci_FL3heQA", "sub":"dgaf4mvfs75Fci_FL3heQA",
"scope":"email profile phone address" "scope":"email profile phone address"
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t> <t>
<xref target="RFC7662">OAuth 2.0 Token Introspection</xref> already define <xref target="RFC7662" format="default">OAuth 2.0 Token Introspection</xre
s the <spanx style="verb">scope</spanx> f> already defines the <tt>scope</tt>
parameter to convey the scopes associated with the token. parameter to convey the scopes associated with the token.
</t> </t>
</section> </section>
<section anchor="client_id" numbered="true" toc="default">
<section title='"client_id" (Client Identifier) Claim' anchor="client_id"> <name>"client_id" (Client Identifier) Claim</name>
<t> <t>
The <spanx style="verb">client_id</spanx> claim carries the The <tt>client_id</tt> claim carries the
client identifier of the <xref target="RFC6749">OAuth 2.0</xref> client th client identifier of the <xref target="RFC6749" format="default">OAuth 2.0
at </xref> client that
requested the token. requested the token.
</t> </t>
<t>
<figure title="Client Identifier Claim" anchor="client_id-ex"> The following example in <xref target="client_id-ex" format="default"/>
<preamble> illustrates the <tt>client_id</tt> claim within a JWT Claims Set
The following example in <xref target="client_id-ex"/> illustrates the <
spanx style="verb">client_id</spanx> claim within a JWT Claims Set
indicating an OAuth 2.0 client with "s6BhdRkqt3" as its identifier. indicating an OAuth 2.0 client with "s6BhdRkqt3" as its identifier.
</preamble> </t>
<artwork><![CDATA[ <figure anchor="client_id-ex">
<name>Client Identifier Claim</name>
<sourcecode type="json"><![CDATA[
{ {
"aud":"https://consumer.example.com", "aud":"https://consumer.example.com",
"iss":"https://issuer.example.com", "iss":"https://issuer.example.com",
"exp":1443904177, "exp":1443904177,
"sub":"user@example.com", "sub":"user@example.com",
"client_id":"s6BhdRkqt3" "client_id":"s6BhdRkqt3"
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t> <t>
<xref target="RFC7662">OAuth 2.0 Token Introspection</xref> already define <xref target="RFC7662" format="default">OAuth 2.0 Token Introspection</xre
s the <spanx style="verb">client_id</spanx> f> already defines the <tt>client_id</tt>
parameter as the client identifier for the OAuth 2.0 client that requested the token. parameter as the client identifier for the OAuth 2.0 client that requested the token.
</t> </t>
</section> </section>
<section anchor="may_act" numbered="true" toc="default">
<section title='"may_act" (Authorized Actor) Claim' anchor="may_act"> <name>"may_act" (Authorized Actor) Claim</name>
<t> <t>
The <spanx style="verb">may_act</spanx> claim makes a statement that one p The <tt>may_act</tt> claim makes a statement that one party is authorized
arty is authorized to to
become the actor and act on behalf of another party. become the actor and act on behalf of another party.
The claim might be used, for example, when a <spanx style="verb">subject_t oken</spanx> is The claim might be used, for example, when a <tt>subject_token</tt> is
presented to the token endpoint in a token exchange request and presented to the token endpoint in a token exchange request and
<spanx style="verb">may_act</spanx> claim in the subject token can be used by the authorization <tt>may_act</tt> claim in the subject token can be used by the authorizati on
server to determine whether the client (or party identified in the server to determine whether the client (or party identified in the
<spanx style="verb">actor_token</spanx>) is authorized to engage in the re quested delegation or <tt>actor_token</tt>) is authorized to engage in the requested delegation or
impersonation. impersonation.
The claim value is a JSON object and members in the JSON object are claims that identify the party that The claim value is a JSON object, and members in the JSON object are claim s that identify the party that
is asserted as being eligible to act for the party identified by is asserted as being eligible to act for the party identified by
the JWT containing the claim. the JWT containing the claim.
The claims that make up the <spanx style="verb">may_act</spanx> The claims that make up the <tt>may_act</tt>
claim identify and possibly provide additional information about the autho rized actor. claim identify and possibly provide additional information about the autho rized actor.
For example, the combination of the two claims <spanx style="verb">iss</sp For example, the combination of the two claims <tt>iss</tt>
anx> and <tt>sub</tt> are sometimes necessary to uniquely identify an authorize
and <spanx style="verb">sub</spanx> are sometimes necessary to uniquely id d actor,
entify an authorized actor, while the <tt>email</tt> claim might be used to provide additional useful
while the <spanx style="verb">email</spanx> claim might be used to provide information about
additional useful information about
that party. that party.
</t> </t>
<t> <t>
However, claims within the <spanx style="verb">may_act</spanx> claim perta However, claims within the <tt>may_act</tt> claim pertain only to the iden
in only to the identity of that party tity of that party
and are not relevant to the validity of the containing JWT and are not relevant to the validity of the containing JWT
in the same manner as top-level claims. in the same manner as top-level claims.
Consequently, claims such as <spanx style="verb">exp</spanx>, <spanx style Consequently, claims such as <tt>exp</tt>, <tt>nbf</tt>, and
="verb">nbf</spanx>, and <tt>aud</tt> are not meaningful when used within a <tt>may_act</tt>
<spanx style="verb">aud</spanx> are not meaningful when used within a <spa claim and are therefore not used.
nx style="verb">may_act</spanx> </t>
claim, and therefore are not used.
</t>
<t>
</t> <t><xref target="may_act-ex" format="default"/> illustrates the <tt>may_
<figure title="Authorized Actor Claim" anchor="may_act-ex"> act</tt> claim within a JWT Claims Set.
<preamble> The claims of the token itself are about user@example.com while the <tt>
<xref target="may_act-ex"/> illustrates the <spanx style="verb">may_act< may_act</tt> claim indicates
/spanx> claim within a JWT Claims Set.
The claims of the token itself are about user@example.com while the <spa
nx style="verb">may_act</spanx> claim indicates
that admin@example.com is authorized to act on behalf of user@example.co m. that admin@example.com is authorized to act on behalf of user@example.co m.
</preamble> </t>
<artwork><![CDATA[ <figure anchor="may_act-ex">
<name>Authorized Actor Claim</name>
<sourcecode type="json"><![CDATA[
{ {
"aud":"https://consumer.example.com", "aud":"https://consumer.example.com",
"iss":"https://issuer.example.com", "iss":"https://issuer.example.com",
"exp":1443904177, "exp":1443904177,
"nbf":1443904077, "nbf":1443904077,
"sub":"user@example.com", "sub":"user@example.com",
"may_act": "may_act":
{ {
"sub":"admin@example.com" "sub":"admin@example.com"
} }
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t> <t>
When included as a top-level member of an OAuth token introspection respon When included as a top-level member of an OAuth token introspection respon
se, <spanx style="verb">may_act</spanx> se, <tt>may_act</tt>
has the same semantics and format as the claim of the same name. has the same semantics and format as the claim of the same name.
</t> </t>
</section> </section>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t> <t>
Much of the guidance from Section 10 of <xref target="RFC6749"/>, Much of the guidance from <xref target="RFC6749"
sectionFormat="of" section="10"/>,
the Security Considerations in The OAuth 2.0 Authorization Framework, the Security Considerations in The OAuth 2.0 Authorization Framework,
is also applicable here. is also applicable here.
Furthermore, <xref target="RFC6819"/> Furthermore, <xref target="RFC6819" format="default"/>
provides additional security considerations for OAuth and provides additional security considerations for OAuth, and
<xref target="OAUTH-SECURITY"/> <xref target="I-D.ietf-oauth-security-topics" format="default"/>
has updated security guidance based on deployment experience and new thr eats that have has updated security guidance based on deployment experience and new thr eats that have
emerged since OAuth 2.0 was originally published. emerged since OAuth 2.0 was originally published.
</t> </t>
<t> <t>
All of the normal security issues that are discussed in <xref target="JW T"/>, All of the normal security issues that are discussed in <xref target="RF C7519" format="default"/>,
especially in relationship to comparing URIs and dealing with unrecogniz ed values, especially in relationship to comparing URIs and dealing with unrecogniz ed values,
also apply here. also apply here.
</t> </t>
<t> <t>
In addition, both delegation and impersonation introduce unique security In addition, both delegation and impersonation introduce unique
issues. Any time one principal is delegated the rights of security issues. Any time one principal is delegated the rights of
another principal, the potential for abuse is a concern. another principal, the potential for abuse is a concern. The use of
The use of the <spanx style="verb">scope</spanx> claim (in addition to o the <tt>scope</tt> claim (in addition to other
ther typical constraints such as a limited token lifetime) typical constraints such as a limited token lifetime) is suggested to
is suggested to mitigate mitigate potential for such abuse, as it restricts the contexts in
potential for such abuse, as it restricts the contexts in which which the delegated rights can be exercised.
the delegated rights can be exercised.
</t> </t>
</section> </section>
<section anchor="Privacy" title="Privacy Considerations"> <section anchor="Privacy" numbered="true" toc="default">
<name>Privacy Considerations</name>
<t> <t>
Tokens employed in the context of the functionality described herein Tokens employed in the context of the functionality described herein
may contain privacy-sensitive information and, to prevent may contain privacy-sensitive information and, to prevent
disclosure of such information to unintended parties, MUST only be disclosure of such information to unintended parties, <bcp14>MUST</bcp14 > only be
transmitted over encrypted channels, such as Transport Layer Security transmitted over encrypted channels, such as Transport Layer Security
(TLS). In cases where it is desirable to prevent disclosure of certain (TLS). In cases where it is desirable to prevent disclosure of certain
information to the client, the token MUST be encrypted to its information to the client, the token <bcp14>MUST</bcp14> be encrypted to
intended recipient. Deployments SHOULD determine the minimally necessary its
intended recipient. Deployments <bcp14>SHOULD</bcp14> determine the mini
mally necessary
amount of data and only include such information in issued tokens. amount of data and only include such information in issued tokens.
In some cases, data minimization may include representing only an In some cases, data minimization may include representing only an
anonymous or pseudonymous user. anonymous or pseudonymous user.
</t> </t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="IANA" title="IANA Considerations"> <section anchor="URIReg" numbered="true" toc="default">
<name>OAuth URI Registration</name>
<section anchor="URIReg" title="OAuth URI Registration"> <t>
IANA has registered the following values in the
<t> "OAuth URI" subregistry of the "OAuth Parameters" registry
This specification registers the following values in the <xref target="IANA.OAuth.Parameters" format="default"/>. The "OAuth URI
IANA "OAuth URI" registry " subregistry was
<xref target="IANA.OAuth.Parameters"/> established by <xref target="RFC6755" format="default"/>.
established by <xref target="RFC6755"/>. </t>
</t> <ul spacing="compact">
<li>URN: urn:ietf:params:oauth:grant-type:token-exchange</li>
<section title="Registry Contents" anchor="URIContents"> <li>Common Name: Token exchange grant type for OAuth 2.0</li>
<li>Change Controller: IESG</li>
<t> <li>Specification Document: <xref target="Request" format="default"/>
<?rfc subcompact="yes"?> of RFC 8693</li>
<list style="symbols"> </ul>
<t>URN: urn:ietf:params:oauth:grant-type:token-exchange</t> <ul spacing="compact">
<t>Common Name: Token exchange grant type for OAuth 2.0</t> <li>URN: urn:ietf:params:oauth:token-type:access_token</li>
<t>Change controller: IESG</t> <li>Common Name: Token type URI for an OAuth 2.0 access token</li>
<t>Specification Document: <xref target="Request"/> of [[ this spec <li>Change Controller: IESG</li>
ification ]]</t> <li>Specification Document: <xref target="TokenTypeIdentifiers" format
</list> ="default"/> of RFC 8693</li>
</t> </ul>
<t> <ul spacing="compact">
<list style="symbols"> <li>URN: urn:ietf:params:oauth:token-type:refresh_token</li>
<t>URN: urn:ietf:params:oauth:token-type:access_token</t> <li>Common Name: Token type URI for an OAuth 2.0 refresh token</li>
<t>Common Name: Token type URI for an OAuth 2.0 access token</t> <li>Change Controller: IESG</li>
<t>Change controller: IESG</t> <li>Specification Document: <xref target="TokenTypeIdentifiers" format
<t>Specification Document: <xref target="TokenTypeIdentifiers"/> of ="default"/> of RFC 8693</li>
[[this specification]]</t> </ul>
</list> <ul spacing="compact">
</t> <li>URN: urn:ietf:params:oauth:token-type:id_token</li>
<t> <li>Common Name: Token type URI for an ID Token</li>
<list style="symbols"> <li>Change Controller: IESG</li>
<t>URN: urn:ietf:params:oauth:token-type:refresh_token</t> <li>Specification Document: <xref target="TokenTypeIdentifiers" format
<t>Common Name: Token type URI for an OAuth 2.0 refresh token</t> ="default"/> of RFC 8693</li>
<t>Change controller: IESG</t> </ul>
<t>Specification Document: <xref target="TokenTypeIdentifiers"/> of <ul spacing="compact">
[[this specification]]</t> <li>URN: urn:ietf:params:oauth:token-type:saml1</li>
</list> <li>Common Name: Token type URI for a base64url-encoded SAML 1.1 asser
</t> tion</li>
<t> <li>Change Controller: IESG</li>
<list style="symbols"> <li>Specification Document: <xref target="TokenTypeIdentifiers" format
<t>URN: urn:ietf:params:oauth:token-type:id_token</t> ="default"/> of RFC 8693</li>
<t>Common Name: Token type URI for an ID Token</t> </ul>
<t>Change controller: IESG</t> <ul spacing="compact">
<t>Specification Document: <xref target="TokenTypeIdentifiers"/> of <li>URN: urn:ietf:params:oauth:token-type:saml2</li>
[[this specification]]</t> <li>Common Name: Token type URI for a base64url-encoded SAML 2.0 asser
</list> tion</li>
</t> <li>Change Controller: IESG</li>
<t> <li>Specification Document: <xref target="TokenTypeIdentifiers" format
<list style='symbols'> ="default"/> of RFC 8693</li>
<t>URN: urn:ietf:params:oauth:token-type:saml1</t> </ul>
<t>Common Name: Token type URI for a base64url-encoded SAML 1.1 ass
ertion</t>
<t>Change Controller: IESG</t>
<t>Specification Document: <xref target="TokenTypeIdentifiers"/> of
[[this specification]]</t>
</list>
</t>
<t>
<list style='symbols'>
<t>URN: urn:ietf:params:oauth:token-type:saml2</t>
<t>Common Name: Token type URI for a base64url-encoded SAML 2.0 ass
ertion</t>
<t>Change Controller: IESG</t>
<t>Specification Document: <xref target="TokenTypeIdentifiers"/> of
[[this specification]]</t>
</list>
</t>
<?rfc subcompact="no"?>
</section>
</section>
<section anchor="OAuthParametersReg" title="OAuth Parameters Registration"
>
<t>
This specification registers the following values
in the IANA "OAuth Parameters" registry
<xref target="IANA.OAuth.Parameters"/>
established by <xref target="RFC6749"/>.
</t>
<section anchor='ParametersContents' title='Registry Contents'>
<t>
<?rfc subcompact="yes"?>
<list style='symbols'>
<t>Parameter name: resource</t>
<t>Parameter usage location: token request</t>
<t>Change controller: IESG</t>
<t>Specification document(s): <xref target="Request"/> of [[ this s
pecification ]]</t>
</list>
</t>
<t>
<list style='symbols'>
<t>Parameter name: audience</t>
<t>Parameter usage location: token request</t>
<t>Change controller: IESG</t>
<t>Specification document(s): <xref target="Request"/> of [[ this s
pecification ]]</t>
</list>
</t>
<t>
<list style='symbols'>
<t>Parameter name: requested_token_type</t>
<t>Parameter usage location: token request</t>
<t>Change controller: IESG</t>
<t>Specification document(s): <xref target="Request"/> of [[ this s
pecification ]]</t>
</list>
</t>
<t>
<list style='symbols'>
<t>Parameter name: subject_token</t>
<t>Parameter usage location: token request</t>
<t>Change controller: IESG</t>
<t>Specification document(s): <xref target="Request"/> of [[ this s
pecification ]]</t>
</list>
</t>
<t>
<list style='symbols'>
<t>Parameter name: subject_token_type</t>
<t>Parameter usage location: token request</t>
<t>Change controller: IESG</t>
<t>Specification document(s): <xref target="Request"/> of [[ this s
pecification ]]</t>
</list>
</t>
<t>
<list style='symbols'>
<t>Parameter name: actor_token</t>
<t>Parameter usage location: token request</t>
<t>Change controller: IESG</t>
<t>Specification document(s): <xref target="Request"/> of [[ this s
pecification ]]</t>
</list>
</t>
<t>
<list style='symbols'>
<t>Parameter name: actor_token_type</t>
<t>Parameter usage location: token request</t>
<t>Change controller: IESG</t>
<t>Specification document(s): <xref target="Request"/> of [[ this s
pecification ]]</t>
</list>
</t>
<t>
<list style='symbols'>
<t>Parameter name: issued_token_type</t>
<t>Parameter usage location: token response</t>
<t>Change controller: IESG</t>
<t>Specification document(s): <xref target="SuccessfulResponse"/> o
f [[ this specification ]]</t>
</list>
</t>
<?rfc subcompact="no"?>
</section>
</section> </section>
<section anchor="OAuthParametersReg" numbered="true" toc="default">
<section anchor="TokenTypeReg" title='OAuth Access Token Type Registration <name>OAuth Parameters Registration</name>
'>
<t> <t>
This specification registers the following access token type IANA has registered the following values
in the IANA "OAuth Access Token Types" registry in the "OAuth Parameters" subregistry of the "OAuth Parameters" registr
<xref target="IANA.OAuth.Parameters"/> y
established by <xref target="RFC6749"/>. <xref target="IANA.OAuth.Parameters" format="default"/>. The "OAuth Par
ameters"
subregistry was
established by <xref target="RFC6749" format="default"/>.
</t> </t>
<section anchor="TokenTypeContents" title='Registry Contents'> <ul spacing="compact">
<li>Parameter name: audience</li>
<t> <li>Parameter usage location: token request</li>
<?rfc subcompact="yes"?> <li>Change controller: IESG</li>
<list style='symbols'> <li>Specification document(s): <xref target="Request" format="default"
<t>Type name: N_A</t> /> of RFC 8693</li>
<t>Additional Token Endpoint Response Parameters: (none)</t> </ul>
<t>HTTP Authentication Scheme(s): (none)</t> <ul spacing="compact">
<t>Change controller: IESG</t> <li>Parameter name: requested_token_type</li>
<t>Specification document(s): <xref target="SuccessfulResponse"/> <li>Parameter usage location: token request</li>
of [[ this specification ]]</t> <li>Change controller: IESG</li>
</list> <li>Specification document(s): <xref target="Request" format="default"
</t> /> of RFC 8693</li>
<?rfc subcompact="no"?> </ul>
<ul spacing="compact">
</section> <li>Parameter name: subject_token</li>
<li>Parameter usage location: token request</li>
<li>Change controller: IESG</li>
<li>Specification document(s): <xref target="Request" format="default"
/> of RFC 8693</li>
</ul>
<ul spacing="compact">
<li>Parameter name: subject_token_type</li>
<li>Parameter usage location: token request</li>
<li>Change controller: IESG</li>
<li>Specification document(s): <xref target="Request" format="default"
/> of RFC 8693</li>
</ul>
<ul spacing="compact">
<li>Parameter name: actor_token</li>
<li>Parameter usage location: token request</li>
<li>Change controller: IESG</li>
<li>Specification document(s): <xref target="Request" format="default"
/> of RFC 8693</li>
</ul>
<ul spacing="compact">
<li>Parameter name: actor_token_type</li>
<li>Parameter usage location: token request</li>
<li>Change controller: IESG</li>
<li>Specification document(s): <xref target="Request" format="default"
/> of RFC 8693</li>
</ul>
<ul spacing="compact">
<li>Parameter name: issued_token_type</li>
<li>Parameter usage location: token response</li>
<li>Change controller: IESG</li>
<li>Specification document(s): <xref target="SuccessfulResponse" forma
t="default"/> of RFC 8693</li>
</ul>
</section> </section>
<section anchor="TokenTypeReg" numbered="true" toc="default">
<section anchor="ClaimsReg" title="JSON Web Token Claims Registration"> <name>OAuth Access Token Type Registration</name>
<t>
<t> IANA has registered the following access token type
This specification registers the following Claims in the "OAuth Access Token Types" subregistry of the "OAuth
in the IANA "JSON Web Token Claims" registry Parameters" registry
<xref target="IANA.JWT.Claims"/> <xref target="IANA.OAuth.Parameters" format="default"/>. The "OAuth Acc
established by <xref target="JWT"/>. ess Token
</t> Types" subregistry was
established by <xref target="RFC6749" format="default"/>.
<section anchor='ClaimsContents' title='Registry Contents'> </t>
<ul spacing="compact">
<t> <li>Type name: N_A</li>
<?rfc subcompact="yes"?> <li>Additional Token Endpoint Response Parameters: none</li>
<list style='symbols'> <li>HTTP Authentication Scheme(s): none</li>
<t>Claim Name: <spanx style="verb">act</spanx></t> <li>Change controller: IESG</li>
<t>Claim Description: Actor</t> <li>Specification document(s): <xref target="SuccessfulResponse" forma
<t>Change Controller: IESG</t> t="default"/> of RFC 8693</li>
<t>Specification Document(s): <xref target="actor"/> of [[ this spe </ul>
cification ]]</t>
</list>
</t>
<t>
<list style='symbols'>
<t>Claim Name: <spanx style="verb">scope</spanx></t>
<t>Claim Description: Scope Values</t>
<t>Change Controller: IESG</t>
<t>Specification Document(s): <xref target="scopes"/> of [[ this sp
ecification ]]</t>
</list>
</t>
<t>
<list style='symbols'>
<t>Claim Name: <spanx style="verb">client_id</spanx></t>
<t>Claim Description: Client Identifier</t>
<t>Change Controller: IESG</t>
<t>Specification Document(s): <xref target="client_id"/> of [[ this spec
ification ]]</t>
</list>
</t>
<t>
<list style='symbols'>
<t>Claim Name: <spanx style="verb">may_act</spanx></t>
<t>Claim Description: Authorized Actor - the party that is authorized to
become the actor</t>
<t>Change Controller: IESG</t>
<t>Specification Document(s): <xref target="may_act"/> of [[ this specif
ication ]]</t>
</list>
</t>
<?rfc subcompact="no"?>
</section>
</section> </section>
<section anchor="ClaimsReg" numbered="true" toc="default">
<section anchor="IntrospectionReg" title="OAuth Token Introspection Respon <name>JSON Web Token Claims Registration</name>
se Registration">
<t> <t>
This specification registers the following values IANA has registered the following Claims
in the IANA "OAuth Token Introspection Response" registry in the "JSON Web Token Claims" subregistry of the "JSON Web Token
<xref target="IANA.OAuth.Parameters"/> (JWT)" registry
established by <xref target="RFC7662"/>. <xref target="IANA.JWT" format="default"/>. The "JSON Web Token Claims"
subregistry was
established by <xref target="RFC7519" format="default"/>.
</t> </t>
<ul spacing="compact">
<section anchor='IntrospectionContents' title='Registry Contents'> <li>Claim Name: act</li>
<li>Claim Description: Actor</li>
<t> <li>Change Controller: IESG</li>
<?rfc subcompact="yes"?> <li>Specification Document(s): <xref target="actor" format="default"/>
<list style='symbols'> of RFC 8693</li>
<t>Claim Name: <spanx style="verb">act</spanx></t> </ul>
<t>Claim Description: Actor</t> <ul spacing="compact">
<t>Change Controller: IESG</t> <li>Claim Name: scope</li>
<t>Specification Document(s): <xref target="actor"/> of [[ this sp <li>Claim Description: Scope Values</li>
ecification ]]</t> <li>Change Controller: IESG</li>
</list> <li>Specification Document(s): <xref target="scopes" format="default"/
</t> > of RFC 8693</li>
<t> </ul>
<list style='symbols'> <ul spacing="compact">
<t>Claim Name: <spanx style="verb">may_act</spanx></t> <li>Claim Name: client_id</li>
<t>Claim Description: Authorized Actor - the party that is authori <li>Claim Description: Client Identifier</li>
zed to become the actor</t> <li>Change Controller: IESG</li>
<t>Change Controller: IESG</t> <li>Specification Document(s): <xref target="client_id" format="defaul
<t>Specification Document(s): <xref target="may_act"/> of [[ this t"/> of RFC 8693</li>
specification ]]</t> </ul>
</list> <ul spacing="compact">
</t> <li>Claim Name: may_act</li>
<?rfc subcompact="no"?> <li>Claim Description: Authorized Actor - the party that is authorized
to become the actor</li>
</section> <li>Change Controller: IESG</li>
<li>Specification Document(s): <xref target="may_act" format="default"
/> of RFC 8693</li>
</ul>
</section> </section>
<section anchor="IntrospectionReg" numbered="true" toc="default">
<section anchor="ErrorReg" title="OAuth Extensions Error Registration"> <name>OAuth Token Introspection Response Registration</name>
<t> <t>
This specification registers the following values IANA has registered the following values
in the IANA "OAuth Extensions Error" registry in the "OAuth Token Introspection Response" registry of the "OAuth
<xref target="IANA.OAuth.Parameters"/> Parameters" registry
established by <xref target="RFC6749"/>. <xref target="IANA.OAuth.Parameters" format="default"/>. The "OAuth To
ken
Introspection Response" registry was
established by <xref target="RFC7662" format="default"/>.
</t> </t>
<ul spacing="compact">
<section anchor='ErrorContents' title='Registry Contents'> <li>Name: act</li>
<li>Description: Actor</li>
<t> <li>Change Controller: IESG</li>
<?rfc subcompact="yes"?> <li>Specification Document(s): <xref target="actor" format="default"/>
<list style='symbols'> of RFC 8693</li>
<t>Error Name: <spanx style="verb">invalid_target</spanx></t> </ul>
<t>Error Usage Location: token error response</t> <ul spacing="compact">
<t>Related Protocol Extension: OAuth 2.0 Token Exchange</t> <li>Name: may_act</li>
<t>Change Controller: IETF</t> <li>Description: Authorized Actor - the party that is authorized to be
<t>Specification Document(s): <xref target="ErrorResponse"/> of [[ come the actor</li>
this specification ]]</t> <li>Change Controller: IESG</li>
</list> <li>Specification Document(s): <xref target="may_act" format="default"
</t> /> of RFC 8693</li>
<?rfc subcompact="no"?> </ul>
</section>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.6749.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.3986.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.8259.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.7662.xml' ?>
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"?>
<reference anchor='JWT' target='https://www.rfc-editor.org/info/rfc7519'> <displayreference target="RFC7519" to="JWT"/>
<front>
<title>JSON Web Token (JWT)</title>
<author initials='M.' surname='Jones' fullname='M. Jones'><organization /></auth
or>
<author initials='J.' surname='Bradley' fullname='J. Bradley'><organization /></
author>
<author initials='N.' surname='Sakimura' fullname='N. Sakimura'><organization />
</author>
<date year='2015' month='May' />
<abstract><t>JSON Web Token (JWT) is a compact, URL-safe means of representing c
laims to be transferred between two parties. The claims in a JWT are encoded as
a JSON object that is used as the payload of a JSON Web Signature (JWS) structu
re or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the cl
aims to be digitally signed or integrity protected with a Message Authentication
Code (MAC) and/or encrypted.</t></abstract>
</front>
<seriesInfo name='RFC' value='7519'/>
<seriesInfo name='DOI' value='10.17487/RFC7519'/>
</reference>
<!-- [rfced] [IANA.JWT.Claims] This URL is correct -->
<reference anchor="IANA.JWT.Claims" target="http://www.iana.org/assignment
s/jwt">
<front>
<title>JSON Web Token Claims</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
<!-- [rfced] [IANA.OAuth.Parameters] This URL is correct -->
<reference anchor="IANA.OAuth.Parameters" target="http://www.iana.org/assi
gnments/oauth-parameters">
<front>
<title>OAuth Parameters</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
</references>
<references title="Informative References">
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.6755.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.6750.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.7521.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.7523.xml' ?>
<?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.R
FC.6819.xml' ?>
<!-- <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I
-D.ietf-oauth-security-topics.xml'?>; I-D Exists -->
<reference anchor='OAUTH-SECURITY'>
<front>
<title>OAuth 2.0 Security Best Current Practice</title>
<author initials='T' surname='Lodderstedt' fullname='Torsten Lodderstedt'>
<organization />
</author>
<author initials='J' surname='Bradley' fullname='John Bradley'>
<organization />
</author>
<author initials='A' surname='Labunets' fullname='Andrey Labunets'>
<organization />
</author>
<author initials='D' surname='Fett' fullname='Daniel Fett'>
<organization />
</author>
<date month='July' day='8' year='2019' />
<abstract><t>This document describes best current security practice for OAuth 2.
0. It updates and extends the OAuth 2.0 Security Threat Model to incorporate pra
ctical experiences gathered since OAuth 2.0 was published and covers new threats
relevant due to the broader application of OAuth 2.0.</t></abstract>
</front>
<seriesInfo name='Work in Progress,' value='draft-ietf-oauth-security-topics-13'
/>
</reference>
<!-- <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I
-D.ietf-oauth-resource-indicators.xml'?>; Waiting for Writeup -->
<reference anchor='OAUTH-RESOURCE'>
<front>
<title>Resource Indicators for OAuth 2.0</title>
<author initials='B' surname='Campbell' fullname='Brian Campbell'>
<organization />
</author>
<author initials='J' surname='Bradley' fullname='John Bradley'>
<organization />
</author>
<author initials='H' surname='Tschofenig' fullname='Hannes Tschofenig'>
<organization />
</author>
<date month='July' day='24' year='2019' /> <displayreference target="I-D.ietf-oauth-security-topics" to="OAUTH-SECURITY"/>
<abstract><t>An extension to the OAuth 2.0 Authorization Framework defining requ est parameters that enable a client to explicitly signal to an authorization ser ver about the identity of the protected resource(s) to which it is requesting ac cess.</t></abstract> <displayreference target="I-D.ietf-oauth-resource-indicators" to="OAUTH-RESOURCE "/>
</front> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6749.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.3986.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8259.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7662.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7519.xml"/>
<reference anchor="IANA.JWT" target="https://www.iana.org/assignments/jw
t">
<front>
<title>JSON Web Token (JWT)</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
<reference anchor="IANA.OAuth.Parameters" target="https://www.iana.org/a
ssignments/oauth-parameters">
<front>
<title>OAuth Parameters</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6755.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6750.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7521.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7523.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.6819.xml"/>
<seriesInfo name='Work in Progress,' value='draft-ietf-oauth-resource-indicators <!-- I-D.ietf-oauth-security-topics; I-D Exists -->
-05' /> <xi:include
</reference> href="https://www.rfc-editor.org/refs/bibxml3/reference.I-D.ietf-oauth-secur
ity-topics.xml"/>
<!-- <?rfc include='http://xml2rfc.tools.ietf.org/public/rfc/bibxml2/reference.O <!-- < I-D.ietf-oauth-resource-indicators; RFC-EDITOR state -->
ASIS.saml-core-2.0-os.xml' ?>; inserted full entry from http://xml2rfc.tools.iet <xi:include
f.org/public/rfc/bibxml2/reference.OASIS.saml-core-2.0-os.xml --> href="https://www.rfc-editor.org/refs/bibxml3/reference.I-D.ietf-oauth-resou
rce-indicators.xml"/>
<reference anchor="OASIS.saml-core-2.0-os"> <reference anchor="OASIS.saml-core-2.0-os" target="http://docs.oasis-ope
<front> n.org/security/saml/v2.0/saml-core-2.0-os.pdf">
<title>Assertions and Protocol for the OASIS Security Assertion Markup L <front>
anguage (SAML) V2.0</title> <title>Assertions and Protocol for the OASIS Security Assertion Mark
<author fullname="Scott Cantor" initials="S." surname="Cantor"> up Language (SAML) V2.0</title>
<organization>Internet2</organization> <seriesInfo name="OASIS Standard" value="saml-core-2.0-os"/>
<address> <author fullname="Scott Cantor" initials="S." surname="Cantor">
<organization>Internet2</organization>
<address>
<email>cantor.2@osu.edu</email> <email>cantor.2@osu.edu</email>
</address> </address>
</author> </author>
<author fullname="John Kemp" initials="J." surname="Kemp"> <author fullname="John Kemp" initials="J." surname="Kemp">
<organization>Nokia</organization> <organization>Nokia</organization>
<address> <address>
<email>John.Kemp@nokia.com</email> <email>John.Kemp@nokia.com</email>
</address> </address>
</author> </author>
<author fullname="Rob Philpott" initials="R." surname="Philpott"> <author fullname="Rob Philpott" initials="R." surname="Philpott">
<organization>RSA Security</organization> <organization>RSA Security</organization>
<address> <address>
<email>rphilpott@rsasecurity.com</email> <email>rphilpott@rsasecurity.com</email>
</address> </address>
</author> </author>
<author fullname="Eve Maler" initials="E." surname="Maler"> <author fullname="Eve Maler" initials="E." surname="Maler">
<organization>Sun Microsystems</organization> <organization>Sun Microsystems</organization>
<address> <address>
<email>eve.maler@sun.com</email> <email>eve.maler@sun.com</email>
</address> </address>
</author> </author>
<date year="2005" month="March"/> <date year="2005" month="March"/>
</front> </front>
<seriesInfo name="OASIS Standard" value="saml-core-2.0-os"/> </reference>
<format type="PDF" target="http://docs.oasis-open.org/security/saml/v2.0/sam <reference anchor="OASIS.saml-core-1.1" target="https://www.oasis-open.o
l-core-2.0-os.pdf"/> rg/committees/download.php/3406/oasis-sstc-saml-core-1.1.pdf">
</reference> <front>
<title>Assertions and Protocol for the OASIS Security Assertion Mark
<!-- [rfced] [OASIS.saml-core-1.1] This URL is correct --> up Language
<reference anchor="OASIS.saml-core-1.1">
<front>
<title>Assertions and Protocol for the OASIS Security Assertion Markup
Language
(SAML) V1.1</title> (SAML) V1.1</title>
<author fullname="Eve Maler" initials="E." surname="Maler"> <seriesInfo name="OASIS Standard" value="oasis-sstc-saml-core-1.1"/>
<organization>Sun Microsystems</organization> <author fullname="Eve Maler" initials="E." surname="Maler">
<address> <organization>Sun Microsystems</organization>
<email>eve.maler@sun.com</email> <address>
</address> <email>eve.maler@sun.com</email>
</author> </address>
<author fullname="Prateek Mishra" initials="P." surname="Mishra"> </author>
<organization>Netegrity, Inc.</organization> <author fullname="Prateek Mishra" initials="P." surname="Mishra">
<address> <organization>Netegrity, Inc.</organization>
<email>pmishra@netegrity.com</email> <address>
</address> <email>pmishra@netegrity.com</email>
</author> </address>
<author fullname="Rob Philpott" initials="R." surname="Philpott"> </author>
<organization>RSA Security</organization> <author fullname="Rob Philpott" initials="R." surname="Philpott">
<address> <organization>RSA Security</organization>
<email>rphilpott@rsasecurity.com</email> <address>
</address> <email>rphilpott@rsasecurity.com</email>
</author> </address>
<date year="2003" month="September" day="2"/> </author>
</front> <date year="2003" month="September"/>
<seriesInfo name="OASIS Standard" value="oasis-sstc-saml-core-1.1"/> </front>
<format type="PDF" target="https://www.oasis-open.org/committees/download </reference>
.php/3406/oasis-sstc-saml-core-1.1.pdf"/> <reference anchor="WS-Trust" target="https://docs.oasis-open.org/ws-sx/w
</reference> s-trust/v1.4/ws-trust.html">
<front>
<!-- [rfced] [WS-Trust] This URL is correct --> <title>WS-Trust 1.4</title>
<author fullname="Anthony Nadalin" initials="A." surname="Nadalin" r
<reference anchor="WS-Trust" target="http://docs.oasis-open.org/ws-sx/ws-t ole="editor"/>
rust/v1.4/ws-trust.html"> <author fullname="Marc Goodner" initials="M." surname="Goodner" role
<front> ="editor"/>
<title>WS-Trust 1.4</title> <author fullname="Martin Gudgin" initials="M." surname="Gudgin" role
<author fullname="Anthony Nadalin" initials="A." surname="Nadalin"/> ="editor"/>
<author fullname="Marc Goodner" initials="M." surname="Goodner"/> <author fullname="Abbie Barbir" initials="A." surname="Barbir" role=
<author fullname="Martin Gudgin" initials="M." surname="Gudgin"/> "editor"/>
<author fullname="Abbie Barbir" initials="A." surname="Barbir"/> <author fullname="Hans Granqvist" initials="H." surname="Granqvist"
<author fullname="Hans Granqvist" initials="H." surname="Granqvist"/> role="editor"/>
<date day="2" month="February" year="2012"/> <date month="February" year="2012"/>
</front> </front>
</reference> </reference>
<reference anchor="OpenID.Core" target="https://openid.net/specs/openid-
<!-- <?rfc include='http://openid.net/bibxml/reference.OpenID.Core.xml' ?>; inse connect-core-1_0.html">
rted full entry from http://openid.net/bibxml/reference.OpenID.Core.xml --> <front>
<title abbrev="OpenID Connect Core 1.0">OpenID Connect Core 1.0</tit
<reference anchor="OpenID.Core" le>
target="http://openid.net/specs/openid-connect-core-1_0.html"> <author fullname="Nat Sakimura" initials="N." surname="Sakimura">
<front> <organization abbrev="NRI">Nomura Research Institute, Ltd.</organi
<title abbrev="OpenID Connect Core 1.0">OpenID Connect Core 1.0</title> zation>
<address>
<author fullname="Nat Sakimura" initials="N." surname="Sakimura"> <email>n-sakimura@nri.co.jp</email>
<organization abbrev="NRI">Nomura Research Institute, Ltd.</organization> <uri>https://nat.sakimura.org/</uri>
<address> </address>
<email>n-sakimura@nri.co.jp</email> </author>
<uri>http://nat.sakimura.org/</uri> <author fullname="John Bradley" initials="J." surname="Bradley">
</address> <organization abbrev="Ping Identity">Ping Identity</organization>
</author> <address>
<email>ve7jtb@ve7jtb.com</email>
<author fullname="John Bradley" initials="J." surname="Bradley"> <uri>http://www.thread-safe.com/</uri>
<organization abbrev="Ping Identity">Ping Identity</organization> </address>
<address> </author>
<email>ve7jtb@ve7jtb.com</email> <author fullname="Michael B. Jones" initials="M." surname="Jones">
<uri>http://www.thread-safe.com/</uri> <organization abbrev="Microsoft">Microsoft</organization>
</address> <address>
</author> <email>mbj@microsoft.com</email>
<uri>https://self-issued.info/</uri>
<author fullname="Michael B. Jones" initials="M.B." surname="Jones"> </address>
<organization abbrev="Microsoft">Microsoft</organization> </author>
<address> <author fullname="Breno de Medeiros" initials="B." surname="de Medei
<email>mbj@microsoft.com</email> ros">
<uri>http://self-issued.info/</uri> <organization abbrev="Google">Google</organization>
</address> <address>
</author> <email>breno@google.com</email>
<uri>https://stackoverflow.com/users/311376/breno</uri>
<author fullname="Breno de Medeiros" initials="B." surname="de Medeiros"> </address>
<organization abbrev="Google">Google</organization> </author>
<address> <author fullname="Chuck Mortimore" initials="C." surname="Mortimore"
<email>breno@google.com</email> >
<uri>http://stackoverflow.com/users/311376/breno</uri> <organization abbrev="Visa">Visa</organization>
</address> <address>
</author> <email>chuck.mortimore@visa.com</email>
<uri>https://twitter.com/cmort</uri>
<author fullname="Chuck Mortimore" initials="C." surname="Mortimore"> </address>
<organization abbrev="Salesforce">Salesforce</organization> </author>
<address> <date month="November" year="2014"/>
<email>cmortimore@salesforce.com</email> <workgroup>OpenID Connect Working Group</workgroup>
<uri>https://twitter.com/cmort</uri> </front>
</address> </reference>
</author> </references>
<date day="8" month="November" year="2014" />
<workgroup>OpenID Connect Working Group</workgroup>
<abstract>
<t>OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0
protocol. It enables Clients to verify the identity of the End-User based
on the authentication performed by an Authorization Server, as well as to
obtain basic profile information about the End-User in an interoperable an
d
REST-like manner.</t>
<t>
This specification defines the core OpenID Connect functionality:
authentication built on top of OAuth 2.0 and
the use of Claims to communicate information about the End-User.
It also describes the security and privacy considerations for using OpenID
Connect.
</t>
</abstract>
</front>
</reference>
</references> </references>
<section anchor="AdditionalExamples" numbered="true" toc="default">
<section title="Additional Token Exchange Examples" anchor="AdditionalExamples <name>Additional Token Exchange Examples</name>
"> <t>
<t>
Two example token exchanges are provided in the following sections Two example token exchanges are provided in the following sections
illustrating impersonation and delegation, respectively illustrating impersonation and delegation, respectively
(with extra line breaks and indentation for display purposes only). (with extra line breaks and indentation for display purposes only).
</t> </t>
<section title="Impersonation Token Exchange Example" anchor="ImpersonationExa <section anchor="ImpersonationExample" numbered="true" toc="default">
mple"> <name>Impersonation Token Exchange Example</name>
<section anchor="ImpersonationRequest" numbered="true" toc="default">
<section anchor="ImpersonationRequest" title="Token Exchange Request"> <name>Token Exchange Request</name>
<t> <t>
In the following token exchange request, a client is requesting a token In the following token exchange request, a client is requesting a token
with impersonation semantics (with only a <spanx style="verb">subject_to with impersonation semantics (delegation is impossible with only a <tt>s
ken</spanx> ubject_token</tt>
and no <spanx style="verb">actor_token</spanx>, delegation is impossible and no <tt>actor_token</tt>).
).
The client tells the authorization server that it needs a token for use at The client tells the authorization server that it needs a token for use at
the target service with the logical name the target service with the logical name
<spanx style="verb">urn:example:cooperation-context</spanx>. <tt>urn:example:cooperation-context</tt>.
</t> </t>
<figure title="Token Exchange Request" anchor="ImpersonationRequestEx"> <figure anchor="ImpersonationRequestEx">
<artwork><![CDATA[ <name>Token Exchange Request</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
POST /as/token.oauth2 HTTP/1.1 POST /as/token.oauth2 HTTP/1.1
Host: as.example.com Host: as.example.com
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&audience=urn%3Aexample%3Acooperation-context &audience=urn%3Aexample%3Acooperation-context
&subject_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwc &subject_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwc
zovL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXI zovL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXI
uZXhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTA2MDAsIm5iZiI6MTQ0MTkwOTAwMCwic uZXhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTA2MDAsIm5iZiI6MTQ0MTkwOTAwMCwic
3ViIjoiYmRjQGV4YW1wbGUubmV0Iiwic2NvcGUiOiJvcmRlcnMgcHJvZmlsZSBoaXN 3ViIjoiYmRjQGV4YW1wbGUubmV0Iiwic2NvcGUiOiJvcmRlcnMgcHJvZmlsZSBoaXN
0b3J5In0.PRBg-jXn4cJuj1gmYXFiGkZzRuzbXZ_sDxdE98ddW44ufsbWLKd3JJ1VZ 0b3J5In0.PRBg-jXn4cJuj1gmYXFiGkZzRuzbXZ_sDxdE98ddW44ufsbWLKd3JJ1VZ
hF64pbTtfjy4VXFVBDaQpKjn5JzAw hF64pbTtfjy4VXFVBDaQpKjn5JzAw
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt &subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt
]]></artwork> ]]></artwork>
</figure> </figure>
<!-- JWT signing key for example.net </section>
{"kty":"EC","kid":"16","use":"sig","alg":"ES256", <section anchor="ImpersonationSubjectClaims" numbered="true" toc="defaul
"x":"N_MqlYd_Iq0rfzTqXAX7TUC0r7fQSp3YQKh42tn7uSc", t">
"y":"9tGuwMFkHYWPqkLa51f8GazZNQqdgMOVvJEd6fJ18PI", <name>Subject Token Claims</name>
"crv":"P-256", <t>
"d":"cZ_4DqRSAWMMErQbKv6dCYqI9G1pi6lxvlvHU152Uts"} The <tt>subject_token</tt> in the prior request is a JWT, and
-->
</section>
<section anchor="ImpersonationSubjectClaims" title="Subject Token Claims">
<t>
The <spanx style="verb">subject_token</spanx> in the prior request is a JWT an
d
the decoded JWT Claims Set is shown here. The JWT is the decoded JWT Claims Set is shown here. The JWT is
intended for consumption by the authorization server within a specific time wi ndow. intended for consumption by the authorization server within a specific time wi ndow.
The subject of the JWT (<spanx style="verb">bdc@example.net</spanx>) is The subject of the JWT (<tt>bdc@example.net</tt>) is
the party on behalf of whom the new token is being requested. the party on behalf of whom the new token is being requested.
</t> </t>
<figure title="Subject Token Claims" anchor="ImpersonationSubjectClaimsEx"> <figure anchor="ImpersonationSubjectClaimsEx">
<artwork><![CDATA[ <name>Subject Token Claims</name>
<sourcecode type="json"><![CDATA[
{ {
"aud":"https://as.example.com", "aud":"https://as.example.com",
"iss":"https://original-issuer.example.net", "iss":"https://original-issuer.example.net",
"exp":1441910600, "exp":1441910600,
"nbf":1441909000, "nbf":1441909000,
"sub":"bdc@example.net", "sub":"bdc@example.net",
"scope":"orders profile history" "scope":"orders profile history"
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="ImpersonationResponse" numbered="true" toc="default">
<section anchor="ImpersonationResponse" title="Token Exchange Response"> <name>Token Exchange Response</name>
<t> <t>
The <spanx style="verb">access_token</spanx> parameter of the token exchange The <tt>access_token</tt> parameter of the token exchange
response shown below contains the new token that the client requested. response shown below contains the new token that the client requested.
The other parameters of the response indicate that the token is a bearer acces s token The other parameters of the response indicate that the token is a bearer acces s token
that expires in an hour. that expires in an hour.
</t> </t>
<figure title="Token Exchange Response" anchor="ImpersonationResponseEx"> <figure anchor="ImpersonationResponseEx">
<artwork><![CDATA[ <name>Token Exchange Response</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/json Content-Type: application/json
Cache-Control: no-cache, no-store Cache-Control: no-cache, no-store
{ {
"access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjcyIn0.eyJhdWQiOiJ1cm4 "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjcyIn0.eyJhdWQiOiJ1cm4
6ZXhhbXBsZTpjb29wZXJhdGlvbi1jb250ZXh0IiwiaXNzIjoiaHR0cHM6Ly9hcy5l 6ZXhhbXBsZTpjb29wZXJhdGlvbi1jb250ZXh0IiwiaXNzIjoiaHR0cHM6Ly9hcy5l
eGFtcGxlLmNvbSIsImV4cCI6MTQ0MTkxMzYxMCwic3ViIjoiYmRjQGV4YW1wbGUub eGFtcGxlLmNvbSIsImV4cCI6MTQ0MTkxMzYxMCwic3ViIjoiYmRjQGV4YW1wbGUub
mV0Iiwic2NvcGUiOiJvcmRlcnMgcHJvZmlsZSBoaXN0b3J5In0.rMdWpSGNACTvnF mV0Iiwic2NvcGUiOiJvcmRlcnMgcHJvZmlsZSBoaXN0b3J5In0.rMdWpSGNACTvnF
uOL74sYZ6MVuld2Z2WkGLmQeR9ztj6w2OXraQlkJmGjyiCq24kcB7AI2VqVxl3wSW uOL74sYZ6MVuld2Z2WkGLmQeR9ztj6w2OXraQlkJmGjyiCq24kcB7AI2VqVxl3wSW
nVKh85A", nVKh85A",
"issued_token_type": "issued_token_type":
"urn:ietf:params:oauth:token-type:access_token", "urn:ietf:params:oauth:token-type:access_token",
"token_type":"Bearer", "token_type":"Bearer",
"expires_in":3600 "expires_in":3600
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<!-- JWT signing key for example.com </section>
{"kty":"EC","kid":"72","use":"sig","alg":"ES256", <section anchor="ImpersonationIssuedClaims" numbered="true" toc="default
"x":"472aI8TvDdm2qfBRpXYw0uZ7feumuQOM-RPRkkTukSo", ">
"y":"VNNStdPhuxY6q7XfVIeYSW7xh_a4z5W2MCtNmQDcILc", <name>Issued Token Claims</name>
"crv":"P-256", <t>
"d":"dtJiut8QBJxACG6fcX8NYnzIsAN1muCJvaMiLSrOjIc"}
-->
</section>
<section anchor="ImpersonationIssuedClaims" title="Issued Token Claims">
<t>
The decoded JWT Claims Set of the issued token is shown below. The new JWT is The decoded JWT Claims Set of the issued token is shown below. The new JWT is
issued by the authorization server and intended for consumption by a system en tity issued by the authorization server and intended for consumption by a system en tity
known by the logical name <spanx style="verb">urn:example:cooperation-context< /spanx> known by the logical name <tt>urn:example:cooperation-context</tt>
any time before its expiration. any time before its expiration.
The subject (<spanx style="verb">sub</spanx>) of the JWT The subject (<tt>sub</tt>) of the JWT
is the same as the subject the token used to make the request, is the same as the subject the token used to make the request,
which effectively enables the client to impersonate that subject which effectively enables the client to impersonate that subject
at the system entity known by the logical name of at the system entity known by the logical name of
<spanx style="verb">urn:example:cooperation-context</spanx> by using the token . <tt>urn:example:cooperation-context</tt> by using the token.
</t> </t>
<figure anchor="ImpersonationIssuedClaimsEx" title="Issued Token Claims"> <figure anchor="ImpersonationIssuedClaimsEx">
<artwork><![CDATA[ <name>Issued Token Claims</name>
<sourcecode type="json"><![CDATA[
{ {
"aud":"urn:example:cooperation-context", "aud":"urn:example:cooperation-context",
"iss":"https://as.example.com", "iss":"https://as.example.com",
"exp":1441913610, "exp":1441913610,
"sub":"bdc@example.net", "sub":"bdc@example.net",
"scope":"orders profile history" "scope":"orders profile history"
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section>
</section> </section>
</section> <section anchor="DelegationExample" numbered="true" toc="default">
<name>Delegation Token Exchange Example</name>
<section title="Delegation Token Exchange Example" anchor="DelegationExample"> <section anchor="DelegationRequest" numbered="true" toc="default">
<name>Token Exchange Request</name>
<section anchor="DelegationRequest" title="Token Exchange Request"> <t>
<t>
In the following token exchange request, a client is requesting a token In the following token exchange request, a client is requesting a token
and providing both a <spanx style="verb">subject_token</spanx> and an <s panx style="verb">actor_token</spanx>. and providing both a <tt>subject_token</tt> and an <tt>actor_token</tt>.
The client tells the authorization server that it needs a token for use at The client tells the authorization server that it needs a token for use at
the target service with the logical name the target service with the logical name
<spanx style="verb">urn:example:cooperation-context</spanx>. Policy at th e <tt>urn:example:cooperation-context</tt>. Policy at the
authorization server dictates that the issued token be a composite. authorization server dictates that the issued token be a composite.
</t> </t>
<figure anchor="DelegationRequestEx" title="Token Exchange Request"> <figure anchor="DelegationRequestEx">
<artwork><![CDATA[ <name>Token Exchange Request</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
POST /as/token.oauth2 HTTP/1.1 POST /as/token.oauth2 HTTP/1.1
Host: as.example.com Host: as.example.com
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&audience=urn%3Aexample%3Acooperation-context &audience=urn%3Aexample%3Acooperation-context
&subject_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwc &subject_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwc
zovL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXI zovL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXI
uZXhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTAwNjAsInNjb3BlIjoic3RhdHVzIGZlZ uZXhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTAwNjAsInNjb3BlIjoic3RhdHVzIGZlZ
WQiLCJzdWIiOiJ1c2VyQGV4YW1wbGUubmV0IiwibWF5X2FjdCI6eyJzdWIiOiJhZG1 WQiLCJzdWIiOiJ1c2VyQGV4YW1wbGUubmV0IiwibWF5X2FjdCI6eyJzdWIiOiJhZG1
pbkBleGFtcGxlLm5ldCJ9fQ.4rPRSWihQbpMIgAmAoqaJojAxj-p2X8_fAtAGTXrvM pbkBleGFtcGxlLm5ldCJ9fQ.4rPRSWihQbpMIgAmAoqaJojAxj-p2X8_fAtAGTXrvM
xU-eEZHnXqY0_AOZgLdxw5DyLzua8H_I10MCcckF-Q_g xU-eEZHnXqY0_AOZgLdxw5DyLzua8H_I10MCcckF-Q_g
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt &subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt
&actor_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwczo &actor_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwczo
vL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXIuZ vL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXIuZ
XhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTAwNjAsInN1YiI6ImFkbWluQGV4YW1wbGU XhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTAwNjAsInN1YiI6ImFkbWluQGV4YW1wbGU
ubmV0In0.7YQ-3zPfhUvzje5oqw8COCvN5uP6NsKik9CVV6cAOf4QKgM-tKfiOwcgZ ubmV0In0.7YQ-3zPfhUvzje5oqw8COCvN5uP6NsKik9CVV6cAOf4QKgM-tKfiOwcgZ
oUuDL2tEs6tqPlcBlMjiSzEjm3yBg oUuDL2tEs6tqPlcBlMjiSzEjm3yBg
&actor_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt &actor_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt
]]></artwork> ]]></artwork>
</figure> </figure>
<!-- JWT signing key for example.net </section>
{"kty":"EC","kid":"16","use":"sig","alg":"ES256", <section anchor="DelegationSubjectClaims" numbered="true" toc="default">
"x":"N_MqlYd_Iq0rfzTqXAX7TUC0r7fQSp3YQKh42tn7uSc", <name>Subject Token Claims</name>
"y":"9tGuwMFkHYWPqkLa51f8GazZNQqdgMOVvJEd6fJ18PI", <t>
"crv":"P-256", The <tt>subject_token</tt> in the prior request is a JWT, and
"d":"cZ_4DqRSAWMMErQbKv6dCYqI9G1pi6lxvlvHU152Uts"}
-->
</section>
<section anchor="DelegationSubjectClaims" title="Subject Token Claims">
<t>
The <spanx style="verb">subject_token</spanx> in the prior request is a
JWT and
the decoded JWT Claims Set is shown here. The JWT is the decoded JWT Claims Set is shown here. The JWT is
intended for consumption by the authorization server intended for consumption by the authorization server
before a specific expiration time. before a specific expiration time.
The subject of the JWT The subject of the JWT
(<spanx style="verb">user@example.net</spanx>) is (<tt>user@example.net</tt>) is
the party on behalf of whom the new token is being requested. the party on behalf of whom the new token is being requested.
</t> </t>
<figure anchor="DelegationSubjectClaimsEx" title="Subject Token Claims"> <figure anchor="DelegationSubjectClaimsEx">
<artwork><![CDATA[ <name>Subject Token Claims</name>
<sourcecode type="json"><![CDATA[
{ {
"aud":"https://as.example.com", "aud":"https://as.example.com",
"iss":"https://original-issuer.example.net", "iss":"https://original-issuer.example.net",
"exp":1441910060, "exp":1441910060,
"scope":"status feed", "scope":"status feed",
"sub":"user@example.net", "sub":"user@example.net",
"may_act": "may_act":
{ {
"sub":"admin@example.net" "sub":"admin@example.net"
} }
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="DelegationActorClaims" numbered="true" toc="default">
<section anchor="DelegationActorClaims" title="Actor Token Claims"> <name>Actor Token Claims</name>
<t> <t>
The <spanx style="verb">actor_token</spanx> in the prior request is a JW The <tt>actor_token</tt> in the prior request is a JWT, and
T and
the decoded JWT Claims Set is shown here. This JWT is also the decoded JWT Claims Set is shown here. This JWT is also
intended for consumption by the authorization server intended for consumption by the authorization server
before a specific expiration time. before a specific expiration time.
The subject of the JWT The subject of the JWT
(<spanx style="verb">admin@example.net</spanx>) is (<tt>admin@example.net</tt>) is
the actor that will wield the security token being requested. the actor that will wield the security token being requested.
</t> </t>
<figure anchor="DelegationActorClaimsEx" title="Actor Token Claims"> <figure anchor="DelegationActorClaimsEx">
<artwork><![CDATA[ <name>Actor Token Claims</name>
<sourcecode type="json"><![CDATA[
{ {
"aud":"https://as.example.com", "aud":"https://as.example.com",
"iss":"https://original-issuer.example.net", "iss":"https://original-issuer.example.net",
"exp":1441910060, "exp":1441910060,
"sub":"admin@example.net" "sub":"admin@example.net"
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section> </section>
<section anchor="DelegationResponse" numbered="true" toc="default">
<section anchor="DelegationResponse" title="Token Exchange Response"> <name>Token Exchange Response</name>
<t> <t>
The <spanx style="verb">access_token</spanx> parameter of the token exch The <tt>access_token</tt> parameter of the token exchange
ange
response shown below contains the new token that the client requested. response shown below contains the new token that the client requested.
The other parameters of the response indicate that the token is a JWT The other parameters of the response indicate that the token is a JWT
that expires in an hour and that the access token type is not applicable that expires in an hour and that the access token type is not applicable
since the issued token is not an access token. since the issued token is not an access token.
</t> </t>
<figure anchor="DelegationResponseEx" title="Token Exchange Response"> <figure anchor="DelegationResponseEx">
<artwork><![CDATA[ <name>Token Exchange Response</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/json Content-Type: application/json
Cache-Control: no-cache, no-store Cache-Control: no-cache, no-store
{ {
"access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjcyIn0.eyJhdWQiOiJ1cm4 "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjcyIn0.eyJhdWQiOiJ1cm4
6ZXhhbXBsZTpjb29wZXJhdGlvbi1jb250ZXh0IiwiaXNzIjoiaHR0cHM6Ly9hcy5l 6ZXhhbXBsZTpjb29wZXJhdGlvbi1jb250ZXh0IiwiaXNzIjoiaHR0cHM6Ly9hcy5l
eGFtcGxlLmNvbSIsImV4cCI6MTQ0MTkxMzYxMCwic2NvcGUiOiJzdGF0dXMgZmVlZ eGFtcGxlLmNvbSIsImV4cCI6MTQ0MTkxMzYxMCwic2NvcGUiOiJzdGF0dXMgZmVlZ
CIsInN1YiI6InVzZXJAZXhhbXBsZS5uZXQiLCJhY3QiOnsic3ViIjoiYWRtaW5AZX CIsInN1YiI6InVzZXJAZXhhbXBsZS5uZXQiLCJhY3QiOnsic3ViIjoiYWRtaW5AZX
hhbXBsZS5uZXQifX0.3paKl9UySKYB5ng6_cUtQ2qlO8Rc_y7Mea7IwEXTcYbNdwG hhbXBsZS5uZXQifX0.3paKl9UySKYB5ng6_cUtQ2qlO8Rc_y7Mea7IwEXTcYbNdwG
9-G1EKCFe5fW3H0hwX-MSZ49Wpcb1SiAZaOQBtw", 9-G1EKCFe5fW3H0hwX-MSZ49Wpcb1SiAZaOQBtw",
"issued_token_type":"urn:ietf:params:oauth:token-type:jwt", "issued_token_type":"urn:ietf:params:oauth:token-type:jwt",
"token_type":"N_A", "token_type":"N_A",
"expires_in":3600 "expires_in":3600
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<!-- JWT signing key for example.com </section>
{"kty":"EC","kid":"72","use":"sig","alg":"ES256", <section anchor="DelegationIssuedClaims" numbered="true" toc="default">
"x":"472aI8TvDdm2qfBRpXYw0uZ7feumuQOM-RPRkkTukSo", <name>Issued Token Claims</name>
"y":"VNNStdPhuxY6q7XfVIeYSW7xh_a4z5W2MCtNmQDcILc", <t>
"crv":"P-256",
"d":"dtJiut8QBJxACG6fcX8NYnzIsAN1muCJvaMiLSrOjIc"}
-->
</section>
<section anchor="DelegationIssuedClaims" title="Issued Token Claims">
<t>
The decoded JWT Claims Set of the issued token is shown below. The new J WT is The decoded JWT Claims Set of the issued token is shown below. The new J WT is
issued by the authorization server and intended for consumption by a sys tem entity issued by the authorization server and intended for consumption by a sys tem entity
known by the logical name known by the logical name
<spanx style="verb">urn:example:cooperation-context</spanx> <tt>urn:example:cooperation-context</tt>
any time before its expiration. any time before its expiration.
The subject (<spanx style="verb">sub</spanx>) The subject (<tt>sub</tt>)
of the JWT of the JWT
is the same as the subject of is the same as the subject of
the <spanx style="verb">subject_token</spanx> used to make the request. the <tt>subject_token</tt> used to make the request.
The actor (<spanx style="verb">act</spanx>) of the JWT is the same as the subj The actor (<tt>act</tt>) of the JWT is the same as the subject
ect of the <tt>actor_token</tt> used to make the request.
of the <spanx style="verb">actor_token</spanx> used to make the request.
This indicates delegation and identifies This indicates delegation and identifies
<spanx style="verb">admin@example.net</spanx> as the current actor to who <tt>admin@example.net</tt> as the current actor to whom authority
m authority has been delegated to act on behalf of <tt>user@example.net</tt>.
has been delegated to act on behalf of <spanx style="verb">user@example. </t>
net</spanx>. <figure anchor="DelegationIssuedClaimsEx">
</t> <name>Issued Token Claims</name>
<figure anchor="DelegationIssuedClaimsEx" title="Issued Token Claims"> <sourcecode type="json"><![CDATA[
<artwork><![CDATA[
{ {
"aud":"urn:example:cooperation-context", "aud":"urn:example:cooperation-context",
"iss":"https://as.example.com", "iss":"https://as.example.com",
"exp":1441913610, "exp":1441913610,
"scope":"status feed", "scope":"status feed",
"sub":"user@example.net", "sub":"user@example.net",
"act": "act":
{ {
"sub":"admin@example.net" "sub":"admin@example.net"
} }
} }
]]></artwork> ]]></sourcecode>
</figure> </figure>
</section>
</section>
</section> </section>
</section> <section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t> <t>
This specification was developed within the OAuth Working Group, which This specification was developed within the OAuth Working Group, which
includes dozens of active and dedicated participants. includes dozens of active and dedicated participants.
It was produced under the chairmanship of It was produced under the chairmanship of
Hannes Tschofenig, Derek Atkins, and Rifaat Shekh-Yusef <contact fullname="Hannes Tschofenig"/>, <contact fullname="Derek
with Kathleen Moriarty, Stephen Farrell, Eric Rescorla, Roman Danyliw, a Atkins"/>, and <contact fullname="Rifaat Shekh-Yusef"/>,
nd Benjamin Kaduk serving as with <contact fullname="Kathleen Moriarty"/>, <contact fullname="Stephen
Farrell"/>, <contact fullname="Eric Rescorla"/>, <contact fullname="Roman
Danyliw"/>, and <contact fullname="Benjamin Kaduk"/> serving as
Security Area Directors. Security Area Directors.
The following individuals contributed ideas, feedback, and wording
to this specification:
</t> </t>
<t> <t>
Caleb Baker, The following individuals contributed ideas, feedback, and wording
Vittorio Bertocci, to this specification:
Mike Brown, <contact fullname="Caleb Baker"/>,
Thomas Broyer, <contact fullname="Vittorio Bertocci"/>,
Roman Danyliw, <contact fullname="Mike Brown"/>,
William Denniss, <contact fullname="Thomas Broyer"/>,
Vladimir Dzhuvinov, <contact fullname="Roman Danyliw"/>,
Eric Fazendin, <contact fullname="William Denniss"/>,
Phil Hunt, <contact fullname="Vladimir Dzhuvinov"/>,
Benjamin Kaduk, <contact fullname="Eric Fazendin"/>,
Jason Keglovitz, <contact fullname="Phil Hunt"/>,
Torsten Lodderstedt, <contact fullname="Benjamin Kaduk"/>,
Barry Leiba, <contact fullname="Jason Keglovitz"/>,
Adam Lewis, <contact fullname="Torsten Lodderstedt"/>,
James Manger, <contact fullname="Barry Leiba"/>,
Nov Matake, <contact fullname="Adam Lewis"/>,
Matt Miller, <contact fullname="James Manger"/>,
Hilarie Orman, <contact fullname="Nov Matake"/>,
Matthew Perry, <contact fullname="Matt Miller"/>,
Eric Rescorla, <contact fullname="Hilarie Orman"/>,
Justin Richer, <contact fullname="Matthew Perry"/>,
Adam Roach, <contact fullname="Eric Rescorla"/>,
Rifaat Shekh-Yusef, <contact fullname="Justin Richer"/>,
Scott Tomilson, <contact fullname="Adam Roach"/>,
<contact fullname="Rifaat Shekh-Yusef"/>,
<contact fullname="Scott Tomilson"/>,
and and
Hannes Tschofenig. <contact fullname="Hannes Tschofenig"/>.
</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>
-19
<list style='symbols'>
<t>Fix-up changes introduced in -18.</t>
<t>Fix invalid JSON in the Nested Actor Claim example.</t>
<t>Reference figure numbers in text when introducing the examples in S
ection 2 and 4.</t>
<t>Editorial updates from additional IESG evaluation comments.</t>
<t>Add an informational reference to ietf-oauth-resource-indicators</t
>
<t>Update ietf-oauth-security-topics ref to 13</t>
</list>
</t>
<t>
-18
<list style='symbols'>
<t>Editorial updates based on a few more IESG evaluation comments.</t>
</list>
</t>
<t>
-17
<list style='symbols'>
<t>Editorial improvements and example fixes resulting from IESG evalua
tion comments.</t>
<t>Added a pointer to RFC6749's Appendix B. on the
"Use of application/x-www-form-urlencoded Media Type" as a way of
providing a normative citation (by reference) for the media type.</t
>
<t>Strengthened some of the wording in the privacy considerations to b
ring it inline
with RFC 7519 Sec. 12 and RFC 6749 Sec. 10.8.</t>
</list>
</t>
<t>
-16
<list style='symbols'>
<t>Fixed typo and added an AD to Acknowledgements.</t>
</list>
</t>
<t>
-15
<list style='symbols'>
<t>Updated the nested actor claim example to (hopefully) be more strai
ghtforward.</t>
<t>Reworked Privacy Considerations to say to use TLS in transit, minim
ize the amount of
information in the token, and encrypt the token if disclosure of its
information to the
client is a concern per https://mailarchive.ietf.org/arch/msg/secdir
/KJhx4aq_U5uk3k6zpYP-CEHbpVM
</t>
<t>Moved the Security and Privacy Considerations sections to before th
e IANA Considerations.</t>
</list>
</t>
<t>
-14
<list style='symbols'>
<t>Added text in <xref target="actor"/> about the "act" claim stating that
only the top-level claims
and the current actor are to be considered in applying access control de
cisions.</t>
</list>
</t>
<t>
-13
<list style='symbols'>
<t>Updated the claim name and value syntax for scope to be consistent with
the treatment
of scope in RFC 7662 OAuth 2.0 Token Introspection.</t>
<t>Updated the client identifier claim name to be consistent with the trea
tment of client id
in RFC 7662 OAuth 2.0 Token Introspection.</t>
</list>
</t>
<t>
-12
<list style='symbols'>
<t>Updated to use the boilerplate from RFC 8174.</t>
</list>
</t>
<t>
-11
<list style='symbols'>
<t>Added new WG chair and AD to the Acknowledgements.</t>
<t>Applied clarifications suggested during AD review by EKR.</t>
</list>
</t>
<t>
-10
<list style='symbols'>
<t>
Defined token type URIs for base64url-encoded SAML 1.1 and SAML 2.0 a
ssertions.
</t>
<t>
Applied editorial fixes.
</t>
</list>
</t>
<t>
-09
<list style='symbols'>
<t>Changed "security tokens obtained could be used in a number of contexts"
to
"security tokens obtained may be used in a number of contexts" per a WGLC
suggestion.</t>
<t>Clarified that the validity of the subject or actor token have no impact
on the validity
of the issued token after the exchange has occurred per a WGLC comment.</t
>
<t>Changed use of invalid_target error code to a SHOULD per a WGLC comment.<
/t>
<t>Clarified text about non-identity claims within the "act" claim being mea
ningless
per a WGLC comment.</t>
<t>Added brief Privacy Considerations section per WGLC comments.</t>
</list>
</t>
<t>
-08
<list style='symbols'>
<t>Use the bibxml reference for OpenID.Core rather than defining it inline.<
/t>
<t>Added editor role for Campbell.</t>
<t>Minor clarification of the text for actor_token.</t>
</list>
</t>
<t>
-07
<list style='symbols'>
<t>Fixed typo (desecration -> discretion).</t>
<t>
Added an explanation of the relationship between scope, audience and resourc
e in the request
and added an "invalid_target" error code enabling the AS to tell the client
that the requested audiences/resources were too broad.
</t>
</list>
</t>
<t>
-06
<list style='symbols'>
<t>Drop "An STS for the REST of Us" from the title.</t>
<t>Drop "heavyweight" and "lightweight" from the abstract and introduction.</t
>
<t>Clarifications on the language around xxxxxx_token_type.</t>
<t>Remove the want_composite parameter.</t>
<t>
Add a short mention of proof-of-possession style tokens to the introduction
and remove the respective open issue.
</t>
</list>
</t>
<t>
-05
<list style='symbols'>
<t>
Defined the JWT claim <spanx style="verb">cid</spanx> to express
the OAuth 2.0 client identifier of the client that requested the token.
</t>
<t>
Defined and requested registration for <spanx style="verb">act</spanx> and
<spanx style="verb">may_act</spanx> as Token introspection response paramete
rs
(in addition to being JWT claims).
</t>
<t>
Loosen up the language about refresh_token in the response to OPTIONAL from
NOT RECOMMENDED
based on feedback form real world deployment experience.
</t>
<t>
Add clarifying text about the distinction between JWT and access token URIs.
</t>
<t>
Close out (remove) some of the Open Issues bullets that have been resolved.
</t>
</list>
</t>
<t>
-04
<list style='symbols'>
<t>
Clarified that the "resource" and "audience" request parameters can b
e used at the same
time (via http://www.ietf.org/mail-archive/web/oauth/current/msg15335
.html).
</t>
<t>
Clarified subject/actor token validity after token exchange and expla
ined a
bit more about the recommendation to not issue refresh tokens
(via http://www.ietf.org/mail-archive/web/oauth/current/msg15318.html
).
</t>
<t>
Updated the examples appendix to use an issuer value that doesn't imply
that the client issued and signed the tokens and used "Bearer" and
"urn:ietf:params:oauth:token-type:access_token" in one of the responses
(via http://www.ietf.org/mail-archive/web/oauth/current/msg15335.html).
</t>
<t>
Defined and registered urn:ietf:params:oauth:token-type:id_token,
since some use cases perform token exchanges for ID Tokens
and no URI to indicate that a token is an ID Token had previously bee
n defined.
</t>
</list>
</t>
<t>
-03
<list style='symbols'>
<t>Updated the document editors (adding Campbell, Bradley, and Mortimo
re).</t>
<t>Added to the title.</t>
<t>Added to the abstract and introduction.</t>
<t>
Updated the format of the request to use application/x-www-form-urle
ncoded
request parameters and the response to use the existing token endpoin
t
JSON parameters defined in OAuth 2.0.
</t>
<t>Changed the grant type identifier to urn:ietf:params:oauth:grant-ty
pe:token-exchange.</t>
<t>
Added RFC 6755 registration requests for
urn:ietf:params:oauth:token-type:refresh_token,
urn:ietf:params:oauth:token-type:access_token, and
urn:ietf:params:oauth:grant-type:token-exchange.
</t>
<t>
Added RFC 6749 registration requests for request/response parameters
.
</t>
<t>
Removed the Implementation Considerations and the requirement to supp
ort JWTs.
</t>
<t>Clarified many aspects of the text.</t>
<t>
Changed <spanx style="verb">on_behalf_of</spanx> to
<spanx style="verb">subject_token</spanx>,
<spanx style="verb">on_behalf_of_token_type</spanx> to
<spanx style="verb">subject_token_type</spanx>,
<spanx style="verb">act_as</spanx> to
<spanx style="verb">actor_token</spanx>, and
<spanx style="verb">act_as_token_type</spanx> to
<spanx style="verb">actor_token_type</spanx>.
</t>
<t>
Added an <spanx style="verb">audience</spanx> request parameter used
to
indicate the logical names of the target services at which the client
intends to use the requested security token.
</t>
<t>
Added a <spanx style="verb">want_composite</spanx> request parameter used
to
indicate the desire for a composite token rather than trying to infer it f
rom the
presence/absence of token(s) in the request.
</t>
<t>
Added a <spanx style="verb">resource</spanx> request parameter used
to
indicate the URLs of resources at which the client
intends to use the requested security token.
</t>
<t>
Specified that multiple <spanx style="verb">audience</spanx> and
<spanx style="verb">resource</spanx> request parameter values may be
used.
</t>
<t>
Defined the JWT claim <spanx style="verb">act</spanx> (actor) to express
the current actor or delegation principal.
</t>
<t>
Defined the JWT claim <spanx style="verb">may_act</spanx> to express
that one party is authorized to act on behalf of another party.
</t>
<t>
Defined the JWT claim <spanx style="verb">scp</spanx> (scopes) to exp
ress
OAuth 2.0 scope-token values.
</t>
<t>
Added the <spanx style="verb">N_A</spanx> (not applicable)
OAuth Access Token Type definition for use in contexts in which
the token exchange syntax requires a <spanx style="verb">token_type</
spanx>
value, but in which the token being issued is not an access token.
</t>
<t>Added examples.</t>
</list>
</t>
<t>
-02
<list style='symbols'>
<t>
Enabled use of Security Token types other than JWTs for
<spanx style="verb">act_as</spanx> and
<spanx style="verb">on_behalf_of</spanx> request values.
</t>
<t>
Referenced the JWT and OAuth Assertions RFCs.
</t>
</list>
</t>
<t>
-01
<list style='symbols'>
<t>
Updated references.
</t>
</list>
</t>
<t>
-00
<list style='symbols'>
<t>
Created initial working group draft from draft-jones-oauth-token-exc
hange-01.
</t>
</list>
</t> </t>
<?rfc subcompact="no"?>
</section> </section>
</back> </back>
</rfc> </rfc>
<!-- code used to create the JWTs in examples
public class TokenExExamplesTest
{
@Test
public void go() throws Exception
{
main(null);
}
public static void main(String[] args) throws Exception
{
AlgorithmFactoryFactory.getInstance(); // init to get the logging out of
the way
System.out.println("\nmain-example");
System.out.println(" main :::::");
PublicJsonWebKey mainExKey = PublicJsonWebKey.Factory.newPublicJwk("{\"k
ty\":\"EC\",\"kid\":\"9er\",\"use\":\"sig\",\"alg\":\"ES256\",\"x\":\"5yoR9FjZHn
7kJDALhDzhZ8i8F06mc12YswUMTBv4BoA\",\"y\":\"4uxuIItWj5Duzspth5mUbpLXWrPFzFPQkOCe
AGGI6KM\",\"crv\":\"P-256\",\"d\":\"LncS7zrx6c8X5qZRxoSN18ZEYDeI2wfKfUvX_DgwRH8\
"}");
System.out.println(mainExKey.toJson(JsonWebKey.OutputControlLevel.INCLUD
E_PRIVATE));
NumericDate iat = NumericDate.fromSeconds(1441917533);
System.out.println(iat);
NumericDate exp = NumericDate.fromSeconds(iat.getValue());
exp.addSeconds(60);
JwtClaims claims = new JwtClaims();
claims.setAudience("https://backend.example.com");
final String asDotComUri = "https://as.example.com";
claims.setIssuer(asDotComUri);
claims.setExpirationTime(exp);
claims.setIssuedAt(iat);
claims.setSubject("bdc@example.com");
claims.setClaim("scope", "api");
JsonWebSignature jws = new JsonWebSignature();
jws.setAlgorithmHeaderValue(AlgorithmIdentifiers.ECDSA_USING_P256_CURVE_
AND_SHA256);
jws.setKeyIdHeaderValue(mainExKey.getKeyId());
jws.setKey(mainExKey.getPrivateKey());
jws.setPayload(claims.toJson());
System.out.println(jws.getCompactSerialization());
System.out.println("\n\n\n\nimpersonation-example");
System.out.println("\n subject :::::");
PublicJsonWebKey dotNetKey = PublicJsonWebKey.Factory.newPublicJwk("{\"k
ty\":\"EC\",\"kid\":\"16\",\"use\":\"sig\",\"alg\":\"ES256\",\"x\":\"N_MqlYd_Iq0
rfzTqXAX7TUC0r7fQSp3YQKh42tn7uSc\",\"y\":\"9tGuwMFkHYWPqkLa51f8GazZNQqdgMOVvJEd6
fJ18PI\",\"crv\":\"P-256\",\"d\":\"cZ_4DqRSAWMMErQbKv6dCYqI9G1pi6lxvlvHU152Uts\"
}");
System.out.println(dotNetKey.toJson(JsonWebKey.OutputControlLevel.INCLUD
E_PRIVATE));
iat = NumericDate.fromSeconds(1441910000);
System.out.println(iat);
exp = NumericDate.fromSeconds(iat.getValue());
exp.addSeconds(600);
NumericDate nbf = NumericDate.fromSeconds(iat.getValue());
nbf.addSeconds(-1000);
claims = new JwtClaims();
claims.setAudience(asDotComUri);
String originalIssuerDotNetUri = "https://original-issuer.example.net";
claims.setIssuer(originalIssuerDotNetUri);
claims.setExpirationTime(exp);
claims.setNotBefore(nbf);
claims.setSubject("bdc@example.net");
claims.setStringClaim("scope", "orders profile history");
jws = new JsonWebSignature();
jws.setAlgorithmHeaderValue(AlgorithmIdentifiers.ECDSA_USING_P256_CURVE_
AND_SHA256);
jws.setKeyIdHeaderValue(dotNetKey.getKeyId());
jws.setKey(dotNetKey.getPrivateKey());
String payload = claims.toJson();
jws.setPayload(payload);
System.out.println("sub token: " + jws.getCompactSerialization());
System.out.println("sub token claims: " + payload);
System.out.println("\n issued :::::");
PublicJsonWebKey dotComKey = PublicJsonWebKey.Factory.newPublicJwk("{\"k
ty\":\"EC\",\"kid\":\"72\",\"use\":\"sig\",\"alg\":\"ES256\",\"x\":\"472aI8TvDdm
2qfBRpXYw0uZ7feumuQOM-RPRkkTukSo\",\"y\":\"VNNStdPhuxY6q7XfVIeYSW7xh_a4z5W2MCtNm
QDcILc\",\"crv\":\"P-256\",\"d\":\"dtJiut8QBJxACG6fcX8NYnzIsAN1muCJvaMiLSrOjIc\"
}");
System.out.println(dotComKey.toJson(JsonWebKey.OutputControlLevel.INCLUD
E_PRIVATE));
iat = NumericDate.fromSeconds(1441910010);
System.out.println(iat);
exp = NumericDate.fromSeconds(iat.getValue());
exp.addSeconds(3600);
claims = new JwtClaims();
claims.setAudience("urn:example:cooperation-context");
claims.setIssuer(asDotComUri);
claims.setExpirationTime(exp);
claims.setSubject("bdc@example.net");
claims.setStringClaim("scope", "orders profile history");
jws = new JsonWebSignature();
jws.setAlgorithmHeaderValue(AlgorithmIdentifiers.ECDSA_USING_P256_CURVE_
AND_SHA256);
jws.setKeyIdHeaderValue(dotComKey.getKeyId());
jws.setKey(dotComKey.getPrivateKey());
payload = claims.toJson();
jws.setPayload(payload);
System.out.println("issued token: " + jws.getCompactSerialization());
System.out.println("issued token claims: " + payload);
System.out.println("\n\n\ndelegation-example");
System.out.println("\n :::::");
iat = NumericDate.fromSeconds(1441910000);
System.out.println(iat);
exp = NumericDate.fromSeconds(iat.getValue());
exp.addSeconds(60);
String admin = "admin@example.net";
claims = new JwtClaims();
claims.setAudience(asDotComUri);
claims.setIssuer(originalIssuerDotNetUri);
claims.setExpirationTime(exp);
claims.setStringClaim("scope", "status feed");
String sub = "user@example.net";
claims.setSubject(sub);
JwtClaims mayAct = new JwtClaims();
mayAct.setSubject(admin);
claims.setClaim("may_act", mayAct.getClaimsMap());
jws = new JsonWebSignature();
jws.setAlgorithmHeaderValue(AlgorithmIdentifiers.ECDSA_USING_P256_CURVE_
AND_SHA256);
jws.setKeyIdHeaderValue(dotNetKey.getKeyId());
jws.setKey(dotNetKey.getPrivateKey());
payload = claims.toJson();
jws.setPayload(payload);
System.out.println("sub token: " + jws.getCompactSerialization());
System.out.println("sub token claims: " + payload);
claims = new JwtClaims();
claims.setAudience(asDotComUri);
claims.setIssuer(originalIssuerDotNetUri);
claims.setExpirationTime(exp);
claims.setSubject(admin);
jws = new JsonWebSignature();
jws.setAlgorithmHeaderValue(AlgorithmIdentifiers.ECDSA_USING_P256_CURVE_
AND_SHA256);
jws.setKeyIdHeaderValue(dotNetKey.getKeyId());
jws.setKey(dotNetKey.getPrivateKey());
payload = claims.toJson();
jws.setPayload(payload);
System.out.println("actor token: " + jws.getCompactSerialization());
System.out.println("actor token claims: " + payload);
iat = NumericDate.fromSeconds(1441910010);
System.out.println(iat);
exp = NumericDate.fromSeconds(iat.getValue());
exp.addSeconds(3600);
claims = new JwtClaims();
claims.setAudience("urn:example:cooperation-context");
claims.setIssuer(asDotComUri);
claims.setExpirationTime(exp);
claims.setStringClaim("scope", "status feed");
claims.setSubject(sub);
JwtClaims actor = new JwtClaims();
actor.setSubject(admin);
claims.setClaim("act", actor.getClaimsMap());
jws = new JsonWebSignature();
jws.setAlgorithmHeaderValue(AlgorithmIdentifiers.ECDSA_USING_P256_CURVE_
AND_SHA256);
jws.setKeyIdHeaderValue(dotComKey.getKeyId());
jws.setKey(dotComKey.getPrivateKey());
payload = claims.toJson();
jws.setPayload(payload);
System.out.println("issued token: " + jws.getCompactSerialization());
System.out.println("issued token claims: " + payload);
}
}
 End of changes. 214 change blocks. 
1797 lines changed or deleted 1141 lines changed or added

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