Okta SSO sessions and app sessions run on different clocks

The problem: logging out of your app doesn't always log out of Okta

A user signs out of your web application. They click the browser back button, and the app silently signs them back in. Or they open a sensitive admin page minutes after their access token expired, and the app refreshes it without asking for credentials again. Both behaviors happen because Okta maintains an organization-level SSO session that is separate from your application's local session.

Okta's SSO cookie can outlive your access token. Your app can issue a short-lived access token while Okta still allows silent token renewal. If you treat Okta's timeout as your app's timeout, you risk keeping users authenticated longer than intended. If you treat them as identical, you may force unnecessary re-login and frustrate users.

Two clocks to configure

Think of two independent timers:

• Okta SSO session: controls how long a user can silently obtain new tokens from Okta without re-entering credentials. Configured at the org level, often split into idle and absolute timeouts.
• Application session and tokens: controls how long your app trusts a logged-in user and how long access tokens remain valid. Controlled by your OIDC client configuration and application code.

Ending one does not automatically end the other. Clearing your app's session cookie does not remove Okta's SSO cookie. Conversely, Okta session expiry does not always invalidate an already-issued access token until that token reaches its own expiry.

Layer	What it governs	Typical control point
Okta SSO session	Silent re-authentication across apps in the org	Okta Admin Console session settings
OIDC access token	API access lifetime issued to your app	Okta authorization server or app integration settings
App local session	Your app's own cookie or store after login	Application code and framework session middleware

Exact defaults and limits depend on your Okta edition, release, and whether Classic Engine or Identity Engine is active. Verify the values in your target org before hardcoding minutes.

Worked example: short tokens with step-up auth

A practical pattern is to pair a longer Okta SSO window with short-lived access tokens, then require fresh authentication for sensitive routes such as payments, user management, or admin actions.

Example configuration to verify in your org:

• Okta SSO absolute timeout: eight hours (placeholder; confirm in Admin Console)
• Okta SSO idle timeout: four hours (placeholder; confirm in Admin Console)
• Application access token lifetime: fifteen minutes (placeholder)
• Sensitive route: force prompt=login or max_age=0

When a user opens a sensitive route, redirect them to Okta with an authorization request that forces re-authentication:

https://{yourOktaDomain}/oauth2/default/v1/authorize
?client_id={clientId}
&response_type=code
&scope=openid profile email
&redirect_uri={redirectUri}
&code_challenge={codeChallenge}
&code_challenge_method=S256
&prompt=login
&max_age=0

Run this redirect from your application's server or browser client after the user clicks a sensitive action. No special shell permissions are required, but the Okta app integration must allow the requested scopes and redirect URI.

Expected check: Okta displays a login prompt even if the user has an active SSO cookie. After successful authentication, Okta returns an authorization code that your app exchanges for a new ID and access token.

Risk: using max_age=0 on every page forces credentials constantly. Reserve it for high-risk actions and fall back to silent renewal for normal navigation.

Diagnose logout and silent renewal

Before changing timeouts, confirm how your org behaves today:

1. Open the Okta Admin Console session settings for your org and record the configured idle and absolute timeouts.
2. Sign in to your app through OIDC, inspect the ID token and access token expiry, then wait or simulate expiry.
3. Use prompt=none in a hidden authorization request after the idle window. If Okta returns login_required or interaction_required, silent renewal is blocked and the user must sign in again.
4. Clear your app's local session cookie, then attempt a silent authorization. If Okta still returns tokens, the SSO cookie is still valid and your app logout did not end Okta's session.

Browser cookie restrictions such as Intelligent Tracking Prevention can also break silent renewal independently of Okta timeouts. Handle renewal errors gracefully by redirecting to a normal login flow rather than showing a raw error.

Trade-offs and limitations

• Changing org-wide Okta session timeouts can affect every application that shares that SSO session, not just your app.
• Short access tokens reduce the window for token misuse but increase token endpoint traffic.
• prompt=login and max_age behavior can vary by Okta release and client implementation; test in a non-production org first.
• Okta session settings are not a substitute for application-level authorization checks on sensitive routes.

Closing checklist

• Verify your org's current idle and absolute SSO timeouts in the Okta Admin Console.
• Set access token lifetimes appropriate for your risk profile.
• Implement prompt=login or max_age for payments, admin routes, and profile changes.
• Test logout in multiple browsers to confirm whether Okta silent re-authentication still works after your app session ends.

Treat Okta SSO and your application session as separate clocks, align them deliberately, and step up authentication where the risk justifies the friction.