Okta cutover: Do existing application sessions drain naturally or require forced re-authentication?

Context

A small application currently authenticates via a legacy IdP and is being migrated to Okta using phased routing rules. The goal is zero-downtime cutover without forcing all users to log in again at the moment of switch-over.

Unresolved behavior

Okta routing rules evaluate only at authentication time. Users who already hold a valid application session cookie or long-lived refresh token never redirect to Okta after the routing rule flips to Okta-only. Okta’s Session API and prompt=login parameter cannot reach those users because the application’s session store is opaque to Okta. Documented guidance recommends shortening the application’s session TTL before cutover, but no Okta feature enforces or coordinates this change across the application layer.

Constraints

• Application framework controls session lifetime (cookie max-age, sliding expiration, refresh-token rotation).
• Legacy IdP sessions and Okta sessions exist independently; no atomic revocation mechanism spans both.
• OIDC front-channel logout requires the application to implement a logout endpoint and only triggers after the user visits Okta.

Which application-session configurations guarantee that all active sessions drain within a predictable window after the routing rule switches to Okta-only? Does Okta provide any hook or event that the application can consume to proactively invalidate its own sessions at cutover? What is the maximum session-drain duration if the application relies solely on TTL expiry without code changes?