We have a web app in which we allow users to log into the app using any Open ID provider(e.g. Okta, Google, Facebook etc.). We want to implement the correct Open ID Connect prescribed methodology/workflow to keep the user logged into the site.

The existing implementation, looks at the expiry of the Access Token then if it's close to expiry uses a Refresh Token to get a new Access Token to keep the user logged in. I feel like this is wrong. When a user logs in to the web app, the Identity Token is used to Authenticate the identity of the user using the Authorization Code workflow. The Access Token and Refresh Token are stored on the server side. Periodically, the Refresh Token is used to get new Access Tokens to keep the user logged into the site. I believe this is a security risk because -

Imagine if a user is logged onto his OP account in a browser. He opens up Sky and is directly logged into MP because he’s already logged into MP. He then in a separate tab, logs out of his OP account. He will continue to be logged into MP for days on the basis of this Refresh Token/Access Token mechanism! Isn’t this a security risk?

If feel like the correct way to go about this is to use Session Management using iframes as prescribed here on OIDC - https://openid.net/specs/openid-connect-session-1_0.html

For more context, when a user logs into our WebApp we pull data from the OP's UserInfo endpoint to create a profile within our WebApp and set permissions/roles within our app based on data sent over from the OP's UserInfo endpoint. We continue doing this periodically. For this purpose, I feel like using the Access Token(and using the Refresh Token to get new Access Token) to access the UserInfo API is correct because it conforms to the OAuth 2.0 concept of protecting/authorizing API/Resource endpoints using Access Tokens.

I want to know if this is indeed the correct way to manage how a user should be logged in when supporting Open ID Connect.

3 Answers 3


As I understood the access token and refresh token are meant for the client/rely party to have access to specific user resources stored by other providers. In your case the user allows your services to have access to his or her e.g. email address stored at google or facebook. The access token and refresh token represent this permission. It is not representing login status, because plain oAuth is just for authorization. (Authentication is needed only to give authorization)

Whether the user is still logged in to google or facebook should be managed by these identity providers. Whenever necessary it should be possible to call them for the current login status of user.

I am not sure, if this helps you with your question.


You are correct - don't use refresh tokens to keep users logged in, they are intended for "offline access", i.e. background processes where the user is not present. Keeping the user logged into your app after they have logged out of their OIDC provider may or may not be a security issue, but in any case if that is the desired behaviour then periodically querying the user info endpoint is kinda pointless and you may as well just ignore the expiry time on the access token and keep them logged in as long as you like.

The most basic way to handle this is to keep the user logged into your app until the id_token expires (ignore the access_token). Once the token expires re-authenticate the user against the openid provider - the provider should take care of tracking the users session, and avoid re-authenticating the user if they are still logged in. If the user is paying attention they will see some redirects, but they should end up back at your application without needing to enter their password. The downside of this approach is that if the user logs out of the openid provider, they would remain logged into your app until the id_token expires (which depending on the app, might be some time).

If you want the openid provider to notify your client app when the user logs out then there are actually 3 different mechanisms for you to use depending on the application type:

  • The iframe method described in the OpenID Connect Session Management is primarily intended for single-page apps. It works by sending messages (via javascript) when there are changes to the session state (i.e. the user logs out)
  • The Front-Channel Logout method is intended for traditional web apps, and works using a hidden iframe on the logout page which loads a page from the client application, allowing that application to clear cookies etc...
  • The Back-Channel Logout works by directly sending a HTTP request to the client application (i.e. a webhook). Because the request isn't done in the context of a browser session this means that its not quite as straightforward for the client application to clear down the session (e.g. by invalidating a cookie). Its more for edge cases where the above 2 mechanisms maybe aren't viable, e.g. native applications.

There shouldn't be a huge problem with using the Access and Refresh Token scheme.

If someone logs out of the Identity Provider, their sessions in applications that have authenticated against that IDP may not end. However, that is the responsibility of the application to consider what the risks are and appropriately check the authentication on a regular basis.

You don't necessarily need to wait until close to the expiration of the Access Token to use the Refresh Token. If the tokens last 30 days, you could check on a far more regular basis - days, hours, minutes, or even every single (all or specific) requests to your application. The Refresh Token should become invalid if the session in the IDP ends. If you attempt to use the Refresh Token and it is invalid, you can terminate the session in your application.

How often you check on the authentication status depends on your application, your security requirements, and the threats to your security.

Don't forget - you can totally decouple your session management from the Access and Refresh Tokens from the IDP. Take advantage of that as needed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.