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 |
|
|
n/a |
| Methods |
n/a |
|
|
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. Some WebAuthn authenticators are hardware-protected. See Hardware-protected WebAuthn authenticators. |
Okta Verify proof-of-possession key WebAuthn hardware security keys. |
| Phishing-Resistant | An authenticator that cryptographically verifies the login server. | WebAuthn, Okta FastPass in Okta Verify |
| 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:
- 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, you must also configure it so it works 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. See Phishing resistant authentication.
Hardware-protected WebAuthn authenticators
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.
About rate limits
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.