About MFA authenticators

The goal of a good multifactor authentication (MFA) strategy is to provide a certain level of assurance. This is the degree of confidence that the user attempting to sign in is who they say they are. Authenticators provide different levels of assurance depending on their factor type:

  • Possession: This is something that the user has in their possession, such as a phone, or access to an email account.

  • Knowledge: This is something that the user knows, such as a password, or the answer to a security question.

  • Biometric: This is something that the user is. It represents a physical attribute of the user that a device can scan, such as a fingerprint reader or facial scanner. The scan is used to determine that the person attempting to authenticate is the same person who originally set up this type of authentication.

This table shows the relationship between authenticators, factors types, and methods.

Factor type
Knowledge (something you know) Possession (something you have) Biometrics/Inherence (something you are)
Authenticator

  • Password

  • Security Question

  • Phone

  • Google Authenticator

  • Email

  • WebAuthn

n/a
Methods

n/a

  • SMS

  • Voice

  • Google Authenticator

  • Okta Verify (TOTP & Push)

  • Email Magic Link

  • Security Key (touch-enabled YubiKey)

  • Okta Verify (with biometrics)

  • WebAuthn with Touch ID

  • Security Key (YubiKey with biometrics)

Authenticators also have methods. Each method enrollment satisfies a different set of factor types and method characteristics. For example, some authenticators are bound to a specific device, while others are used to demonstrate the physical presence of the user (instead of a bot, for example). Here’s a table that describes the characteristics of methods:

Method characteristic Description Examples
Device-Bound The device key or secret is stored on the device and can’t be transferred to another device without re-enrolling All possession authenticators except for Email and Phone
Hardware-Protected An authenticator that provides hardware protection of secrets or private keys. The device key is stored on a separate device, in the Trusted Platform Module (TPM), in a secure enclave, or on a separate hardware token, such as RSA SecureID. Hardware protection isn't provided by all types of devices. Okta Verify proof-of-possession key
Phishing-Resistant An authenticator that cryptographically verifies the login server WebAuthn
User Presence The user proves they have control of the authenticator by actively authenticating (interacting with the authenticator, such as touching a YubiKey or entering a one-time password) and demonstrates their physical presence Every method except an Okta Verify verification signed by a proof-of-possession key

To provide higher levels of assurance, select combinations of authenticators that cover different factor types, such as this combination:

  • Select Password or Security Question to ask the user for something they know
  • Select Google Authenticator to prove that a user is in possession of the device they’re authenticating with, and that it really is that user’s device
  • Select Okta Verify with biometrics enabled to verify the physical person attempting to authenticate

When you add an authenticator to your list of authenticators, you must also configure it so it will work the way you want in your environment. Each authenticator has unique configuration requirements, and some authenticators are used for specific purposes.

For example, you can configure the Email, Phone, and Security Question authenticators to be used only for authentication (multifactor authentication or single sign-on), only for password recovery, or for both. When an authenticator is disabled for multifactor authentication or single sign-on, it's never requested during sign-on policy evaluation.

Phishing resistance

Phishing-resistant authentication detects and prevents the disclosure of sensitive authentication data to fake applications or websites. WebAuthn (FIDO 2) and Okta FastPass in Okta Verify are phishing-resistant authentication options that prevent email, SMS, and social media phishing attacks. Phishing-resistant authenticators don’t protect against attacks where the computer or network is already compromised.

To ensure that users authenticate with phishing-resistant factor types, follow these steps:

  1. Set up WebAuthn (FIDO 2) and Okta Verify.

  2. Configure authentication policy rules that require a phishing-resistant possession factor.

    WebAuthn (FIDO 2) and Okta Verify (Okta FastPass option) satisfy the phishing-resistance requirement.

  3. For iOS or macOS managed devices, configure an SSO extension profile to ensure that authentication with Okta FastPass is phishing resistant.

You can now force the collection of device signals from all authentication attempts if any authentication policy rule has device conditions. Signals are collected even if users don't sign in with Okta FastPass. If you choose not to enable this feature, device signals are cached in the session and may not be collected. To activate this Early Access feature, enable Okta FastPass collects device signals in every auth attempt in the Admin Console. See Manage Early Access and Beta features for more information.

If phishing attempts occur when users authenticate with Okta FastPass or WebAuthn, the events are recorded in the System Log. A message flags the authentication failure: FastPass declined phishing attempt.

When users attempt to access resources that require a phishing-resistant factor, they can usually use Okta FastPass. If Okta FastPass isn’t supported, users are prompted to authenticate with WebAuthn (FIDO 2).

Phishing-resistant authentication on managed devices

Operating system Supported browsers Native apps
Android Okta FastPass or WebAuthn Okta FastPass or WebAuthn
iOS Okta FastPass or WebAuthn Okta FastPass or WebAuthn
macOS Okta FastPass or WebAuthn Okta FastPass or WebAuthn
Windows Okta FastPass or WebAuthn No phishing-resistant authentication

Phishing-resistant authentication on unmanaged devices

Operating system Supported browsers Native apps
Android Okta FastPass or WebAuthn Okta FastPass or WebAuthn
iOS WebAuthn* WebAuthn*
macOS Okta FastPass or WebAuthn WebAuthn
Windows Okta FastPass or WebAuthn No phishing-resistant authentication**

* Users sign in with Okta FastPass and are prompted to authenticate with WebAuthn as a phishing-resistant factor.

** Access is denied.

About rate limiting

Okta enforces a rate limit on unsuccessful authentication attempts from your authenticators to protect your sensitive corporate resources from unauthorized access. A cumulative limit of five unsuccessful authentication attempts is enforced over a rolling five-minute period. If unsuccessful authentications exceed the rate limit, authentication isn’t allowed until the rate limit period has elapsed. A message appears on the user interface, and an entry is written to the System Log.