I’m evaluating Auth0 and want to test a simple implicit login flow with a SPA and API. The problem I have is that the access_token returned from Auth0 is opaque - but there is no introspection endpoint to validate it against. I therefore cannot pass this token into my microservices as they cannot validate it.
If I read the docs correctly, I am expected to pass an audience parameter in to the initial authorize call, and this will then embed the API name into a JWT. This seems to me to a) be non standard and b) stops me being able to pass that token to another microservice other than the API that it was originally requested for.
Can someone please clarify if my assumptions are correct, and what the recommended way of doing this with Auth0 is?
The access token format in OAuth2 is an implementation details between the authorization server and resource server. At this time if you configure your own custom resource server (aka API) in Auth0 and want to leverage it to issue access tokens for that API then we impose the JWT format. In the future opaque tokens or other self-contained formats may be supported, but at this time it will be a JWT.
Having said that, no matter the format the resource server should validate that the access token was issued to it and not another API so the situation you mention about inability to pass the token to another downstream API is applicable independently of the access token format.
In relation to the audience parameter it is not technically required so if you only have a single resource server for which you want access tokens to be issued you can configure it as the default audience in your account settings and in this way you would not have the need for any parameter that is not listed in OAuth2. However, the parameter actually brings additional flexibility and the specification itself kind of anticipates that because it makes possible for those additional parameters to be sent without forcing a compliant authorization server to reject the request.
In conclusion, you may either want to represent your micro-services as a single API or only require bearer token authorization at the entry point for requests coming from the outside; that is for service to service communication you would employ other means to validate that the request comes from a trusted party (for example, network level access).
Many thanks @jmangelo - I tested it as you suggest with the default audience and using the JWT and it works. I just need to consider the implications of this now to see if that is acceptable (no revocation etc)