Configure an authentication policy for Okta FastPass

Create an authentication policy that supports Okta FastPass.

Configure strong authentication policies to secure each of your apps

When you configure Okta FastPass, make sure you remove the default global password requirement from your Global Session Policy. This change removes responsibility for defining and enforcing authentication criteria from your Global Session Policy and transfers it to each of your authentication policies. Before you remove this global requirement in your Global Session Policy, make sure you protect all of your apps with a strong authentication policy.

After you upgrade from an Okta Classic Engine to an Okta Identity Engine, end users will have a different user verification experience. With an Okta Classic Engine, if your authentication policy is configured for two authentication factors (for example, Password + Another factor, or Any 2 factor types), users with Okta Verify are required to provide two authentication factors (for example, enter a password and accept an Okta Verify Push notification). When you upgrade to an Okta Identity Engine, the same authentication policy exists, but the user experience changes. Now (using the same example from earlier), users can only provide Okta Verify Push with biometrics to get access. This is expected behavior because, when the user provided biometrics to unlock their device, the authentication policy evaluated that as the first authentication factor.

This procedure provides an example of how to configure an authentication policy that allows passwordless access to apps.

With this policy, users must have Okta Verify installed and enrolled on their device (see Device registration) before they can access the apps. Users with unregistered devices are denied access to apps.

  1. In the Admin Console, go to Security > Authentication Policy.
  2. Select the policy you want to update.
  3. Click the Rules tab.
  4. Click Add Rule.
  5. Create authentication policy rules.
  6. Use Rule 1 (example), Rule 2 (example), and Rule 3 (example) as a guide when setting up your authentication policy rules. In this example:

    • Rule 1 allows seamless access (Okta FastPass) to the application if the device is managed, registered, has secure hardware, and the user successfully provides any two authentication factors.

    • Rule 2 allows access to the application if the device is registered, not manage, and the user successfully provides a password and any other authentication factor except phone or email.

    • Rule 3 denies access to all users that did not meet Rule 1 or Rule 2.

    The most restrictive rule (Rule 1) is at the top and the least restrictive rule is at the bottom.

    The following image reflects the rules that are provided as an example:

    The image displays an example of a sign-on policy for passwordless authentication.

    Rule 1 (example)

    This rule applies to users with devices that are managed, registered, and have secure hardware. It allows them to have seamless access to the application. Users are prompted to re-authenticate only if it’s been more than one hour since they last authenticated.

    Users matching this rule can use any two authentication factor types to access the application. If users want to access the application without entering a password, they must enable biometric authentication in Okta Verify. If they have enabled biometrics in Okta Verify, they're still prompted for their password (a knowledge factor).

    1. In the Rule name field, enter a name for the rule. For example, Passwordless: Allow Registered + Managed + Hardware present + 2 factors.
    2. Use the following configuration as a guide for rule 1:
    3. Condition Configuration Description
      IF User's user type is Any user type Configures the user type that can access the app. Select one of the following:
      • Any user type (default): Any user type can access the app.

      • One of the following user types: Only specific user types can access the app. In the fields that appear when this option is selected, enter the user types to include and exclude.

      AND User's group membership includes Any group Configures user groups that can access the app. Select one of the following:
      • Any group (default): Users that are part of any group can access the app.

      • At least one of the following groups: Only users that are part of specific groups can access the app. In the fields that appear when this option is selected, enter the groups to include and exclude.

      AND User is Any user Configures users that can access the app. Select one of the following:
      • Any user (default): Allows any user to access the app.

      • At least one of the following users: Only allows specific users to access the app. In the fields that appear when this option is selected, enter the users to include and exclude.

      AND Device state is Registered Configures whether devices must be registered to access the app. Select one of the following:
      • Any (default): Registered and unregistered devices can access the app.

      • Registered: Only registered devices can access the app.

      AND Device management is Managed Configures whether devices must be managed to access the app. Select one of the following:
      • Not managed (default): Managed and not managed devices can access the app.

      • Managed: Only managed devices can access the app.

      AND Device platform is Any platform Configures the device platform needed to access the app. Select one of the following:
      • Any platform (default): Any device platform can access the app.

      • One of the following platforms: Only specified device platforms can access the app. From the list that appears when this option is selected, select one or more of the following: 

        • IOS

        • ANDROID

        • WINDOWS

        • MACOS

        • MOBILE_OTHER

        • DESKTOP_OTHER

      AND User's IP is Any IP Configures the network zone required to access the app. Select one of the following:
      • Any IP (default): Devices with any IP address can access the app.

      • In any network zone defined in Okta: Only devices in a network zone defined in Okta can access the app.

      • In any of the following zones: Only devices within the specified zones can access the app. Enter specific zones in the field that appears.

      • Not in any network zone defined in Okta: Only devices outside of the network zone defined in Okta can access the app.

      • Not in any of the following zones: Only devices outside of the specified zones can access the app. Enter specific zones in the field that appears.

      AND Risk is Any Configures the risk score tolerance for sign-in attempts. Select one of the following:
      • Any (default): The risk score can be low, medium, or high.

      • Low: The risk score must be low.

      • Medium: The risk score must be medium.

      • High: The risk score must be high.

      See Risk Scoring.

      AND The following custom expression is true Optional. Configures additional conditions using the Okta Expression Language (EL).

      See Okta Expression Language for devices.

      AND Client is Any client Configures the clients that can access the app. Select one of the following:
      • Any client (default): Any client can access the app.

      • One of the following clients: Only specified clients can access the app. Choose one or more of the following: 

        • Web browser

        • Modern Authentication

        • Exchange ActiveSync/Legacy Auth

      THEN Access is Allowed after successful authentication Configures the resulting app permissions if all the previous conditions are met:
      • Denied: The device is denied access when all the IF conditions are met.

      • Allowed after successful authentication: The device is allowed access when all the IF conditions are met and authentication is successful.

      AND User must authenticate with Any 2 factor types Configures the authentication that is required to access the app:
      • Password or Password / IdP: The user must enter a password every time the rule requires re-authentication.

      • Possession factor: The user must provide a possession factor to authenticate. For example, Okta Verify, WebAuthn, phone, or email.

      • Any 1 factor type or Any 1 factor type / IdP: The user must provide a possession, knowledge, or biometric authentication factor. For example, Okta Verify, WebAuthn, phone, email, password, or security question.

      • Password + Another factor or Password / IdP + Another factor: The user must provide a password, and any other authentication factor.

      • Any 2 factor types: The user must provide any two authentication factors.

      See About MFA authenticators.

      AND Possession factor constraints are Select the following checkboxes:
      • Hardware protection

      • Device bound (excludes phone and email)

      Configures the possession factor characteristics:
      • Phishing resistant (clear by default): Requires the possession factor to be phishing resistant.
      • Hardware protected (clear by default): Requires keys to be stored in a hardware-backed keystore (TPM, Secure Enclave).
      • Note: By default, Okta Verify attempts to store the Okta Verify keys on the secure hardware of the device: trusted platform module (TPM) for Windows and Android devices, or secure enclave for macOS and iOS devices. If secure hardware is not available, software storage is used. When software storage is used, Okta Verify will not satisfy the authentication policy if Hardware protection is selected as an AND Possession factor restraints are THEN condition.

        To identify how Okta Verify keys are stored for a device, view the secureHardwarePresent device attribute in the Admin Console, or 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 Okta Expression Language for devices and View device attributes.

      • Device Bound (excludes phone and email) (selected by default): Requires factor keys to be stored securely on the device.
      AND Access with Okta FastPass is granted If the user approves a prompt in Okta Verify or provides biometrics (meets NIST AAL2 requirements) Configures when access with Okta FastPass is granted:
      • If the user approves a prompt in Okta Verify or provides biometrics (meets NIST AAL2 requirements) (default): The user must prove that they are physically present when using Okta FastPass to authenticate.

      • Without the user approving a prompt in Okta Verify or providing biometrics: The user is not required to approve a prompt in Okta Verify or provide biometrics.

      See Add a global session policy rule for more information about this setting.

      Re-authentication frequency is Re-authenticate after: 1 Hours Configures how often a user is required to re-authenticate:
      • Every sign-in attempt: The user must authenticate each time they sign in.

      • Never re-authenticate if the session is active: The user is not required to re-athenticate if they are in an active session.

      • Re-authenticate after (default): The user is required to re-authenticate after a specified time. The default time is 2 Hours.

    4. Click Save.

    Rule 2 (example)

    This rule applies to users with devices that are registered and not managed. It allows them to access the application after they provide a password and any other authentication factor except phone or email.

    In addition to providing a password, users matching this rule can choose any enrolled authentication factor (except phone and email). If you select the option Okta Verify user interaction in this rule, users who choose Okta Verify as the authentication factor are prompted to provide user verification (biometrics).

    1. In the Rule name field, enter a name for the rule. For example, Allow Registered + Not managed + 2 factor (password, possession).
    2. Use the following configuration as a guide for rule 2:
    3. Condition Configuration Description
      IF User's user type is Any user type See Rule 1 (example).
      AND User's group membership includes Any group
      AND User is Any user
      AND Device state is Registered
      AND Device management is Not managed
      AND Device platform is Any platform
      AND User's IP is Any IP
      AND Risk is Any
      AND The following custom expression is true Optional.
      AND Client is Any client
      THEN Access is Allowed after successful authentication
      AND User must authenticate with Password + Another factor
      AND Possession factor constraints are Select the Device bound (excludes phone and email) checkbox.
      AND Access with Okta FastPass is granted If the user approves a prompt in Okta Verify or provides biometrics (meets NIST AAL2 requirements)
      Re-authentication frequency is Set the following:
      • Password re-authentication frequency is: 4 Hours

      • Re-authentication frequency for all other factors is: 15 Minutes

    4. Click Save.

    Rule 3 (example)

    This rule applies to users that did not match Rule 1 or Rule 2. It is a catch-all rule that denies access to the application.

    1. In the Rule name field, enter a name for the rule. For example, Catch-all Rule.

    2. Use the following configuration as a guide for rule 3:
    3. Condition Configuration Description
      IF User's user type is Any user type See Rule 1 (example).
      AND User's group membership includes Any group
      AND User is Any user
      AND Device state is Any
      AND Device platform is Any platform
      AND User's IP is Any IP
      AND Risk is Any
      AND The following custom expression is true Leave blank.
      THEN Access is Denied
    4. Click Save.

Related topics