Is there a way to use an existing token as credentials to fetch a new token (in an effort to get a token for a different audience)?
The scenario:
We have a number (N) of microservices which each require a token with a different audience (they all talk their own scopes). As ive seen mentioned before, two ways to handle this are, requiring the client to manage all N tokens, or try bring all services under a single Auth0 API (audience). I was hoping this could be solved in a 3rd way, using a token exchange process.
For example:
I setup an API Gateway that abstracts all the underlying microservice APIs. The API Gateway has a new Auth0 Api (audience). Clients get tokens for the API Gateways audience and make calls. When the calls reach the API Gateway, I take the token and attempt to exchange it for the token i need to call the specific microservice. If the user does not have permissions to access that API, the token exchange fails and i send back a 401. If the user does have permissions, the exchange succeeds, and i have a new token with the correct audience and scopes. I then forward the call to the microservice API using this new token.
Is there any chance Auth0 can do this?
Answering your first question, at the moment, I don’t believe there’s a token for token exchange process that would address your specific scenario. You can use refresh tokens to obtain other tokens, but although being a token exchange the obtained tokens are mostly equivalent to previously obtained ones being the most notable difference their renewed lifetimes.
Despite the above, if you’re going to have an API Gateway brokering access to the downstream micro-services then it’s still possible to achieve your end goals with different levels of integration.
A possible alternative is to have the micro-services in an internal network only accessed from the API Gateway, this would mean that the API Gateway would be the only resource server configured in Auth0 and it would do all the authorization checks. Further calls to micro-services would not need to repeat the check and just implicitly trust the call from the API Gateway which could still include information about the end-user that made the original call if the micro-services require the notion of a user identity.
Another alternative would be to represent both the API Gateway and micro-services as resource servers in Auth0. In this situation, client applications not wanting to deal directly with multiple resource servers would go through the API Gateway which after receiving a request would apply the required validations (user permission checks) and perform a client credentials grant to obtain a token eligible for the downstream micro-service. The downstream micro-service would also validate this token which was issued directly to a client application and as no notion of end-user, however, the call from the API Gateway could still include user identity data that would be trusted because it would be accompanied by a valid token.
With the second alternative the API Gateway acts both as a resource server and as a client application. Personally, I would prefer the first approach which is simpler and has less overhead (authorization checks like token validation are done only once), however, if the micro-services also need to be directly exposed to the outside world then the second option could suit your needs.
In conclusion, you’ll most likely encounter a few alternatives on how to accomplish your goals so you may need to review the pros and cons of each in light of your specific requirements.