id_token as autorization bearer rather than access_token

Help
,
1

Hi!

By reading more about access_token and id_token I seem to get more and more confused. I need help to understand how to handle my business case.

We are:

  • Not using any third party connections. Also owning all the clients and API’s
  • Using Auth0 Database Connections for users

We want to only use Auth0 for user authentication. The hosted API just want to know if the user is authenticated and what email the authenticated user has. Each API endpoint access is handled by user rights handled by hosted API not Auth0 or Auth0Api.

Currently each client uses Auth0Lock or Auth0.js v8 to authenticated the user and sends the result id_token as bearer to the hosted API. The API then resolves (jwt decode) the user email to check whether or not that user has the right for the specific endpoint. Validation and decode of id_token bearer is done in similar fashion as auth0-python-api-samples/server.py at master · auth0-samples/auth0-python-api-samples · GitHub

According to documentation access_tokens should be used for clients to access specific endpoints in the API. But due to business demand the hosted API is doing this verification instead. The questions is whether it’s secure to use id_token as authenticated user bearers to the hosted API rather than access_token?

Please let me know if any confusions in the text above. Appreciate any suggestions or help.

Some answers and documentation state to use access_tokens with additional call to get user information. I would like to avoid this if possible due to two reasons:

  • Additional overhead to call the user info endpoint
  • Not using access_token scopes as the hosted API handles it
2

The new API Authorization features are based on the OAuth 2.0 Authorization framework. This is further outlined in our docs.

In short, nothing is stopping you from using id_token as a bearer token. In saying that, id_tokens were meant purely for authentication, rather than API Authorization. The main advantages for using access_tokens are:

  1. Using a proven, secure flow.
  2. Ability to handle more complicated authorization scenarios (e.g. permissions for different clients/users accessing different APIs).
  3. Scalability - if you build more applications (clients) that need to access your APIs, it is much easier to configure your API to validate access_tokens using, for example, the single public key for the API (if using RS256), rather than multiple Client Secrets for each additional client.

Useful docs: