Add a global session policy rule

Rules describe the conditions of policy behavior, like requests from a geographical location or whether the user is on or off a trusted network.

When a user attempts to sign in, they're evaluated by each rule in Priority order until one matches. Be sure that the rules are arranged in an order that restricts access to users with high-risk conditions. Don't prioritize a rule that applies to everyone over one that applies to only users out of zone, because the policy evaluation will stop when it reaches the everyone rule.

There's no limit to the number of rules that a global session policy can have, but it must have at least one.

If you're adding rules to a new policy, start this task at step 4.

  1. In the Admin Console, go to Security > Global Session Policy.
  2. Select the policy that you want to add rules to.
  3. Click Add rule.
  4. In the Rule name field, add a descriptive name for the rule you want to create.
  5. Optional. In the Exclude users field, indicate which individual users of a group you want to exclude from the rule.
  6. Indicate your conditions.
    IF User’s IP is

    Use the dropdown menu to assign location parameters.

    • Specify whether Anywhere, In zone, or Not in zone will prompt authentication.
    • For In zone or Not in zone, you can choose All Zones or specify individual zones. Click Manage Configurations for Network to see your current gateway settings. To add new ones see Create zones for IP addresses and Create a dynamic zone.
    AND Identity provider is

    Use this dropdown menu to specify an identity provider.

    • Any: Select this option to use either Okta or Specific IdP as the identity provider.
    • Okta: Select this option to use only Okta as the identity provider.
    • Specific IdP: Select this option to use an identity provider that you specify. Click the second field to select an identity provider. If the one you want isn't listed, see Add a social login (IdP).

    Note: This is an Early Access feature. To enable it, contact Okta Support.

    AND Authenticates viaUse this dropdown menu to specify the required means of authentication.
    AND Behavior is

    Enter a behavior type or a named behavior. For high-risk behaviors, be sure to set your MFA requirement to At every sign in. Don't combine a behavior condition with a per device or per session MFA requirement.

    See About Behavior types.

    AND Risk is

    Select a risk level of Low, Medium, or High. If you select High, be sure to set your MFA requirement to At every sign in. Don't combine a high-risk level with a device or session MFA requirement.

    See Risk scoring.

    THEN Access isBased on the authentication form of the previous dropdown list, use this one to establish whether the condition allows or denies access.
    AND Establish the user session with

    Select A password or Any factor used to meet the Authentication Policy requirements.

    See Set up passwordless sign-in experience.

    Multifactor authentication (MFA) is

    Indicate whether multifactor authentication is required or not.

    Users will be prompted for MFA

    This option appears when you select Required for the Multifactor authentication (MFA) is option. If users are required to use multifactor authentication, indicate when they are prompted to use it:

    • At every sign in: Users are challenged for multifactor authentication every time they sign in to Okta. This option is suitable for use with behavior conditions, which detect high-risk sign-in events.
    • When signing in with a new device cookie: Users are challenged for multifactor authentication whenever they attempt to sign in with a new device, or if the cookie has been removed from their existing device. Because it allows users to bypass MFA if they appear to be signing in from the same device (based on a browser cookie), it's only appropriate for low-risk, low-assurance use cases. It shouldn't be used with behavior conditions.
    • After MFA lifetime expires for the device cookie: Users are challenged for multifactor authentication when they attempt to sign in after the MFA lifetime period has expired. You can set both MFA lifetime and a session lifetime, but be aware that MFA lifetime is only enforced when a new session is created or if the user changes devices.
      • MFA lifetime: This option appears when you select After MFA lifetime expires for the device cookie. Type a numerical value in the field on the right, then select a value from the dropdown list (Days, Hours, Minutes).

    Max Okta session lifetime

    Configure an Okta session lifetime, or none:

    • No time limit: If you select this option, there is no time limit applied to Okta sessions, but user sessions will still expire when the idle time is reached.

    • Set time limit: Set a time limit to Okta session lifetimes. Type a numerical value in the field on the right, then select a value from the dropdown list (Days, Hours, Minutes).

    Max Okta session lifetime is only appropriate for low-risk, low-assurance use cases and shouldn't be used with behavior conditions or risk conditions.

    Expire session after user has been idle on Okta for

    Configure the amount of idle time that passes before Okta sessions are automatically expired, regardless of the maximum Okta session lifetime:

    • Type a numerical value in the field on the right, then select a value from the dropdown list (Days, Hours, Minutes).

    Persist session cookies across browser sessions

    This option appears if you set the usePersistentCookie option in the Okta API. See Session and persistent Single Sign-On.

    Enable or disable the persistence of session cookies across browser sessions. Select an option from the dropdown list:

    • Enable: Allow session cookies to persist across browser sessions if users wish to do so. Users must select Keep me signed in on the Sign-In Widget to enable this functionality.

    • Disable: Don't allow session cookies to persist across browser sessions.

  7. Click Create Rule.

Keep me signed in

Okta allows admins to create global session policies that can minimize login friction for the user.

Admins can allow the use of Persistent Cookies, which maintains the user's Okta session cookie on the device even after the browser session is quit. Admins can also specify how often a user is prompted for a second factor when signing in to Okta. End users can opt in to this functionality by selecting Keep me signed in on the sign-in widget; this check box retains the end user’s identifier and authenticator verification information on their device for the amount of time designated by the global session policy.

Authenticator verifications are cleared for end users when they sign out or when their session expires. Users who select the Keep me signed in check box are still required to pass MFA at least once on their current device.

MFA settings

When the global session policy rule is set to Users will be prompted for MFA, After MFA lifetime expires for the device cookie:

Users are challenged for multifactor authentication when they attempt to sign in after the MFA lifetime period has expired. You can set both MFA lifetime and a session lifetime, but be aware that MFA lifetime is only enforced when a new session is created or if the user changes devices, even if users select Keep me signed in.

When the global session policy is set to Users will be prompted for MFA and MFA Lifetime is set:

Users won’t be prompted to verify additional authenticators based on the MFA Lifetime that is set in the global session policy.

For example, if the MFA Lifetime is set to 10 days, after 10 days the user is prompted for secondary authenticators. When the user’s session expires, or after they sign out of the session, they’re prompted for a primary authenticator.

When the global session policy is set to Any factor used to meet the Authentication Policy requirements:

Password can’t be used a secondary authenticator, and passwordless authentication is not available.

When the global session policy is set to A password:

Security Question can be used as a secondary authenticator only for MFA/SSO. Okta recommends against using security questions in any authentication flow.

About persistent cookies

When a persistent cookie is set for a global session policy rule, the Keep me signed in functionality persists the session cookie in the browser so the user stays signed in after the browser closes.

Note

Global Session Policy persistent cookies can only be configured by setting the usePersistentCookie option in the Okta API. See Session and persistent Single Sign-On.

When the usePersistentCookie is configured:

  • The API sets a cookie that lasts across browser sessions. If a user quits their browser and reopens the browser, the browser session is persisted unless the user has signed out.
  • The persistent cookie is valid until the session expires according to settings in the global session policy.
  • Persistent cookies are never set for Okta admins.

Notes about global session policy rules

  • The global session policy controls how long an overall session is valid, but re-authentication frequency is controlled by authentication policy rules.
  • An end user’s session expires according to the setting in the global session policy. At this point, end users must re-authenticate, regardless of whether they selected the Keep me signed in option when signing in.
  • When the AND Authenticates via condition is set to LDAP, the AND Establish user session with selection has no effect. LDAP interface bind requests may still require a username and password with MFA information. See Use multifactor authentication with the LDAP Interface.

Related topics

Global session policies

Authentication policies

Registration of end users