Auth0 Home Blog Docs

Access token refreshing after Tenant session timeout

I have an app setup. In the tenant, I have specified the settings for Inactivity timeout and Require log in after. My app refreshes the token every 5 minutes from the client-side using the refresh token. Based on the tenant settings the Auth0 session should get invalidated after a certain amount of time a specified in the settings. But even after the time has passed, I can still refresh my access tokens and get new ones. Auth0 does not stop or reject token refresh.
I am expecting that after the session has been set to expire as per the Tenant settings, Auth0 session should have expired and when my app tries to refresh a token, it should have failed. But that is not happening right now.
Can anyone please let me know the reason for this?

Are you refreshing your access tokens using a refresh token? Refresh tokens do not expire. They can be manually revoked if needed.

@markd Yes. I am using a refresh token. Does it not sound weird that the user who issued the refresh token has now an invalid session in AUth0 but the refresh token is still valid?
If the user has already logged out from Auth0 or the session has been timed out, how can I know in my app that it has happened? How can I verify that the user is logged out without redirecting to Auth0 so that I can log the user out from my app too?

Hi @shahzad.adil,

OAuth 2.0 is a delegation protocol. Its entire purpose is to allow a 1st party (a person typically) to delegate authority to a 3rd party to act on their behalf. For example, allowing Zoom to manage events in my Google calendar so Zoom can add my video calls directly.

Since access tokens expire (and usually have a short lifetime) a refresh token allows the 3rd party to get new access tokens so it can continue working on behalf of the user. Without refresh tokens, the user would be asked to re-authorize the 3rd party every time a new access token was required. Imagine continuous pop-ups on your phone or browser asking you to re-authorize Zoom to access your calendar.

However, refresh tokens are optional. If you do not request offline_access you won’t get a refresh token and the 3rd party’s access will expire.

@markd You are right. 3rd party is authorised to carry out operations on the behalf of the first party. But shouldn’t that only be allowed till the time the session is valid. Zoom is authorised to make changes to Google account, but that should not be forever. That should only be for a limited period of time. And once that time period expires, Zoom should no longer be allowed to access my Google account without having to reauthorize.
3rd party should not have to reauthorize every time the access token is refreshed, but they should definitely be asked to reauthorise once the mandatory timeout has occurred and the authentication is no longer valid. Otherwise wouldn’t a 1st party end up providing a 3rd party access to sensitive information till the end of time?

I get what you are saying, and there are ways to implement the model that you are describing, but in general this is the way OAuth is intended to work. Ultimately you need to design your solution based on your requirements.

If you did want to force re-authorization, you could forgo the refresh token, but now you have to select an appropriate expiration time for your access tokens with the understanding that a user may be asked to re-authorize access mid-session.

You can also revoke refresh tokens whenever you like, but there’s nothing that does this automatically. Likewise, I can go into my Google account settings and revoke access to 3rd party apps any time I like, but Google doesn’t do that on my behalf.