<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
System Status
Announcements
Announcements
Search
Search
Select Language
Knowledge Base
Knowledge Articles
Support Videos ↗
Documentation
Product Documentation ↗
Developer Documentation ↗
Product Release Notes ↗
Community
Events & Webinars
Okta Ideas ↗
Resources
Product Hub
Customer Success Hub
Product Release Update
Learning
Okta Learning ↗
Get Support
Open a Case
HomeCommunityForum
0D5WR00001edFfy0AEOkta Classic EngineAuthenticationAnswered2026-05-18T22:16:37.000Z2026-05-15T01:20:01.000Z2026-05-18T22:16:37.000Z

ShoichiroK.00155 (LAC Co., Ltd) asked a question.

May 15, 2026 at 1:20 AM
Best practices for handling active app sessions when moving to an unauthorized network post-login

Hi everyone,

 

I am looking for some advice regarding session management and IP restrictions.

 

Currently, once a user logs into an application via Okta from an authorized network, they can continue to use the app even if they move to an unauthorized network, as long as the application session remains active.

 

Does anyone have insights or experience dealing with this issue?

 

My understanding is that Okta's policy controls (such as IP restrictions/Network Zones) are evaluated only during the initial Okta login. They do not affect the active session on the application side once the authentication is complete.

 

Therefore, I believe the possible solutions would be one of the following:

 

Configuring network controls (IP restrictions) or session timeouts directly on the application side.

Implementing security solutions like CASB or SASE to control access at the network traffic level.

If there is any way to achieve this using only Okta's features/settings, or if you have any other best practices to share, I would greatly appreciate your guidance.

  • 1 answer
  • 29 views

  • Paul S. (Okta, Inc.)

    Hello @ShoichiroK.00155 (LAC Co., Ltd)​ Thank you for posting on our Community page!

     

    While Okta cannot directly reach into most SaaS apps to kill a session upon a network change, there are a few ways to force re-evaluation closer to real-time:

    • Aggressive Token Lifetimes (OIDC/OAuth Apps Only): If your application uses OIDC, you can shorten the Access Token lifetime (e.g., to 5 or 15 minutes). When the app uses the Refresh Token to get a new Access Token, Okta will re-evaluate the sign-on policies. If the user's IP has changed to an unauthorized network, Okta will deny the refresh, effectively killing the app session. (Note: This does not work for SAML apps, which rely on long-lived cookies post-assertion).
    • Continuous Access Evaluation (CAEP) / Shared Signals: Okta is heavily investing in the Shared Signals Framework. If your downstream application supports CAEP, Okta can send a security event to the app alerting it that the user's risk profile or IP has changed, prompting the app to terminate the session. Support for this is currently limited but growing among major SaaS providers.

    Application-Side Controls (IP Binding / Shorter Sessions)

    • How it works: You configure the application to bind the session cookie to the originating IP address. If a request comes in with a valid cookie but a different IP, the app forces a re-authentication. Alternatively, you simply set aggressive idle timeouts on the app side.
    • Best for: Custom-built applications where you control the codebase, or SaaS apps with robust native security settings (like Salesforce or AWS, which both support IP-session binding).
    • Drawback: It creates a decentralized security model. You have to configure and maintain these rules individually across every application in your stack.
    •  

    The Recommended Best Practice

    In a modern Zero Trust architecture, relying strictly on network perimeters (IP restrictions) is generally discouraged in favor of device posture and continuous authentication.

    If you are trying to ensure that corporate data is only accessed from secure environments, the best practice is to pair Okta with a SASE/CASB solution or an Endpoint Detection and Response (EDR) integration (like CrowdStrike or Microsoft Defender). This allows you to evaluate device trust continuously, rather than just IP addresses, which fluctuate easily in a remote-work world.

     

    Thank you for reaching out to our Community and have a great day!

    --

    Help others in the community by liking or hitting Select as Best if this response helped you.

    Expand Post
    Selected as Best

  • Paul S. (Okta, Inc.)

    Hello @ShoichiroK.00155 (LAC Co., Ltd)​ Thank you for posting on our Community page!

     

    While Okta cannot directly reach into most SaaS apps to kill a session upon a network change, there are a few ways to force re-evaluation closer to real-time:

    • Aggressive Token Lifetimes (OIDC/OAuth Apps Only): If your application uses OIDC, you can shorten the Access Token lifetime (e.g., to 5 or 15 minutes). When the app uses the Refresh Token to get a new Access Token, Okta will re-evaluate the sign-on policies. If the user's IP has changed to an unauthorized network, Okta will deny the refresh, effectively killing the app session. (Note: This does not work for SAML apps, which rely on long-lived cookies post-assertion).
    • Continuous Access Evaluation (CAEP) / Shared Signals: Okta is heavily investing in the Shared Signals Framework. If your downstream application supports CAEP, Okta can send a security event to the app alerting it that the user's risk profile or IP has changed, prompting the app to terminate the session. Support for this is currently limited but growing among major SaaS providers.

    Application-Side Controls (IP Binding / Shorter Sessions)

    • How it works: You configure the application to bind the session cookie to the originating IP address. If a request comes in with a valid cookie but a different IP, the app forces a re-authentication. Alternatively, you simply set aggressive idle timeouts on the app side.
    • Best for: Custom-built applications where you control the codebase, or SaaS apps with robust native security settings (like Salesforce or AWS, which both support IP-session binding).
    • Drawback: It creates a decentralized security model. You have to configure and maintain these rules individually across every application in your stack.
    •  

    The Recommended Best Practice

    In a modern Zero Trust architecture, relying strictly on network perimeters (IP restrictions) is generally discouraged in favor of device posture and continuous authentication.

    If you are trying to ensure that corporate data is only accessed from secure environments, the best practice is to pair Okta with a SASE/CASB solution or an Endpoint Detection and Response (EDR) integration (like CrowdStrike or Microsoft Defender). This allows you to evaluate device trust continuously, rather than just IP addresses, which fluctuate easily in a remote-work world.

     

    Thank you for reaching out to our Community and have a great day!

    --

    Help others in the community by liking or hitting Select as Best if this response helped you.

    Expand Post
    Selected as Best

Loading
Best practices for handling active app sessions when moving to an unauthorized network post-login