How to manage long-term access to profile data using OIDC?

Question

I am designing an ecosystem of web applications that uses an Open ID Connect (OIDC) authorization server. The users authenticate to the authorization server using the Authorization Code Flow with Proof Key for Code Exchange (PKCE). This authorization server (in this context Keycloak) should provide the following services:

• Authentication: The authorization server provides a Single-Sign On (SSO) for all applications
• Identity provider: The authorization server provides basic OIDC user profile data (see Standard Claims in UserInfo. The authorization server is configured to require some profile data during registration.
• Authorization services: out of scope here

The authorization server is configured to require consent from users in order to access profile data. OIDC servers can provide two type of token: an ID token and an access token.

The authorization flow looks like this (adapted from Okta documentation):

I am confused on how to manage (access+update) profile data from the resource server and how to use which token for what. Should the resource server keep an access token + a refresh token to query UserInfo endpoint in the long term? Is there a better alternative for the resource server to keep track of profile data updates?

Answer 1

ID token is requested with access token as shown in the diagram. The access token, refresh token and the ID token should be stored in the client app. To refresh user profile data, keep the access token short-lived and refresh token long-lived. Whenever the access token will expire, refresh the access token using the refresh token. In the refresh response, the identity provider will send you a new access token, new refresh token and updated ID token which contains user profile data.

You are supposed to always verify the validity of the ID token and the ID token itself in the response. The validity of the ID token can be based on your requirement. If your apps will share ID token with each other, its validity should be long lived so that it does not expire very often while apps are performing some collective tasks. If apps will not share it, keep its validity less than or equal to the validity of the access token.

An expired ID token is still secure. Your app will just not be able to share it with other apps once it is expired because they will reject the expired ID token. Similarly, you must also reject the expired ID token whoever will sent you. Client apps should not remove the expired ID token until it is refreshed because an expired ID token can still be used for RP-Initiated logout.