Currently, an absolute timeout is only supported for the Okta Session. The feature isn’t exposed in the admin portal, but you can configure it via an API call. The parameter is called maxSessionLifetimeMinutes. See https://developer.okta.com/docs/reference/api/policy/#signon-session-object.
The problem is that when this timeout occurs, and the user’s session is terminated, their refresh and access tokens are still valid.
If the access token lifetime is 15 minutes, and the refresh token lifetime is 1 hour, then every 15 minutes I can use the refresh to get a new access token and a new refresh token. However this means that the 1 hour lifetime of the refresh token is reset every 15 minutes, leading to no enforcement of an absolute timeout, and a 1 hour idle timeout.
How can I implement an absolute timeout for an OIDC/OAuth application?
I think it’s a common misconception, that access_token or id_token should be linked to session lifetime. They may be used for this purpose, but you just need to be aware of the limitations of this approach.
The application is responsible for its own session management, as Okta is responsible for its. Sorry to disappoint you, maybe, but OIDC/OAuth doesn’t tell anything about session management. There is only a draft for this - https://openid.net/specs/openid-connect-session-1_0.html from which you may want to grab few ideas and use it for your session management on a client side.
@phi1ipp Actually, I just realized that when making a call to /token with the refresh_token grant_type, it does not return you a new refresh token, it just returns you back the same refresh token along with the new access token. So effectively the absolute timeout would be then be tied to the Okta IDP session timeout since once the refresh token expires you would be forced to hit /authorize. Right?
According to the spec https://tools.ietf.org/html/rfc6749#section-6 “The authorization server MAY issue a new refresh token, in which case the client MUST discard the old refresh token and replace it with the new refresh token. The authorization server MAY revoke the old refresh token after issuing a new refresh token to the client.”
It appears that Okta does NOT issue a new refresh token. I just want to verify that this is Okta’s behavior from your experience as well.
@cat,
It will issue a new one, when the old one is about to expire. I’m not sure when exactly it’s happening, but you can try to set your refresh token lifetime to some meaningful small amount of time and retry your /token request a minute before it’s about to expire.
@phi1ipp I just tested this and found that a new refresh token was never issued. This behavior was confirmed by @vijethere as well.
So in that case the absolute timeout is tied to the refresh token lifetime set on the authorization server. You can choose an idle timeout by setting the “expire if not used” time on the authorization server to be something between the access token lifetime and the refresh token lifetime.
When the refresh token expires, you will be forced to hit /authorize which requires an active Okta browser Session.