Skip to main content

OAuth 2.0 Token Exchange: An STS for the REST of Us
draft-ietf-oauth-token-exchange-04

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8693.
Authors Michael B. Jones , Anthony Nadalin , Brian Campbell , John Bradley , Chuck Mortimore
Last updated 2016-03-04
Replaces draft-jones-oauth-token-exchange, draft-campbell-oauth-sts
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Associated WG milestone
May 2017
Submit 'OAuth 2.0 Token Exchange' to the IESG for consideration as a Proposed Standard
Document shepherd Hannes Tschofenig
IESG IESG state Became RFC 8693 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
draft-ietf-oauth-token-exchange-04
quot;:3600
    }

                    Figure 11: Token Exchange Response

A.1.4.  Issued Token Claims

   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 entity known by the logical name
   "urn:example:cooperation-context" any time before its expiration.
   The subject ("sub") of the JWT is the same as the subject the token
   used to make the request, which effectively enables the client to
   impersonate that subject at the system entity known by the logical
   name of "urn:example:cooperation-context" by using the token.

     {
       "aud":"urn:example:cooperation-context",
       "iss":"https://as.example.com",
       "exp":1441913610,
       "sub":"bc@example.net",
       "scp":["orders","history","profile"]
     }

                      Figure 12: Issued Token Claims

A.2.  Delegation Token Exchange Example

A.2.1.  Token Exchange Request

   In the following token exchange request, an anonymous client is
   requesting a token with delegation semantics, which is indicated by
   the inclusion of the "want_composite" parameter.  The client tells

Jones, et al.           Expires September 5, 2016              [Page 22]
Internet-Draft          OAuth 2.0 Token Exchange              March 2016

   the authorization server that it needs a token for use at the target
   service with the logical name "urn:example:cooperation-context".

    POST /as/token.oauth2 HTTP/1.1
    Host: as.example.com
    Content-Type: application/x-www-form-urlencoded

    grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
    &audience=urn%3Aexample%3Acooperation-context
    &want_composite=true
    &subject_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwc
      zovL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXI
      uZXhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTAwNjAsInNjcCI6WyJzdGF0dXMiLCJmZ
      WVkIl0sInN1YiI6InVzZXJAZXhhbXBsZS5uZXQiLCJtYXlfYWN0Ijp7InN1YiI6ImF
      kbWluQGV4YW1wbGUubmV0In19.ut0Ll7wm920VzRvuLGLFoPJLeO5DDElxsax1L_xK
      Um2eooiNSfuif-OGa2382hPyFYnddKIa0wmDhQksW018Rw
    &subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt
    &actor_token=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.eyJhdWQiOiJodHRwczo
      vL2FzLmV4YW1wbGUuY29tIiwiaXNzIjoiaHR0cHM6Ly9vcmlnaW5hbC1pc3N1ZXIuZ
      XhhbXBsZS5uZXQiLCJleHAiOjE0NDE5MTAwNjAsInN1YiI6ImFkbWluQGV4YW1wbGU
      ubmV0In0.7YQ-3zPfhUvzje5oqw8COCvN5uP6NsKik9CVV6cAOf4QKgM-tKfiOwcgZ
      oUuDL2tEs6tqPlcBlMjiSzEjm3yBg
    &actor_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Ajwt

                     Figure 13: Token Exchange Request

A.2.2.  Subject Token Claims

   The "subject_token" in the prior request is a JWT and the decoded JWT
   Claims Set is shown here.  The JWT is intended for consumption by the
   authorization server before a specific expiration time.  The subject
   of the JWT ("user@example.net") is the party on behalf of whom the
   new token is being requested.

     {
       "aud":"https://as.example.com",
       "iss":"https://original-issuer.example.net",
       "exp":1441910060,
       "scp":["status","feed"],
       "sub":"user@example.net",
       "may_act":
       {
         "sub":"admin@example.net"
       }
     }

                      Figure 14: Subject Token Claims

Jones, et al.           Expires September 5, 2016              [Page 23]
Internet-Draft          OAuth 2.0 Token Exchange              March 2016

A.2.3.  Actor Token Claims

   The "actor_token" in the prior request is a JWT and the decoded JWT
   Claims Set is shown here.  This JWT is also intended for consumption
   by the authorization server before a specific expiration time.  The
   subject of the JWT ("admin@example.net") is the actor that will wield
   the security token being requested.

     {
       "aud":"https://as.example.com",
       "iss":"https://original-issuer.example.net",
       "exp":1441910060,
       "sub":"admin@example.net"
     }

                       Figure 15: Actor Token Claims

A.2.4.  Token Exchange Response

   The "access_token" parameter of the token exchange response shown
   below contains the new token that the client requested.  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
   since the issued token is not an access token.

    HTTP/1.1 200 OK
    Content-Type: application/json
    Cache-Control: no-cache, no-store

    {
     "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6IjcyIn0.eyJhdWQiOiJ1cm4
       6ZXhhbXBsZTpjb29wZXJhdGlvbi1jb250ZXh0IiwiaXNzIjoiaHR0cHM6Ly9hcy5l
       eGFtcGxlLmNvbSIsImV4cCI6MTQ0MTkxMzYxMCwic2NwIjpbInN0YXR1cyIsImZlZ
       WQiXSwic3ViIjoidXNlckBleGFtcGxlLm5ldCIsImFjdCI6eyJzdWIiOiJhZG1pbk
       BleGFtcGxlLm5ldCJ9fQ._qjM7Ij_HcrC78omT4jiZTFJOuzsAj1wPo31ymQS-Suq
       r64S1jCp6pfQR-in_OOAosAGamEg4jyPsht6kMAiYA",
     "issued_token_type":"urn:ietf:params:oauth:token-type:jwt",
     "token_type":"N_A",
     "expires_in":3600
    }

                    Figure 16: Token Exchange Response

A.2.5.  Issued Token Claims

   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 entity known by the logical name

Jones, et al.           Expires September 5, 2016              [Page 24]
Internet-Draft          OAuth 2.0 Token Exchange              March 2016

   "urn:example:cooperation-context" any time before its expiration.
   The subject ("sub") of the JWT is the same as the subject of the
   "subject_token" used to make the request.  The actor ("act") of the
   JWT is the same as the subject of the "actor_token" used to make the
   request.  This indicates delegation and identifies
   "admin@example.net" as the current actor to whom authority has been
   delegated to act on behalf of "user@example.net".

     {
       "aud":"urn:example:cooperation-context",
       "iss":"https://as.example.com",
       "exp":1441913610,
       "scp":["status","feed"],
       "sub":"user@example.net",
       "act":
       {
         "sub":"admin@example.net"
       }
     }

                      Figure 17: Issued Token Claims

Appendix B.  Acknowledgements

   This specification was developed within the OAuth Working Group,
   which includes dozens of active and dedicated participants.  It was
   produced under the chairmanship of Hannes Tschofenig and Derek Atkins
   with Kathleen Moriarty and Stephen Farrell serving as Security Area
   Directors.  The following individuals contributed ideas, feedback,
   and wording to this specification:

   Caleb Baker, William Denniss, Vladimir Dzhuvinov, Phil Hunt, Jason
   Keglovitz, Nov Matake, Matt Miller, Matthew Perry, Justin Richer,
   Rifaat Shekh-Yusef, Scott Tomilson, and Hannes Tschofenig.

Appendix C.  Open Issues

   The following decisions need to be made and updates to this spec
   performed:

   o  Should there be a way to use short names for some common token
      type identifiers?  URIs are necessary in the general case for
      extensibility and vendor/deployment specific types.  But short
      names like "access_token" and "jwt" are aesthetically appealing
      and slightly more efficient in terms of bytes on the wire and url-
      encoding.  There seemed to be rough consensus in Prague ('No
      objection to use the proposed mechanism for a default prefix' from
      https://www.ietf.org/proceedings/93/minutes/minutes-93-oauth) for

Jones, et al.           Expires September 5, 2016              [Page 25]
Internet-Draft          OAuth 2.0 Token Exchange              March 2016

      supporting a shorthand for commonly used types - i.e. when the
      value does not contain a ":" character, the value would be treated
      as though "urn:ietf:params:oauth:token-type:" were prepended to
      it.  So, for example, the value "jwt" for "requested_token_type"
      would be semantically equivalent to "urn:ietf:params:oauth:token-
      type:jwt" and the value "access_token" would be equivalent to
      "urn:ietf:params:oauth:token-type:access_token".  However, it was
      a fairly brief discussion in Prague and it has since been
      suggested that making participants handle both syntaxes will
      unnecessarily complicate the supporting code.

   o  Provide a way to include supplementary claims or information in
      the request that would/could potentially be included in the issued
      token.  There are real use cases for this but we would need to
      work through what it would look like.

   o  Understand and define exactly how the presentation of PoP/non-
      bearer tokens works.  Of course, the specifications defining these
      kinds of tokens need to do so first before there is much we can do
      in this specification in this regard.

   o  It seems there may be cases in which it would be desirable for the
      authenticated client to be somehow represented in the issued
      token, sometimes in addition to the actor, which can already be
      represented using the "act" claim.  Perhaps with a "client_id"
      claim?

Appendix D.  Document History

   [[ to be removed by the RFC Editor before publication as an RFC ]]

   -04

   o  Clarified that the "resource" and "audience" request parameters
      can be used at the same time (via http://www.ietf.org/mail-
      archive/web/oauth/current/msg15335.html).
   o  Clarified subject/actor token validity after token exchange and
      explained a bit more about the recommendation to not issue refresh
      tokens (via http://www.ietf.org/mail-archive/web/oauth/current/
      msg15318.html).
   o  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).
   o  Defined and registered urn:ietf:params:oauth:token-type:id_token,
      since some use cases perform token exchanges for ID Tokens and no

Jones, et al.           Expires September 5, 2016              [Page 26]
Internet-Draft          OAuth 2.0 Token Exchange              March 2016

      URI to indicate that a token is an ID Token had previously been
      defined.

   -03

   o  Updated the document editors (adding Campbell, Bradley, and
      Mortimore).
   o  Added to the title.
   o  Added to the abstract and introduction.
   o  Updated the format of the request to use application/x-www-form-
      urlencoded request parameters and the response to use the existing
      token endpoint JSON parameters defined in OAuth 2.0.
   o  Changed the grant type identifier to urn:ietf:params:oauth:grant-
      type:token-exchange.
   o  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.
   o  Added RFC 6749 registration requests for request/response
      parameters.
   o  Removed the Implementation Considerations and the requirement to
      support JWTs.
   o  Clarified many aspects of the text.
   o  Changed "on_behalf_of" to "subject_token",
      "on_behalf_of_token_type" to "subject_token_type", "act_as" to
      "actor_token", and "act_as_token_type" to "actor_token_type".
   o  Added an "audience" request parameter used to indicate the logical
      names of the target services at which the client intends to use
      the requested security token.
   o  Added a "want_composite" request parameter used to indicate the
      desire for a composite token rather than trying to infer it from
      the presence/absence of token(s) in the request.
   o  Added a "resource" request parameter used to indicate the URLs of
      resources at which the client intends to use the requested
      security token.
   o  Specified that multiple "audience" and "resource" request
      parameter values may be used.
   o  Defined the JWT claim "act" (actor) to express the current actor
      or delegation principal.
   o  Defined the JWT claim "may_act" to express that one party is
      authorized to act on behalf of another party.
   o  Defined the JWT claim "scp" (scopes) to express OAuth 2.0 scope-
      token values.
   o  Added the "N_A" (not applicable) OAuth Access Token Type
      definition for use in contexts in which the token exchange syntax
      requires a "token_type" value, but in which the token being issued
      is not an access token.
   o  Added examples.

Jones, et al.           Expires September 5, 2016              [Page 27]
Internet-Draft          OAuth 2.0 Token Exchange              March 2016

   -02

   o  Enabled use of Security Token types other than JWTs for "act_as"
      and "on_behalf_of" request values.
   o  Referenced the JWT and OAuth Assertions RFCs.

   -01

   o  Updated references.

   -00

   o  Created initial working group draft from draft-jones-oauth-token-
      exchange-01.

Authors' Addresses

   Michael B. Jones
   Microsoft

   Email: mbj@microsoft.com
   URI:   http://self-issued.info/

   Anthony Nadalin
   Microsoft

   Email: tonynad@microsoft.com

   Brian Campbell
   Ping Identity

   Email: brian.d.campbell@gmail.com

   John Bradley
   Ping Identity

   Email: ve7jtb@ve7jtb.com

   Chuck Mortimore
   Salesforce

   Email: cmortimore@salesforce.com

Jones, et al.           Expires September 5, 2016              [Page 28]