This article presents the factors supported by Okta for Multi-factor Authentication.

• Multi-Factor Authentication (MFA)

• Okta Verify

  • Okta Verify is a Multi-Factor Authentication authentication (MFA) application developed by Okta. It lets users verify their identity when they sign in to Okta and makes it less likely that someone pretending to be the user can gain access to the account.
  • To use Okta Verify, one must first enable and configure it for the org, and then the end users must install the Okta Verify app on their device and set it up. Then, when end users sign in to Okta, they can verify their identity by approving a push notification in the application or by entering a one-time code provided by the app into Okta.

• SMS Auth

  • The SMS Authentication factor allows users to authenticate themselves using a one-time passcode (OTP) that is delivered to their phone in an SMS message.

  • There are important considerations that one must be aware of when using telephony as part of a multi-factor authentication strategy, including regulatory requirements, toll fraud, and others. See Telephony for more information.

  • There are also important technical considerations for sending SMS messages. See Configure and use telephony for more information.

  • One can also customize SMS message templates, view SMS events in the System Log, and view SMS usage reports. See Configure and use telephony for more information.

• Voice Call Auth

  • The Voice Call Authentication factor allows users to authenticate themselves using a one-time passcode (OTP) that is delivered in a voice call to the user's phone. Users can provide a phone number for a landline or mobile phone. Extension numbers for landlines are also supported.

  • There are important considerations that one must be aware of when using telephony as part of the Multi-Factor Authentication strategy, including regulatory requirements, toll fraud, and others. See Telephony for more information.

  • One can also select languages for voice-based authentication. See Configure and use telephony for more information.

• Email

  • The Email Authentication factor allows users to authenticate themselves by clicking on an email magic link or using a six-digit code as a one-time password (OTP). Okta sends these authentication methods in an email message to the user's primary email address, which helps verify that the person making the sign-in attempt is the intended user. If the user does not click the email magic link or use the OTP within the challenge lifetime, they are not authenticated.

  • This method provides a simple way for users to authenticate, but there are some issues to consider if wanting to implement this factor:

    • Email is not always transmitted using secure protocols; unauthorized third parties can intercept unencrypted messages. Consider assigning a shorter challenge lifetime for email magic links and OTP codes to mitigate this risk.

    • Email messages may be directed to the user's spam or junk folder. Remind users to check these folders if they do not receive their email authentication message.

    • Networking issues may delay email messages. If the email authentication message arrives after the challenge lifetime has expired, users must request another email authentication message.
      One can also use email as a means of account recovery and set the expiration time for the security token.

• Duo Security

  • One can add Duo Security as a Multi-Factor Authentication (MFA) option in Okta. When enabled as a factor, Duo Security is the system of record for MFA, and Okta delegates secondary verification of credentials to the Duo Security account.

  • If one has a Duo Security deployment with existing enrollments, make sure that the Duo Security usernames match the Okta usernames or email addresses of the Okta users. When an end user signs in to Okta or accesses an Okta-protected resource, Okta looks up the user in the Duo Security account according to the user’s Okta username or email address. Username mapping can be changed as described in this topic.

  • Users without an existing Duo Security enrollment can enroll themselves when they sign in to Okta or through their Duo Security account page. Depending on the Okta integration settings in Duo Security, end users can enroll with a smartphone, tablet, telephone, Touch ID, and security keys.

• Google Authenticator

  • Google Authenticator is an application that provides a Time-based One-time Password (TOTP) as a second factor of authentication to users who sign in to environments where Multi-Factor Authentication (MFA) is required.

  • Admins add Google Authenticator to the list of accepted factors in Okta. Then, users who select it to authenticate are prompted to enter the time-based, six-digit code they see in the Google Authenticator app in Okta.

• Symantec VIP

  • Symantec Validation and ID Protection Service (VIP) is a cloud-based authentication service that enables secure access to networks and applications.

  • To enable this authenticator, one first should obtain a certificate from the Symantec VIP Manager and then upload it to Okta. When Symantec VIP is enabled, Symantec VIP-registered users who select it when authenticating are prompted to enter a time-based passcode generated by the Symantec VIP app.

• On-Prem MFA (ex. RSA SecurID)

  • The Okta On-Prem MFA agent (formerly named the RSA SecurID agent) acts as a RADIUS client. It communicates with the RADIUS-enabled on-premises MFA server, which includes RSA Authentication Manager for RSA SecurIDs. This allows organizations to use second-factor challenges from various on-premises Multi-Factor Authentication tools.

  • To sign in, end users must use an RSA hardware dongle device or soft token to generate an authentication code to sign into the org. The numbers are generated using a built-in clock and the card's factory-encoded random key.

• YubiKey

  • A YubiKey is a brand of security key used as a physical Multi-Factor Authentication device. To use it, the user inserts the YubiKey into a USB port on their computer when they are signing in and taps the YubiKey's button when prompted. The YubiKey may provide a one-time password (OTP) or perform fingerprint (biometric) verification, depending on the type of YubiKey the user presents.

  • This topic provides instructions for setting up and managing YubiKeys using the OTP mode. To use YubiKeys for biometric verification, see FIDO2 (WebAuthn).

  • To use this Multi-Factor Authentication (MFA) factor, generate a .csv file of the YubiKeys that were imported using a tool from YubiKey's maker, Yubico. Then, activate the YubiKey factor and import the .csv file. Users activate their YubiKeys the next time they sign in to Okta.

• Security Question (generally not recommended)

  • The Security Question factor prompts end users to enter a correct response to a question that they have selected from a list of possible questions.

  • The Security Question factor:

    • This factor supports authentication (MFA/SSO) and user password recovery when enabled for these scenarios. If disabled, this factor for MFA/SSO is not evaluated by the Okta sign-on policy.

• FIDO2 (WebAuthn - Windows Hello, Apple TouchID)

  • The FIDO2 (WebAuthn) factor lets users use a biometric method, such as fingerprint reading, to authenticate. This factor supports three authentication methods:

    • Security keys, such as YubiKey or Google Titan.

    • Platform authentication that is integrated into a device and uses biometric data, such as Windows Hello or Apple Touch ID.

    • Sign-ins to URLs that are different from the org's Okta URL, custom domain URL, trusted cross-origin, or cross-Relying Party Identifier require validation when using the Trusted Origins API. See Configure Trusted Origins.

  • FIDO2 (WebAuthn) follows the FIDO2 Web Authentication (WebAuthn) standard. After this factor is enabled, end users can select it when signing in and use it for additional authentication.
    To set up and manage YubiKeys to use the one-time password (OTP) mode, see YubiKey (MFA).

• Custom One-Time Passcode (OTP) authenticator

  • The Custom TOTP factor lets users use a custom time-based one-time passcodes (TOTP) solution for user authentication.

  • Users select the Custom TOTP factor when they sign in and provide the TOTP from their token to sign in to Okta or Okta-protected resources.

  • To set this factor up, one should pass a factorProfileId and sharedSecret through the Okta Factors API for each token.

  • One can create unlimited instances of the Custom TOTP factor for different groups of personnel, but users may only enroll in one instance at a time.
     

NOTE: Please be advised that starting on August 2023, all new customers will no longer be able to use Okta-provided SMS and Voice services out-of-the-box. Customers who need to deploy telco-based MFA will need to bring their own telco using Okta’s Telephony Inline Hook. For more details, please consult this documentation or get in touch with the Account Team.

Related References

• Okta Documentation - MFA Factor Configuration

• Telephony