@andrea.chiarelli I understand the role of the id_token in a legacy web application, where it might be used to establish a server side session for the user so that they are “authenticated”. However, in many modern applications, the application is just UI in front of a collection of resources (often ReST based). In this case there is no session; a user is “logged in” if they can expect to make a call to a ReST endpoint and get a valid response. And as you stated, an access token should be used to access resources. What role does the ID token play in this scenario?
Similarly, in the classic OAuth2 scenario (even the example that you used), a resource owner grants one backend application (linked in) access to resources in another backend application (twitter). The OAuth2 client may access resources in the Resource Server even if the Resource Owner is no longer “logged in” to either application. But in the modern application that I describe above, the client may be a SPA and the Resource Server is the ReST API, and both are owned by the same company and part of the same product (unlike your example). In this case, as the developer of the application, if I use Oauth2/OIDC to authenticate and authorize my application, then I don’t expect the authorization to be a long term grant (unlike the linkedin->twitter example). I generally expect the access token to have a lifetime similar to the shorter lifetime of the id token. Is an OAuth2 access token different than an OIDC access token or is this just a matter of different settings for the expiration?