After an RP receives tokens (ID/access/refresh token) from an OP and validates the ID token, should the RP store the ID token in the resource owner's session?
If yes, for what purpose the ID token is used?
I think that the access and refresh token should be stored for the following reason, for example:
The answer depends on the Identity Provider (Google, Auth0, IBM, Twitter, etc).
In OAuth 2.0, there are two tokens returned: Access Token and optionally a Refresh Token.
The Access Token is used to authorize access. This may or may not allow you to access identity information from a userinfo endpoint. The Identity Token does contain this information. An Access Token can either be an opaque token, which means there is no information stored in the token that you can decode, or is a Signed JWT. The amount and type of information are Identity Provider specific. Access Tokens are short-lived and expire, typically after 3600 seconds. There is no need to store the Access Token, except for local caching as the token is worthless after expiration.
The Refresh Token is used to create new Access Tokens. Combined with the OAuth 2.0 Client ID and Client Secret, you can create Access Tokens until the Refresh Token expires or is invalidated.
OIDC (OpenID Connect) adds identity on top of OAuth 2.0. OIDC provides an Identity Token that provides user information requested by OAuth scopes and approved by the user who owns the identity. Most Identity Providers implement OIDC with their OAuth implementation. Identity Tokens also expire and can be revoked.
In Google Cloud, you can use the Identity Token to provide Identity Based Access. You assign the identity (email address) with roles to the service (a Compute Engine instance or a Cloud Storage object). If the HTTP header 'Authorization: Bearer ' is present, is valid and matches the email address, then access is granted according to the roles assigned to the identity to that service.
It is a bad security practice to store OAuth tokens in the web session unless uniquely encrypted per session. A better practice is to store the OAuth tokens in a database and look them up when required using an opaque ID stored in the web session.
Not all Identity providers support Refresh Tokens for all OAuth grant types. This is called "offline" access which may be denied meaning once the Access Token expires the user will need to authorize your app again.
