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.
- In the Admin Console, go to Security > Global Session Policy.
- 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 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 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. 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 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. AND Establish the user session with
Select A password or Any factor used to meet the Authentication Policy requirements.
Multifactor authentication (MFA) is
Indicate whether multifactor authentication is required. Note the following conditions:
- If you selected Any factor used to meet the Authentication Policy requirements and that policy requires a password, it is considered the primary factor. Your secondary factor can't be A password.
- 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 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
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 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.
- Click Create Rule.
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.
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.
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.
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
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.