Access token vs id token usage

Help
1

There are lots of articles and opinions on this subject but most recent documentation points to id tokens being provided purely as a convenience after authentication and only access tokens should be used to call api’s.

Currently we have 2 front end applications (vuejs) and 2 API’s which they consume. The APIs are configured as oauth2 resource servers using Spring Security. Authorization is determined by the roles a user has (defined in our application) and again Spring security is configured to handle this i.e. restrict endpoints to specific roles as well as more fine grained permissions. Both APIs are not publicly exposed (internal dns) and are accessed via an API gateway.

After a user authenticates, the short-lived id token is obtained and set in a secure http-only cookie. The api gateway picks up the cookie and sets the Bearer header to pass onto the APIs. Each API verifies and converts the token to a Spring Authentication instance with a principal and their granted authorities.

The only information I need from a token is the email address of the user, which exists in the id token. Auth0 documentation is steering me towards using access tokens but I’m struggling to see the benefit in requesting another token which doesn’t contain the email address and so would require me to either pass the email address from the id token in a header as well as the access token or call the /userinfo endpoint from the APIs.

Is using the id token for this scenario acceptable usage or am I missing something.

Thanks,
Craig

2

Upon further investigation, I have discovered that access tokens can be augmented (e.g. user email added) via rules and by supplying the api audience, a jwt access token is provided instead of an opaque token after authentication.

This is starting to make sense now. It was a valuable exercise, too, as I discovered that regardless of api/application scope configured in the dashboard, a client can still request any api scope. This is a bit confusing as I’m not sure what purpose there is to attributing scopes to “Machine to Machine Applications” under APIs. So far, I have found these settings to be of no real value and gives the impression that you are restricting requestable scopes, when it appears to do nothing. If any light an be shed on these settings, that would be helpful. In the meantime, I’ll use rules to modify the access token scope.

Thanks,
Craig

3

Update: I discovered that the “Machine to Machine Applications” settings are only relevant for client credentials grants and that’s why it has no bearing on scopes requested via auth0 lock.

Now using access tokens instead of id token now that I understand the subtle differences.

4

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