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, each rule in the policy evaluates the sign-in attempt 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. For example, place a rule that applies only to users outside of a network zone over a rule that applies to everyone. The policy evaluation stops 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.
- In the Admin Console, go to .
- Select the policy that you want to add rules to.
- Click Add rule.
- In the Rule name field, add a descriptive name for the rule you want to create.
- Optional. In the Exclude users field, indicate which individual users of a group you want to exclude from the rule.
-
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 prompts 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 Configure a network 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. See Add a social login (IdP).
Note: This is an Early Access feature. To enable it, contact Okta Support.
AND Authenticates via Use 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 is Based on the authentication form of the previous dropdown list, use this one to establish whether the condition allows or denies access. Establish the user session with Select an option for establishing user sessions:
- A password: Require a password to establish user sessions.
- Any factor used to meet the Authentication Policy requirements: Require an authenticator that the authentication policy includes to establish user sessions.
Users can also sign in to Okta without the use of a password. See Set up passwordless sign-in experience.
Multifactor authentication (MFA) is
Indicate whether multifactor authentication is required. See Multifactor authentication.
Note the following conditions:
- If you selected Any factor used to meet the Authentication Policy requirements and that policy requires a password, it's considered the primary factor. Your secondary factor can't be a knowledge-based factor such as security question.
- If you want your secondary factor to be a security question, your primary factor must be A password. This combination works for MFA/SSO flows only. Okta recommends not using security questions in authentication flows.
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're 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 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 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).
Maximum Okta global session lifetime
Configure an Okta session lifetime:
No time limit: If you select this option, there's no time limit applied to Okta sessions, but user sessions 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).
You can set the session lifetime for the Admin Console independently of this global setting.
This setting is only appropriate for low-risk, low-assurance use cases and shouldn't be used with behavior conditions or risk conditions.
Maximum Okta global session idle time
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).
You can set the timeout for the Admin Console independently of this global setting.
Okta global session cookies persist across browser sessions
This option appears if you set the
usePersistentCookieoption 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. Users must select Stay signed in on the Sign-In Widget to enable this functionality.
Disable: Don't allow session cookies to persist across browser sessions.
- Click Create Rule.
Persistent cookies
When a persistent cookie is set for a global session policy rule, the Stay signed in functionality persists the session cookie in the browser so the user stays signed in after the browser closes.
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.
- 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 authentication policy rules control the re-authentication frequency.
- An end user's session expires according to the setting in the global session policy. At this point, end users must reauthenticate, regardless of whether they selected the Stay signed in option when signing in.
- When the AND Authenticates via condition is set to LDAP, the
ANDEstablish 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.