Hello! The introduction of OIDC as an OAuth extension is what introduced ID tokens.
ID tokens exist for authentication purposes and are mainly used client-side. Due to the fact that they contain additional user information via claims, they are useful for rendering that information to a page. For example, at a /dashboard endpoint in your app you might have a template setup that looks similar to this pseudo-code:
<Navbar>
<Dropdown>
{{ id_token.claims.email }}
</Dropdown>
</Navbar>
<Dashboard>
Hello {{ id_token.claims.givenName }}!
<Button onclick=callToOrdersAPI>See Order History</Button>
</Dashboard>
If the user then clicks on the button to see their order history, this is where the access token comes into play for authorization. In this scenario, the callToOrdersAPI
method makes a call to a protected API that contains user order information. The request would contain the access token in the authorization header, and the orders API would attempt to validate the access token to determine whether the requested information can be returned.
Does this make sense?