Enforcing Okta IP Restrictions After Initial Authentication

Okta evaluates network policies during the initial authentication process, allowing active application sessions to persist even if an end-user moves to an unauthorized network. Enforcing continuous IP restrictions requires implementing aggressive token lifetimes for OpenID Connect (OIDC) applications, utilizing Continuous Access Evaluation (CAEP), or configuring application-side session controls.

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Network Zones
• Sign-on Policies
• Session Management

How does Okta handle session evaluation upon network changes?

Okta evaluates policy controls, such as IP restrictions and Network Zones, during the initial login process. Okta does not directly terminate active sessions in most Software as a Service (SaaS) applications when a network change occurs post-authentication.

Implement aggressive token lifetimes for OpenID Connect applications.

Shorten the Access Token lifetime for OpenID Connect applications to force Okta to re-evaluate sign-on policies during the token refresh process.

• When the application uses the Refresh Token to request a new Access Token, Okta re-evaluates the sign-on policies.
• If the IP address changes to an unauthorized network, Okta denies the refresh request and terminates the application session.
• NOTE: This method does not apply to Security Assertion Markup Language (SAML) applications, which rely on long-lived cookies after the initial assertion.

Utilize Continuous Access Evaluation and Shared Signals.

Leverage Continuous Access Evaluation integrations to allow Okta to send security events to downstream applications and terminate sessions based on real-time risk profile changes.

• Okta sends a security event to the downstream application alerting it of an IP address or risk profile change.
• The application receives the signal and prompts a session termination.

What application-side controls enforce IP restrictions?

Bind session cookies to originating IP addresses or set aggressive idle timeouts to enforce network restrictions directly within the application codebase or native security settings.

• Configure the application to bind the session cookie to the originating IP address.
• If a request presents a valid cookie from a different IP address, the application forces re-authentication.
• Set aggressive idle timeouts directly within the application settings.
• NOTE: This creates a decentralized security model requiring individual configuration across every application in the technology stack. Examples of applications with native security settings include Salesforce and Amazon Web Services (AWS).

Adopt Zero Trust architecture and device posture checks.

Evaluate continuous device trust rather than static IP addresses by pairing Okta with a Secure Access Service Edge (SASE) solution or Endpoint Detection and Response (EDR) tools.

• Pair Okta with a SASE or Cloud Access Security Broker (CASB) solution.
• Integrate EDR tools (for example, CrowdStrike or Microsoft Defender) to continuously evaluate device posture.