Token lifemes Options and interactions

Questions
1

I am trying to make sense of how the various timers interact to affect the end user experience.

With a custom auth sever I know:

Access tokens: The minimum is five minutes, and the maximum is 24 hours
Refresh tokens: The minimum access token lifetime. The idle time window is at least 10 minutes, with a maximum of five years
ID tokens: Not configurable. Token lifetime is 60 minutes.

Also the Session life time can be configured. (Default 2 hours)

In the client code:

When configuring the pipeline in startup we can set the CookieAuthenticationOptions property ExpireTimeSpan to a time range.

When calling the challenge method we can set the the ExpiresUTC property of the AuthenticationProperties to a time value.

Its unclear how to adjust these to control several areas of concern.

  1. Idle timeout: If a user is inactive for 20 minutes we would like the user to be logged out. Right now the time a user can be inactive is much longer and my tinkering with the settings haven’t produced an obvious candidate to control this behavior clearly.

  2. Login Redirect target lifetime: After logging out of our app we redirect to the okta login page. For a period of time, that login page will remember to redirect back to our app when it is used next to login. But after some number of minutes this data seems to expire and now if the user logs in with that login page they are sent to the Okta portal. How can we extend the life of the Login redirect to be as long as possible?

Thank you for any help clarifying how these settings affect the end user experience.
-Gary

2

Idle timeout is a responsibility of your application, as it’s a part of app session management functionality. So manage your session as you like, it’s not Okta’s responsibility

As for the second question: I believe I’ve seen your(?) question here about the same, and I commented there. But what you can do to avoid it, is to land your user on special logout page, so that they are not sent back to Okta every time they log out. Not ideal, but at least it’s something to work with, till the issue? with redirection is fixed

3

Thank you for the reply. Our previous SSO managed our idle timeout.
I will look into managing this instead.

I did post once before asking about the state login page but never had any replies.

Thank you for logged out page idea. We may do that. Some related issues came up today such that we are rethinking about logout in a multi-app environment. So this issue may end up being sidestepped.