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:

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): enter image description here

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?

  • You cannot use ID token to query userinfo. It requires access token. ID token can be short-lived. The expiry time is for your service to validate the freshness of userinfo. Even if it's expired you don't have to refresh it. Whenever you will refresh the access token, you can request userinfo again.
    – defalt
    Commented Sep 12, 2022 at 12:55
  • @defalt I added the authorization flow and updated the question to take your remark into account.
    – DurandA
    Commented Sep 12, 2022 at 14:55

1 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.

  • What if the Resource Owner (User) update its profile data on the identity provider (i.e. Keycloak) without using the Client (SPA)? Is there a "clean" way of querying the Authorization Server from the Resource Server for profile data in the long term? Or is it completely out of scope of OIDC and I should give the Resource Server a special access to KeyCloak admin APIs?
    – DurandA
    Commented Sep 13, 2022 at 10:25
  • How soon do you want updated profile data when it is updated?
    – defalt
    Commented Sep 13, 2022 at 12:08
  • Immediately if possible via push notifications, but polling profile data (e.g. once a day) would be acceptable for my use case.
    – DurandA
    Commented Sep 13, 2022 at 12:34
  • You can poll /userinfo endpoint using access token. Though it's not recommended to do so. User profile data should be periodically updated, not frequently.
    – defalt
    Commented Sep 13, 2022 at 12:56
  • That means that the Client has to send the refresh token to the Resource Server (or that Access Token should be configured with a very long lifetime) in order for the Resource Server to keep polling the /userinfo endpoint which is far from ideal.
    – DurandA
    Commented Sep 13, 2022 at 13:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .