I'm on the verge of creating a service within our resource server that would exchange an externally generated access token for an internally generated access token. However, this feels wrong. I have not found evidence of anyone else needing this pattern, which is a good sign that I'm missing something.


We are running a typical REST based SOA. We delegate authentication to Auth0 so that we can support customers with different Identity Providers. As is, we receive API requests and perform auth based on the access token generated by Auth0. However, we want to manage detailed API permissions internally and we want greater control over the token's life cycle (ie, forced server side revocation.)

Auth0 does support custom claims, but that would require a very tight coupling between our server and theirs (or our rules in their server.) Also, that doesn't solve the forced revocation need either.

It seems like this need can be met by exchanging the Auth0 generated access token for a new access token generated by our server, which could inject claims about the user/identity's configured permissions. This would allow us to control, well anything we want about the token, including revoking it.


I keep scouring OIDC and OAuth2 specs, and searching for others with a similar need. The lack of any hits has me concerned.

Is there a better way to manage authorization internally, while still delegating authentication to a provider like Auth0?

Is there a better way to support token revocation than generating and tracking tokens oneself? Is it possible to maintain stateless tokens and support revocation at the same time? (If this is too much for one SE post, then ignore this part.)


I discovered Token Exchange which looks like what I'm looking for... an OIDC / OAuth2 based version of a Secure Token Service that can exchange tokens from one side of a federated heterogeneous environment for tokens managed by another side of the environment.

So, I'll refine my question: Based on the use case I've described, is the Token Exchange model appropriate? If not, what?

  • We are trying to solve a similar problem. Currently we have an endpoint that does a token exchange of an external OIDC id_token for an internal OAuth bearer token, but it's entirely bespoke. I think the Token Exchange draft spec is the right thing to solve this issue, but I'd like to see it move out of draft status. I've not seen any other solutions suggested either.
    – Rikki
    Oct 30, 2018 at 23:19
  • The only alternative I can imagine is to have all your API servers accept either type of token and have them be able to validate and extract claims from each type of token. However, this does not seem to suit your use case of wanting to keep detailed permissions within your internal tokens. Could you manage a link between the permission and the identity within your system, so it does not need to be in the id_token?
    – Rikki
    Oct 30, 2018 at 23:22
  • 1
    @Rikki Our interim solution (without Token Exchange) does just that. We internally store a set of permissions linked to an identity. On each request, we use the identity from the token to lookup the permissions. This works, but it requires a database hit for each request. I would very much like to get us to a true stateless token, where all auth related information is self contained in the token.
    – allenru
    Oct 31, 2018 at 3:35

1 Answer 1


I believe the way you describe the problem, keeping the 2 security perimeter and configurations decoupled, is a perfect fit for Token Exchange scenario. Some time has passed since your original post and IdP and API Management solutions have started implementing this functionality (https://www.keycloak.org/docs/latest/securing_apps/#_token-exchange) so I believe you are not the only one requiring this specific pattern.

To answer to your other doubt around stateless token and revocation, you might know already that token revocation is actually a standard (https://www.rfc-editor.org/rfc/rfc7009) but that can be implemented only for refresh tokens and by reference token. For by value token this is clearly not possible, but the workaround is obviously to keep the TTL low.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .