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 is only allowed to sign in to Okta from specific network zones, how they must authenticate, the length of their session, and more.
Okta sign-on policies are evaluated in the order in which they appear in the list of policies, 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 is allowed to 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 have created a new Okta sign-on policy, you must close all active sessions for the new policy to take effect.
- Okta sign-on policies do not affect API token validity or lifetime. See API token management
Create an Okta sign-on policy
In the Admin Console, go to Security >Authentication.
Click the Sign On tab.
Click Add New Okta Sign-On Policy.
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.
Click Create Policy and Add Rule.
Add an Okta sign-on policy rule
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 you want to create.|
|Exclude users||If needed, you can exclude individual users of a group from the rule.|
||Use the drop-down menu to assign location parameters. You can specify what kind of location will prompt authentication.|
||Use this drop-down list to specify the required means of authentication.|
Type the name of an existing behavior that was previously created. To add a behavior, start typing a behavior name; a drop-down 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 are 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.
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.
||Based on the authentication form of the previous drop-down menu, use this one to establish whether the condition allows or denies access.|
|Prompt for Factor:||
Appears as available only when at least one factor type is enabled.
Indicate when a factor prompt appears.
|Manage configuration for Multifactor Authentication:||Click Manage Configurations for Multifactor Authentication for quick access to the Authentication page and the Multifactor tab. See Configuring Multifactor Authentication for details about each of the authentication options. Select the box to display radio buttons that determine whether the prompt is triggered per a device, at every sign-on, or per a session time that you specify. When specifying per session, note that sessions have a default lifetime as configured, but sessions always end whenever users sign out of their Okta session.|
Specify how much time must elapse before the user is challenged for MFA. The maximum period is 6 months. If you require MFA frequently across all apps, create a shorter session expiration and set your Prompt for Factor condition to Every time.
|Session expires after||Use this drop-down menu to specify the maximum idle time before an authentication prompt is triggered. The maximum allowed time for this option is 90 days. This is not the total connect time. The default session lifetime is 2 hours. This is idle time before users see a countdown timer at the five-minute mark of remaining session time.|
You can set the maximum session lifetime number through the Okta API. If you previously set this number with the API, you cannot exceed that maximum here in the Okta app. Setting a number over the API maximum will result in an error.
If you add multiple Okta sign-on policies, only the first one that matches criteria you selected will be 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 below, 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 will not be applied to any user, but you can reactivate it later.
- Click Edit to edit the policy.
- Click Delete to delete a policy. You cannot delete the default policy. A deleted policy cannot 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.
If you check the Prompt for Factor checkbox, as shown below, three options appear that affect how end users are prompted for MFA in a given session.
Two of these options allow end-users to control these prompts while one disallows it.
- Per Device: provides the option Do not challenge me on this device again on the end user MFA challenge dialog. This option allows prompts solely for new devices.
- Every Time: end users are prompted every time they sign in to Okta and cannot influence when they are prompted to provide a factor.
- Per Session: provides the option Do not challenge me on this device for the next (minutes/hours/days) on the end user MFA challenge dialog box. You specify the Factor Lifetime in the accompanying Factor Lifetime field. When specifying per session, note that sessions have a default lifetime as configured, but sessions always end whenever users sign out of their Okta session.
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 is not 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 does not work on initial authentication for newly created accounts that are configured to use JIT provisioning. The end user account must already exist in Okta for it to be affected by this policy.
- This policy does not prevent users from resetting their credentials from a denied location.