How to auto-refresh Okta session based on issuance of refresh token?

[ashlin_jude]

We have multiple applications that wants to use Okta for SSO. Each application has a different SSO mechanism like SAML and JWT. My app uses JWT tokens - both refresh and access token, and I would like to know if there is a way to keep the Okta session alive when refresh or access tokens are issued.

Below is a scenario.
System: App1 and App2 are trying to do SSO using Okta. App1 uses JWT. App2 uses SAML.
Assumption: Okta session lifetime is 30 mins. Refresh token lifetime is 1 hr and Access token lifetime is 15 mins.
Steps:

1. User logs into app1 and continues using the app for an hour. By this time the Okta session has expired.
2. User then clicks a link that takes them to app2 but since Okta session has expired, they are asked to login again.
   Step 2 may not be a great user experience for us because we are asking the user to re-login when they have been active in one of the apps. In other words, SSO only works for 30 mins which is the lifetime of the Okta session. So below are my questions.

Questions:
a) Based on other threads, it looks like Okta session does not extend automatically when a refresh token is issued. Is this accurate? We use refresh token rotation as well.
b) Can refreshing the session be configured in Okta itself instead of the app having the responsibility to keep the Okta session alive?
c) If the app should do this, are there any recommendations/documentation from Okta regarding the best way to implement it?
d) Since tokens should be stateless, self contained and independant, is it a good design to auto refresh Okta session when refresh tokens are issued? Or is it better to allow users to continue using the app even if their Okta session has expired because they have a valid refresh token?

This is probably too many questions (sorry) but I would really appreciate the community’s help. I read threads on this topic but they dont address these questions directly, so I thought I would create a new one. If you need additional information, please let me know and I am happy to provide.

[andrea]

a) Correct, refresh tokens do not affect the Okta session lifetime. Only hits to the Okta domain itself, whether that’s the user actively integrating with their Okta dashboard or the user logging into a new application from scratch (such as with an /authorize request), will extend the user’s Okta session. The application session is separate. Refresh token rotation doesn’t factor into this and is just a setting to make refresh tokens more secure for SPAs (where the refresh token will be exposed in the network events from the user’s machine).
b) The application does not need to keep the Okta session alive unless it is reliant on this session to keep the user logged (e.g, kicking off a new OAuth flow to get tokens instead of using refresh tokens to keep them logged in)
c) see above about the sessions being handled separately
d) I don’t see a real reason to do this. Either the Okta session lifetime is long enough that the user is able to log into multiple applications without needing to re-authenticate (say, logging into App A in the morning and then App B in the evening) so they have a good experience, or they just need to re-authenticate because they have not interacted with the IdP recently enough. This is going to come down somewhat to your security stance about how frequently you want them to re-auth.

Final note is that the user can refresh their own session (based on the session cookie they have set in the browser) using this request: Refresh current Session | Okta Developer. So if they do need to remain logged in to Okta based on their activity within your app(s), you can help extend the idle lifetime (note that the max session lifetime will still apply regardless).