Clarify the usage of ID token for authenticating to an API you own

Help
1

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:

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.

1 Like
2

Hi @omar.dfin

I would say our documentation takes a hard stance on these topics because it describes generic architectures, the most common use cases. The OIDC and OAuth2 protocols (the subject of the documentation you point) are very clear in the semantics of the different type of tokens:

  • The ID token contains information about the user and the authentication act
  • The Access Token represents the credentials to access a protected resource. In the most common usage of OAuth2, it represents the delegated permission given by a user to a client application to access the user’s resources.

Using the ID token as a bearer token for authorization is fine in some specific scenarios (the ID token is, after all, a cryptographically signed token issued by a trusted party). Make sure you understand that:

  • This is only safe when the front and backend are two parts of the same application, and you use the ID token only from the front end to its corresponding back end. If you need a common backend shared by different clients, you should define the backend as an API and use access tokens.
  • This shouldn’t be used for third-party applications.
  • The ID token might contain PII information about the user, which you will be sending along with every request to the backend.
  • You should use an asymmetric signing algorithm (RS256), otherwise any client in possession of the client secret could forge tokens.
  • As always, you should verify the aud claim. Under this usage, the audience of the token received in the backend will match the single client ID shared between the frontend and the backend.
  • You won’t be able to use scopes to limit the things that the token is capable of.
  • This design won’t let you open your backends to potential third-party clients.

Hope this helps!

2 Likes
3

Thank you for the thorough reply. That was helpful.

4

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.