SPA: autoRenew without refresh tokens

Questions OAuth/OIDC
,
1

Hi, I’m developing integrating Okta into an existing SPA using okta-vue (moving from Google workspace auth), it’s going well. I am really pleased with the navigation guard, it’s allowing us to simplify the code significantly.

There’s one part which I need to understand better. We would like sessions to last longer than one hour without a user needing to log in again, but without using refresh tokens … (for the sake of testing, I’m working with 2 hours, but it’ll be more like 6 hours once we’ve confirmed the behaviour). ID tokens are the standard 1 hour. It seems to work well, but I don’t understand exactly why.

So, even though we don’t use refresh tokens, the Auth JS SDK fetches new tokens every hour. The SDK fetches new tokens (using grant_type: authorization_code along with a code + code verifier).
After 2 hours, the navigation guard redirects the user to an Okta login prompt.
This is great, but I just need to be able to explain it.

I guess the original authentication response delivered this authorization code’s code + code_verifier via okta.com cookies? And I figure the SDK knows to keep on doing this until the application’s Auth Policy states that the session should end? (The auth policy is currently set to 2 hours, and the navigation guard seems to kick in at that time).

Some info about the integration:

  • Application Type: SPA, OIDC
  • Grant type: Authorization Code (NOT refresh token)
  • No custom auth servers: the org does not have the paid add-on for Custom Auth Servers, so I understand that [everlasting] refresh tokens would not be safe for for this an SPA. The org also can’t alter the time for their ID tokens.
  • PKCE: yes
  • Scopes: none (besides the openid,profile,email used for OIDC authentication).
  • Authentication policy: The org-wide Global policy has a max session time of 11 hours. I have configured this application to use a custom policy with a 2 hour max session time.
  • SDK: okta-vue, with configuration: acrValues: ‘phr’, services.autoRenew: false

So, my questions:

  • Have I understood correctly what’s happening every hour?
  • Did I guess correctly that the SDK stop fetching new tokens as soon as the Auth Policy determines that the session time has reached 2 hours, regardless of whether there has been user activity or not?
  • I configured services.autoRenew: false for now … Strangely, that doesn’t prevent the SDK from fetching a new token. Could you try to explain the distinction between autoRenew, refresh tokens, and the behaviour which I’m observing, please? Is there another name for the ‘re-fetch token’ behaviour which I’m seeing?
  • Are there any docs which cover this style of session renewal, please?

Thank you.

2

Yup, when the user first logs into your application/Okta, an Okta session cookie will be set on the Okta domain, so that users can SSO into this and other applications integrated with Okta.

If there’s not a Refresh Token available, our JS libraries will attempt to renew the tokens “silently” based on the presence of an Okta session. What this means is that, when the users tokens are about to expire (if autoRenew is turned on), Okta will attempt to make an /authorize request in an iFrame to request new tokens for the user (its using getWithoutPrompt() under the hood).

Since its making an /authorize request, it would be dependent on it being able to access the Okta session cookies from within your application, so you can encounter issues with 3rd party cookie blocking if your application is not hosted on the same domain as your Okta org. More information about 3rd party cookie issues discussed here: Okta Help Center (Lightning).

I believe these /authorize requests will extend the user’s Okta session idle lifetime, but they will still observer the max session lifetime if you want to ensure the users are prompted to re-authenticate regularly.

3

Thanks Andrea, that makes sense now. Your thorough explanation is really appreciated…

I have a related question - when it comes to the session times, would you be able to clarify which policy applies when, please?

  • This org has a Global Session Policy with a session time of 11 hours.
  • The application uses its own Authentication Policy with a session time of 2 hours.

Would it be correct to say that someone logging in directly from the app would have the 2 hour limit, but if they were already logged into Okta via some other integration, then their session would continue to last the full 11 hours?

(I have been noticing that sometimes my sessions last beyond the 2 hours, and want to clarify how this could happen - I figure it’s down to I logged into Okta - or possibly it’s related to how I re-authenticated after a session expiry).

Cheers