Additional data may be included in an ID token, like the user's roles, but the ID token may not be the best place for this.
Access Tokens
Use Access Tokens when:
An application needs to access a "resource" on the user's behalf
For example, you might grant a drawing application access to your google drive so it can save images (😬). In this case he "resource" is google drive. Other resources might be your calendar, your gmail, a slack channel, an ecommerce order, your account information, etc.
This could be on the server side,
Or it might be a single-page application (SPA) or mobile app calling services directly
💀💀💀
The Userinfo Service
If you find yourself wanting to read user information from an access token directly by decoding it, you're probably misusing it. We treat them as opaque tokens.
However, there is an endpoint in most Authorization servers that will offer up information about a user. It is just another resource, so your application can access it on behalf of the user. Typically it is at /userinfo. For example, in an Auth0 tenant https://dev-nnnnnnnn.us.auth0.com/userinfo is the userinfo service, and it can be called by passing an access token in the Authorization header, e.g.
Tom McLaughlin is a Software Developer residing in Nebraska, where he is safe from shark attacks, but Potato Oles lurk around every corner. You can find him on LinkedIn and Github.
.png)
