I’m new to Auth0 and have read some of your documentation (you have quite a lot)
I’m currently in a similar use case as described in this thread and this one as well.
And i still cannot figure how to do a proper Login/Auth and APIs protection solution with Auth0.
I have a mobile application (iOS), so i have create a Native app on my Auth0 tenant. Everything is configured correctly so that the Login/Logout on the mobile works with Auth0 and some test users defined in a User/Pwd Database Connection.
I have a dozens of different APIs that this mobile application have to call to do “something”. For now, i only created 2 APIs in my Auth0 tenant for tests purpose.
I activated the RBAC option on each custom API, added some specific permissions on each API, create 1 Role that have access to both APIs, and assigned that role to my test users. (manually without rule) When i request for an access token when login in, i expect to get all permissions so that i can request any APIs i have been granted to with a unique token.
I have an API Gateway product which route traffic to my API implementations. I’m using Traefik (Enterprise) I was thinking to just use their JWT Authentication middleware to validate the token with the jwks endpoint + filter the routing based on permissions claim.
According to the Auth0 documentation and the test i have performed so far, the returned access token when a user Log into the mobile application is Opaque since the specified audience for a native app is the /userinfo endpoint.
Because of that and the fact that Auth0 do not provide any introspection endpoint, this access token is quite unusable and therefore useless in term of API access.
Again, on your documentation & example, you says : well, just call it with the audience matching your custom API defined in Auth0 (and without the openid scope else it would be also opaque by default) and you get a clear and standard JWT token.
Fine, this is working as documented. But…
Such token would only contains the permissions related to that API (not any other API a user would be granted through RBAC settings / group permissions)
For a dozen of different APIs, i need to make a WebAuth() call with each API audience to get a jwt token per API. Then my mobile application have to manage them (with their respective refresh token) and the code responsible to call each APIs also need to know which token to pass in the authorization header…
That’s just a big mess right ?
So what are the other options i did not get yet to cover such a common use case ?
If you have dozens of APIs, consider this question: what is the security context of each API.
If all the APIs are the same in their security requirements/needs, they can be represented by a single Auth0 API (with a single set of permissions).
If each API is different, with a different set of permissions, then you need different APIs in Auth0 as well.
Please note, you MUST pass a non-opaque access token when you make an API call. And that access token MUST have the proper audience for the API. Breaking these rules makes the API insecure.
So, that means, if my dozen of APIs really have different permissions set, my mobile application would have to do a dozen of time the authentication process when a user log in to get a dozen of JWT token - one per audience - and use it when calling the api services.
May i ask then what’s the point of having RBAC ? We can create roles and assign API permissions to roles and that’s great. But if there is no way to get all permissions of a single user at once, what’s the point of it ?
Yes the token must be non-opaque, so why Auth0 returns opaque tokens by default and make it hard to get normal JWT tokens ? (without having to make a call for every single API an application have to interact with)
I feel things has been made complicated for nothing (you provides opaque tokens but do not offers any way to validate it), so i have created this feature request
Introspection endpoints should be available, and from that endpoint a way to get the assigned permissions in clear so that a proper routing can be made from 3rd party routers like API Gateway products.
Each “logical” API (group of apis having same security context) should have its own permission set. Roles are here to grant the specific permissions for specific APIs.
I take an extreme example here but if an application have to interact with 100 logical Auth0 APIs and therefore have to do the authentication process 100 times when a user log in to get a clear JWT Access Token per audience, it’s not productive and definitely not efficient.
If your applications is complex enough that it requires 100s of different APIs with different security requirements, then it makes sense that it would requires 100s of access tokens. If you do complex things, your architecture will be complex.