OAuth 2 - TokenExchange use cases

Question

I have been reading about token exchange and each document talks about different use cases:

1. API gateway use case (https://tyk.io/blog/res-oauth2-token-exchange-rfc8693/) : Client Application gets an access token for API gateway and API gateway exchanges token to get new access token to access the actual resources.

2. This article (https://cloudentity.com/developers/basics/oauth-grant-types/token-exchange/) talks about exchanging an access token from third party OAuth server, to your OAuth server.

3. This article (https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/examples/oauth/token-exchange) talks about issuing an access to user A, which can acts as user B (Impersonation).

The RFC is not clear about the use cases. Can token exchange be implemented for all these use cases?

Answer 1

I'm the author of the Tyk blog post.

Both delegation and impersonation use-cases are described in the RFC.

In my post https://tyk.io/blog/res-oauth2-token-exchange-rfc8693/, the example I provided was about delegation. The Gateway such as Tyk, has it's own identity. The app delegates some of its rights to the Gateway. The Gateway is acting as an agent for the subject.

The RFC describes the distinction between impersonation and delegation https://datatracker.ietf.org/doc/html/rfc8693#name-delegation-vs-impersonation. It introduces the concept of composite tokens.

A composite token contains information about both the actor and the subject - this is a delegation use-case.

  {
    "aud":"urn:example:cooperation-context",
    "iss":"https://as.example.com",
    "exp":1441913610,
    "scope":"status feed",
    "sub":"[email protected]",
    "act":
    {
      "sub":"[email protected]"
    }
  }

In the impersonation use-case, it would be impossible to distinguish between the actor and the subject - the token claims are the same. https://datatracker.ietf.org/doc/html/rfc8693#name-token-exchange-response-2

  {
    "aud":"https://as.example.com",
    "iss":"https://original-issuer.example.net",
    "exp":1441910600,
    "nbf":1441909000,
    "sub":"[email protected]",
    "scope":"orders profile history"
  }

With regards to article 2, migrating between identity providers it not in my field of expertise. That said, I can't see why token exchange cannot also be used for this purpose.