We’re currently working on an Auth0 implementation at an enterprise company with the goal of creating a centralized identity server for other applications to reuse. All login operations including SSO would be handled by the Auth0 tenant (hosted lock page) and the user is redirected to the application via the callback with the ID token.
We will not be managing user groups, roles, or permissions in our tenant. This will be purely authentication. With this model in place, applications can continue to use their own groups, roles, and permissions.
Given the above, we’re encouraging applications to do an implicit flow
/authorize call to the tenant with only
id_token as the response type to get the identity information of the user. The
id_token is then passed to the backend API and validated to make sure it was signed by the proper Auth0 tenant.
This means that for most applications that integrate with the Auth0 tenant, they don’t need to worry about managing their own JWT, instead their API could reuse the
id_token as an authoritative token since we trust the Auth0 tenant because we own it.
I’ve received push back on this implementation from some developers with them citing your documentation, specifically:
- Why use access tokens to secure APIs:
Calling your APIs with Auth0 tokens, where it says
In the OIDC-conformant pipeline, ID Tokens should never be used as API tokens .
I’d like to better understand why the docs take such a hard stance on never using ID token to validate. As I outlined above, we’re building an Auth0 tenant to behave as the source of truth for identity information. Any application that trusts the Auth0 tenant could then reuse the ID token to know who the user is knowing the JWT was signed by a trusted authority. Afterwards, the application can then look up the user’s permissions within its own authorization system (i.e. database tables).
There’s also documentation that says to create an
API within the Auth0 tenant that tracks the backend APIs using the tokens, however, we want to keep this tenant ignorant of the architecture of the products that use it save for the single application that receives the call back with the ID token for which we create an
Application in the tenant. This removes the need for us to constantly update the tenant with new APIs and applications as product architecture changes.
Long post, but I’m interested to hear from the Auth0 team on the implementation outlined above and if there’s any glaring issues.