What does refresh token lifetime do?

[ReturnOfTheMac]

Hi,

I’m using okta-auth-js and okta-react and I just started implementing the refresh token rotation feature and I was wondering what exactly the “Refresh token lifetime is” setting does? I’m just playing around with it and set it to 7 minutes as per screenshot. However, I noticed that after 7 minutes nothing happens. Is it supposed to sign the user out?

[andrea]

The “Refresh token lifetime” configurable in the access rule can be used to customize how long a refresh token will last after it is issued. If your application is using refresh tokens, they will be issued at the same time the ID and Access tokens are issued, and can be used to request new ID and Access Tokens upon their expiration (that’s why the refresh token lifetime MUST be greater than the access token lifetime in your rule, you’ll see an error if you try to make the refresh token expire before the access token).

As for whether the expiration of the refresh token will result in your user being signed out, that depends on how your application is configured as well as your Org’s general Sign On policy. Our front-end SDKs have two methods they use to extend a user’s session once their refresh tokens expire (powered by the renewToken method):

1. if there is a refresh token available in the tokenManager (offline_access scope requested and allowed for the application), it will attempt to use the refresh token to get new tokens.
2. if there is no refresh token in the tokenManager, or it has expired, the SDK will instead try to use the Okta session cookie in the browser to perform silent token renewal (using AuthJS’s getWithoutPrompt method). This method is reliant on the browser being able to access the ‘sid’ cookie set for an authenticated user on your Okta domain from the domain your application is hosted on. This method can/will fail in browsers that block third party cookies if your application is not hosted on the same domain as your Okta tenant.

Based on the behavior you are seeing, the user is likely remaining logged in due to the presence of the Okta session. The lifetime of the Okta session is part of the Sign On Policy that your user falls under.

To confirm, you can log the user into your app, access the Okta dashboard in another tab to log out of Okta (killing the Okta session), and then wait 7 minutes. You should now see that the users will fail to have their tokens renewed and they will be need to re-authenticate to access your application.

[ReturnOfTheMac]

Thanks @andrea.

I’m testing with a user I created and assigned to the app instead of my own credentials and I don’t think that test user has access to the Okta dashboard but it’s ok because I just tried it in Incognito mode (as it blocks 3rd party cookies) and I can confirm the user was automatically signed out but it was after 9 minutes and not 7 minutes. I don’t see this as a big issue though.

However, I did notice that both the access token and refresh token expiry time is the same even though I have configured them to different times in my Okta access rule. Is this expected?

[andrea]

Yup, we are aware of that. The tokens stored in the tokenManager always have an expiresAt property, but the one listed for the refresh token is only there to meet that requirement, not because the expiresAt listed for the refresh token is accurate. All we do is set the expiresAt for the access token as the expiresAt for the refresh token, again, just to provide a value for that property, but the SDK doesn’t do anything with this value. I believe we have addressed this confusing functionality in Auth JS 5.2.1 and in the next major version, we will be removing this extraneous expiresAt property from refresh tokens.

[ReturnOfTheMac]

Excellent thanks. I’m actually using okta-auth-js version 5.2.2 so it sounds like the issue is still there anyway.

I have one more question on sessions/cookies if you don’t mind; I tested my scenario out in Safari which block 3rd party cookies and it all worked using refresh token rotation so that’s great news! My question though is I could see that the sid cookie was not set which is expected as Safari blocked it. However, I’m curious to know if session expiry set in the sign on policy will work at all in Safari? Will the Okta Dashboard continue to work for example? Will it automatically sign the user out after 2 hours of inactivity? What will happen in my OIDC app? Will it just ignore the session expiry time and use the refresh token lifetime instead?

[andrea]

The sid cookie should still be getting set on the Okta domain (unless you block all cookies), so access to the Okta dashboard should work regardless of the 'Prevent cross-site tracking" option being enabled.

And more or less yes, your OIDC application will function as though there is no session cookie if it can’t access it and will be reliant on the refresh token to keep the user logged in.