Add an authentication policy rule

Authentication policies are built on rules. When you create an authentication policy, it starts with a single catch-all rule that allows access to all requests with any two factor types. Configure your authenticator requirements by adding rules and prioritizing them over the catch-all.

For example, you can add one rule that prompts all users for a password. Then you can add a second rule that prompts users in a specific group for email and password authenticators.

Before you begin

Set up authenticators

Create an authentication policy

Add a rule to a policy

  1. In the Admin Console, go to SecurityAuthentication Policies.

  2. Select the policy where you want to add a rule.
  3. On the Rules tab, click Add Rule.
  4. Enter a Rule Name.
  5. Configure IF conditions. These conditions specify when the rule is applied.
    IFDescription
    IF User's user type isAccept the default or specify user types to include and exclude.
    AND User's group membership includesAccept the default or specify user groups to include and exclude.
    AND User isAccept the default or specify users to include and exclude.
    AND Device state isAccept the default or select Registered to apply this rule only to devices enrolled in Okta Verify. See Device registration.
    AND Device management isIf you selected a Registered device state, indicate whether the rule is applied to only devices managed by a third-party device management solution.
    AND Device assurance policy isIf you selected a Registered device state, you can specify device assurance policies to be satisfied. See Add a device assurance policy.
    AND Device platform isAccept the default or select specific platforms.
    AND User's IP isAccept the default or specify network zones that you want to include or exclude. You can sort by zones defined or not defined in Okta, or by dynamic zones.
    AND Risk isBy default, this rule applies to authentication attempts of any risk level. Selecting a level limits the rule to only the specified risk level. See Risk scoring.
    AND The following custom expression is trueOptional. Specify additional conditions with Expression Language (EL). See About behavior and sign-on policies and Okta Expression Language.

  6. Configure THEN conditions. These conditions specify how authentication is enforced.

    THEN Description
    THEN Access is

    Deny the user's access or allow it after successful authentication. If you deny access, skip to the last step to save your rule.

    • Denied: If the user satisfies the conditions that you configured, deny access. If you choose to deny access, skip to the last step to save your rule.
    • Allowed after successful authentication: If the user satisfies the conditions that you configured, allow access.

    AND User must provide

    This item displays the rule's settings in JSON code. It appears when you've selected these options:

    • Allowed after successful authentication for THEN Access is
    • Any 1 factor type or Any 1 factor type / IdP for AND User must authenticate with
    • Any possession constraint for AND Factor restraints are
    AND User must authenticate with

    Choose the authentication requirements that you want to enforce for app access. For a description of factor types, see Multifactor authentication.

    If IdP appears next to these authentication options, your Global Session Policy has specified an Identity Provider (IdP) that can satisfy the password requirement. Users who authenticate through the specified IdP don't need to also provide a password.

    Early Access release. See Enable self-service features.

    If you have multiple instances of the same authenticator in your org, you can allow a specific authenticator instance in the policy. This authenticator instance is shown to the user when they sign in. For example, if you have two instances of Duo Security configured, you can choose which instance is prompted to the user. If the user hasn't enrolled in that authenticator instance, they're prompted to do so when they try to authenticate the next time.

    Similarly, you can disallow a specific authenticator instance in the policy. This instance becomes unavailable to the user the next time they sign in. Allowing or disallowing any one instance of the authenticator in the policy rule doesn't affect other instances of the authenticator.

    However, if you allow or disallow the generic IdP authenticator, it allows or disallows all the IdP authenticator instances.

    1 factor type: To enable one-factor authentication, choose one of these options.

    • Password or Password / IdP requires users to enter their password every time the rule requires re-authentication. If you select this option, the Factor restraints are options aren't available.
    • Possession factor requires users to provide a possession factor such as Okta Verify or email to access the app.
    • Any 1 factor type or Any 1 factor type / IdP allows users to provide any single factor to access the app. If you select this option, the Factor restraints are options aren't available.

    For one-factor passwordless authentication options, see Set up passwordless sign-in experience.

    2 factor types: To require users to provide two distinct factor types, choose one of these options.

    • Password + Another factor or Password / IdP + Another factor
    • Any 2 factor types

    For two-factor passwordless authentication options, see Passwordless authentication.

    Early Access release. See Enable self-service features.

    Authentication method chain: Require users to verify with multiple authentication methods in a specified sequence. See Authentication method chain.
    AND Possession factor constraints are These options aren't available if you selected Password, Any 1 factor type, or Any 1 factor type / IdP. Use these settings to specify possession factor characteristics.
    • Phishing-resistant: Requires users to provide possession factors that cryptographically verify the sign-in server (the origin). FIDO 2 (WebAuthn) and the Okta FastPass option in Okta Verify satisfy this requirement. For details, see Multifactor authentication.
    • Hardware protection: Requires that keys used to authenticate are stored in secure hardware (TPM, Secure Enclave) on the device. Okta Verify meets this constraint.

      If Okta Verify can't store keys on the secure hardware of the device, it uses software storage. On Windows and Android devices it uses TPM. On macOS and iOS devices it uses Secure Enclave. In these cases, Okta Verify doesn't satisfy the Hardware protection requirement.

      To identify how Okta Verify keys are stored for a device, view the secureHardwarePresent device attribute in the Admin Console. You can also use an Okta Expression Language (EL) expression to determine the value of device.profile.secureHardwarePresentview. If this value is true, secure hardware is used.

      See Expression Language attributes for devices.

      Some WebAuthn authenticators are hardware protected. Okta uses the FIDO Alliance Metadata Service (MDS) to determine whether a WebAuthn authenticator is hardware protected. An authenticator is considered hardware protected when one of its keyProtection values is hardware.

      Hardware-protected WebAuthn authenticators have several limitations:

      • Enrollments done before Nov 30, 2022 aren't supported.
      • Enrollments using FIDO U2F aren't supported.
      • Enrollments on Firefox aren't currently supported.
      • Enrollments on Chrome aren't currently supported if User Verification is set to Discouraged and a PIN is set on the security key.
      • If prompted during enrollment, users must allow Okta to see the make and model of the security key.
    • Require user interaction: This option allows you to choose whether to require end users to prove that they're physically present to authenticate.

      If you don't select this option, and the authentication policy requires a possession factor, Okta Verify may perform certificate-based authentication. This allows users to access the resource without proving that they're physically present.

      You can't use a security question as an additional factor if this option isn't selected.

    • Require PIN or biometric user verification: This option appears when you click Require user interaction. Require users to enter a PIN or use biometrics to verify their identity.

      When you select this option, users must verify their identity with an authenticator that proves user presence: Okta Verify with Push, FIDO2 (WebAuthn), Okta FastPass, Custom Authenticator, or Smart Card (with PIN). Configure each of these user presence authenticators to require user verification. This helps prevent users from being locked out and ensures that new enrollments in these authenticators satisfy the user verification requirement.

      Configure the authenticators to require user verification:

      1. Go to SecurityAuthenticators.
      2. Click the Setup tab.
      3. Click ActionsEdit for the authenticator that you want to configure.
      4. For Okta Verify with Push, FIDO2 (WebAuthn), Custom Authenticator, and Okta FastPass, select Required from the dropdown menu in the User verification section. For Smart Card, select PIN.

      Okta also recommends that you require user enrollment in the authenticators that satisfy user verification. See Create an authenticator enrollment policy. In the Authenticators section, set each of your user presence authenticators to Required.

      If a user is already enrolled in an authenticator but didn't activate a user verification option in it, such as enabling facial or fingerprint scanning in Okta Verify, they can't authenticate. Users must reset these enrollments and replace them with new ones, or activate push notifications and biometric verification in Okta Verify.

    AND Authentication methods

    These options aren't available if you select Password as the authentication method.

    • Allow any method that can be used to meet the requirement: Users can be authenticated using any of the available methods that meet the requirement.

    • Disallow specific authentication methods: Select methods to exclude them from use in authentication. When this option is selected, all available methods are allowed unless added to the disallow list.

    • Allow specific authentication methods: Select methods to allow them to be used in authentication. When this option is selected, all available methods are disallowed unless added to the allowlist.

    Option to stay signed in Early Access release. This setting lets you display the Keep me signed in prompt to users after they authenticate. See Keep me signed in.

    Show when not previously shown on the user's current device in the past

    		If you select Option to stay signed in, indicate the amount of time that passes before the Keep me signed in prompt appears again. This setting is for the prompt only and is independent of your MFA lifetime setting.

    Prompt for authentication This option appears if you require 1 factor type or Any 2 factor types for authentication. Indicate how frequently a user must authenticate.
    • Every time user signs in to resource: Users must authenticate every time they try to access the app. This is the most secure option.
    • When it's been over a specified length of time since the user signed in to any resource protected by the active Okta global session: Users are prompted to authenticate when they exceed the time interval you specify.
    • When an Okta global session doesn't exist: Users are prompted to authenticate if they never established an active Okta global session.

    A 10-second grace period applies after a user authenticates. During this grace period, users aren't prompted to authenticate again if you selected Every time user signs in to resource.
    Prompt for password authentication

    and

    Prompt for all other factors of authentication

    		 These options appear if you require Password + Another Factor or Password / IdP + Another factor for authentication. Select frequency intervals for the password and the other factors.

  7. Click Save.

The next step after you add rules to a policy is to apply that policy to one or more apps. There's no limit to the number of apps that can share a policy.

Security questions in an authentication policy

The Security Question authenticator prompts end users to enter a correct response to a question that they've selected from a list of possible questions.

  • The Security Question authenticator supports authentication (MFA/SSO) and password recovery scenarios. If disabled for MFA/SSO, it's included as part of authentication policy or global session policy evaluation.
  • You can use the Security Question authenticator as step-up or additional verification when a password is used as the primary factor, specifically, if the primary factor in the user's global session policy is A password. Okta recommends against using security questions in any authentication flow.

You can configure Okta to use this authenticator for just account recovery, or for both authentication and account recovery. If you choose only the recovery option, Okta doesn't request authentication during the evaluation of your Global Session Policy.

For example, if you want to enable Okta FastPass for your users so that they can access the resource without proving that they're physically present, you can't use a Security Question as an additional factor. If you want end users to use Security Questions, you must use the A password option in the Global Session Policy.

Limitations

  • Authentication rules don't recognize ChromeBook as a ChromeOS platform if users access their resources in a Firefox or Opera browser.

  • Because Okta Verify isn't available for ChromeOS, Okta FastPass isn't supported on this operating system. The Access with Okta FastPass is granted condition has no effect in the rules that check for ChromeOS.

  • If users sign in from a ChromeOS device, a device record isn't created.

  • You can't use ChromeOS in custom expressions.

Next steps

Add apps to an authentication policy

Update an authentication policy