Configure an Okta sign-on policy

The Okta sign-on policy determines who can access Okta, where they can access Okta from, and how they must prove their identity. To create an Okta sign-on policy, you create a policy and then add rules to it.

By default, Okta provides one default Okta sign-on policy in the list. You can customize the settings of this policy and apply it to all users in your organization as a catch-all policy. Then you can add additional Okta sign-on policies and apply them to specific groups of users. For example, you can specify that a certain group of users may only sign in to Okta from specific network zones, how they must authenticate, the length of their session, and more.

Okta evaluates policies in the order in which they appear in the list, starting at the top of the list. Okta tests the sign-in attempt against each policy until it finds a policy that the sign-in attempt can satisfy. If the sign-in attempt doesn't satisfy the requirements of any of your custom policies, Okta tests the attempt against the default Okta sign-on policy. If the sign-in attempt satisfies the requirements of any policy, no other policies are tested and the user may access Okta. Okta recommends that you order your policies with the most restrictive one at the top of the list, the least restrictive one second from last in the list, and the default Okta sign-on policy at the bottom of the list.

  • After you've created a Okta sign-on policy, you must close all active sessions for the new policy to take effect.
  • Okta sign-on policies don't affect API token validity or lifetime. See Manage Okta API tokens

Create an Okta sign-on policy

  1. In the Admin Console, go to SecurityAuthentication.

  2. Click the Sign On tab.

  3. Click Add New Okta Sign-on Policy.

  4. Complete these fields:

    • Policy Name: Enter a name for the sign-on policy.

    • Policy Description: Optional. Enter a description for the Okta sign-on policy.

    • Assign to Groups: Enter the name of a group to which the policy should be applied. The policy can be applied to multiple groups.

  5. Click Create Policy and Add Rule.

Add an Okta sign-on policy rule

  1. Click Add Rule to add a rule to a policy. Complete the following fields as needed.

Rule name Add a descriptive name for the rule that you want to create.
Exclude users If needed, you can exclude individual users of a group from the rule.
IFUser's IP is Use the dropdown menu to assign location parameters. You can specify what kind of location prompts authentication. See Network zones and Dynamic zones.
ANDIdentity provider is

Select the Identity Provider that you want to use. See Identity Providers for information.

ANDAuthenticates via Select the required means of authentication.
ANDBehavior is

Type the name of an existing behavior that was previously created. To add a behavior, start typing a behavior name; a dropdown list of all matching defined behaviors appears from which you can select the behavior. Repeat for each additional behavior you want to add. When you add multiple behaviors, they're treated as OR conditions. See Add a behavior to a sign-on policy rule.

For high-risk behaviors, be sure to set your secondary factor requirement to Every time. Don't combine a behavior condition with a per device or per session secondary factor requirement.

Okta recommends re-authentication every time for the Okta Admin Console.

ANDRisk is

Risk scoring uses a data-driven risk engine to determine whether each sign-in event is likely to represent unusual activity. Select a risk level of Low, Medium, or High.

If you select High, be sure to set your secondary factor requirement to Every time. Don't combine a high-risk level with a per device or per session secondary factor requirement.

See Risk scoring.

THENAccess is Based on the authentication form of the previous dropdown list, use this one to establish whether the condition allows or denies access.

Authentication

Indicate whether multifactor authentication is required.

Users will authenticate with

Select how users authenticate:

  • Password / Any IdP: Use a password and any Identity Provider configured for your org.

  • Password / Any IdP + Any authenticator: Use a password and any Identity Provider configured for your org, and any factor configured for your org.

  • Factor Sequence: Specify the sequence of MFA factors that users see when they sign in to Okta. See MFA Factor Sequencing for instructions.

Users will be prompted for MFA

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.
  • When signing in with a new device cookie: Users are challenged for MFA when they attempt to sign in with a new device, or if the cookie has been removed from their existing device. If users select Do not challenge me on this device again on the Sign-In Widget and authentication is successful, MFA is remembered for the device cookie. As long as the device cookie is valid, users aren't prompted for MFA when they sign in.
  • 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. If users select Do not challenge me on this device again for the next time on the Sign-In Widget and authentication is successful, MFA is remembered for the device cookie. As long as the device cookie is valid, users aren't prompted for MFA when they sign in.
    • 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).
  • Select "Don't prompt me again for MFA" by default: Select this option to not prompt users for multifactor authentication by default.

Session Lifetime

Configure the duration of Okta sessions.

Maximum Okta session lifetime

Configure an Okta session lifetime, or none:

  • 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. See Configure Admin Console session lifetime.

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).

You can set the timeout for the Admin Console independently of this global setting. See Configure Admin Console session lifetime.

Persist session cookies across browser sessions

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 want 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.

You can set the maximum session lifetime number through the Okta API. If you previously set this number with the API, you can't exceed that maximum here in the Okta app. Setting a number over the API maximum results in an error.

If you add multiple Okta sign-on policies, only the first one that matches your criteria are applied.

Universal Okta sign-on policy actions

  • Change the order of all policies except the default policy by grabbing the dotted bar next to the policy name, as shown to the left of policy 1, and moving the policy to the desired position in the list.

  • Change the order of rules within a policy by grabbing the bar to the left of a rule name.
  • Add a new policy by selecting Add New Okta Sign-On Policy.

Individual Okta sign-on policy actions

You can perform the following actions on a single policy. Select the policy in the list to begin.

  • Activate or deactivate the selected policy. If you deactivate a policy, it isn't applied to any user, but you can reactivate it later.
  • Click Edit to edit the policy.
  • Click Delete to delete a policy. You can't delete the default policy. A deleted policy can't be recovered.
  • Click Add Rule to add a rule to the selected policy. Within a policy, you can activate, deactivate, edit, or delete a rule.
  • To view details about a rule, click the rule name under Add Rule.

Pre-auth sign on evaluation policy

End users that sign in using the AuthN API will have their sign-on policies evaluated first before their password or other factor is verified. This evaluation helps to reduce the number of account lockouts that occur across an org.

If the sign-on policy is set to deny, the user's sign-on attempt is rejected and prompted with the following generic error: Authentication failed. In this scenario, the counter for failed logins isn't incremented but instead, an event indicating that a pre-auth sign-on policy evaluation has been triggered.

  • There are no visible UI changes or required setup in the Admin Console to enable this back-end feature.
  • This policy doesn't work on initial authentication for newly created accounts that are configured to use JIT provisioning. The end user account must exist in Okta for it to be affected by this policy.
  • This policy doesn't prevent users from resetting their credentials from a denied location.

Related topics

Okta sign-on policies

MFA enrollment policies

Password policies

App sign-on policies

Configure an MFA enrollment policy

Configure an app sign-on policy

Configure a password policy