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.

Hi @markd , I have a similar concern. For me, it’s totally fine to continue the session even after the Tenant session expiry.

But I would still want to understand the implications we might have when the Tenant session is expired on a “React Native” mobile application. We have a standard token implementation using Access and Refresh Token. So, we would expect it to never expire unless the user chooses to logout or on certain actions.

My question is Will the app continue to work and the user will be logged in indefinitely using Access Tokens and Refresh token.

Or the Tenant expiry time ( Inactivity timeout and Require log in after) will impact at certain point.

Hello @love.huria,

As far as I know, if the Auth0 session is expired, the user must log back in. A refresh token will not allow you to establish a new Auth0 session. A user will be forced to re-authenticate after 100 days of inactivity, or after 365 days even with activity, or fewer days depending on your tenant settings (Tenant Settings -> Advanced -> Log In Session Management).

Hello @markd , I tried that specific to mobile app.

Even after the time set in “Log In Session Management”, I was still able to get an API response by getting new access token using refresh token which has an indefinite expiry.
It does not throw any error/issue. Is this expected?

Or Maybe my question was not clear.
Say my tenant level setting for user to re-login is 5 minutes.

I have a mobile app running using access token and refresh token. Will it kick the user out if its been more than 5 minutes like web apps/spas. We are using for mobile app.

So, how will that work?

I feel the question asked before: Access token refreshing after Tenant session timeout

and your answer: Access token refreshing after Tenant session timeout

with the above answer is contradicting. Let me know your thoughts.

Hello, Any update on this?

I’m not certain how this applies to a native mobile app (I have no experience with mobile apps). Just a guess but, if there is no browser session involved and the app is using a refresh token to get a new access token, then you’ll be logged in “forever” (until the refresh token is revoked). The refresh token does not expire.

That said, refresh tokens can be rotated now: