Oracle Cloud Infrastructure Documentation

Managing Multi-Factor Authentication

Multi-Factor Authentication (MFA) is a method of authentication that requires the use of more than one factor to verify a user’s identity.

With MFA enabled in an identity domain, when a user signs in to an application, they’re prompted for their user name and password, which is the first factor – something that they know. The user is then required to provide a second type of verification. The two factors work together to add an additional layer of security by using either additional information or a second device to verify the user’s identity and complete the login process.

MFA may include any two of the following:

  • Something that you know, like a passcode.

  • Something that you have, like a device.

  • Something that you are, like your fingerprint.

Users are increasingly connected, accessing their accounts and applications from anywhere. As an administrator, when you add MFA on top of the traditional user name and password, you reduce the likelihood of online identity theft and fraud, which secures your business applications even if an account password is compromised.

Securing IAM MFA with Oracle Best Practices

If you're using MFA with identity domains, we recommend that you set up MFA using Oracle best practices. See IAM MFAin the Security guide.

Using MFA in Restricted Realms

Not all MFA providers operate exclusively within restricted realm boundaries. Therefore, before enabling MFA features, we recommend that you carefully evaluate the MFA providers you may want to use, to ensure they operate within the bounds of a restricted realm and that they meet your organization’s security and compliance requirements.

Using Mobile Authenticator Apps with MFA

Using a mobile authenticator application for MFA provides a second factor of authentication in the form of a time-based one-time passcode (OTP) or push notification, and offers multiple options for implementing app protection and compliance policy.

A mobile authenticator app is a soft token that is installed on a mobile device. A mobile authenticator app uses either OTP or push notifications to prove that the user has possession of the mobile device. Only the mobile authenticator app that is in possession of the user's secret key can generate a valid OTP. During MFA enrollment, when a user scans the Quick Response (QR) code or uses the enrollment URL, the mobile authenticator app is automatically configured with the IAM server. The mobile authenticator app retrieves a secret key, which is required to generate the OTP and to receive push notifications on the mobile authenticator app. That secret key is then shared between the client and the IAM server. If the user is enrolling offline, IAM shares the secret with the Mobile Authenticator through a QR Code. If the user is enrolling online, IAM shares the secret with the Mobile Authenticator through the enrollment notification.

A user can use the mobile authenticator app to generate an OTP both online or offline. However, registering for push notifications and performing device compliance checks (jailbreak detection/PIN protection) can only be done while online.

  • Mobile App Passcode: Use a mobile authenticator app, such as the Oracle Mobile Authenticator app, to generate an OTP. A new OTP is generated every 30-60 seconds and is valid for 90-180 seconds. After the user enters their user name and password, a prompt appears for the passcode. After generating the passcode using the mobile authenticator app, the user enters that code as the second verification method.
  • Mobile App Notification: Send a push notification to the OMA app that contains an approval request to allow or deny a login attempt. After the user enters their user name and password, a login request is sent to their phone. The user taps Allow to authenticate.

The OMA app is available for Android, iOS, and Windows operating systems.

Note

During MFA enrollment, a user must enter the key manually or use the enrollment URL when using the OMA app on a Surface Pro or Windows Desktop device. The QR code scanner can't be used due to a camera limitation. When a user enters that key manually, the OMA app supports only BASE32 encoding.

When you enable both the Mobile App Passcode and Mobile App Notification factors and a user is enrolled in Mobile App as a second method of verification, the Mobile App Notification factor is the default that is presented to the user. Users can change which factor they want to use by either selecting a different backup verification method when logging in or by selecting a different method as their default option. IAM users can use the OMA app or any supported third-party authenticator app that they want to generate OTPs. However, users must use the OMA app to receive push notifications.

IAM works with any third-party authenticator app (such as Google Authenticator) that adheres to the TOTP: Time-Based One-Time Password Algorithm specification. There are no special administrator configuration steps for third-party authenticator apps. When a user enrolls in MFA and selects Mobile App as the method, the user can either select the Enter Key Manually or Scan offline QR code options to set up third-party authenticators. We recommend the use of the OMA app as it supports notifications and security features such as app protection policy, compliance policy, and silent key refresh.

Multi-Factor Authentication (MFA) Authorization Flow

The authorization flows that support MFA are the Authorization Code Grant Type and SAML2 Assertion.

Authorization Flows that Don’t Support MFA:

  • Resource Owner Password Credentials Grant Type

  • Client Credentials Grant Type

  • Assertion Grant Type

  • Implicit Grant Type

Using the Console

Registering a Client Application

Register a client application before you configure Multi-Factor Authentication (MFA) so that you have the credentials (Client ID and Client Secret) that are used for authentication in REST API calls. Oracle Support can use your Client ID and Client Secret to help you troubleshoot if you have issues, for example if you lock yourself out of an identity domain when configuring MFA.

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Applications.
  2. Click Add application.
  3. In the Add application window, click Confidential Application, and then click Launch workflow.
  4. In Add application details, enter an application name and description, and then click Next.
  5. Select Configure this application as a client now, and then, in the Authorization section that appears, select only Client Credentials as the Allowed Grant Type.
  6. Scroll down, and select Add app roles and then Add roles.
  7. In the Add app roles dialog window, select Identity Domain Administrator in the list, and then click Add.
  8. Click Next and then click Finish.
  9. On the application detail page, scroll down to General Information. Copy the Client ID and the Client Secret and store it in a safe place.
  10. Click Activate, after the application is created.
Configuring Multi-Factor Authentication Settings

Configure multi-factor authentication (MFA) settings and compliance policies that define which authentication factors that you want to allow and then configure the MFA factors.

Before you begin:
  • Create a test user in a test identity domain. Use that identity domain to set up MFA for the first time. See Creating an Identity Domain and Creating a User.
  • Set up a client application to enable access to your identity domain using the REST API in case your Sign-On Policy configuration locks you out. If you don’t set up this client application and a Sign-On Policy configuration restricts access to everyone, then all users are locked out of the identity domain until you contact Oracle Support. For information about setting up the Client Application, see Registering a Client Application.

To define MFA settings, you must be assigned to either the identity domain administrator role or the security administrator role.

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Security and then MFA.
  2. In the Factors section, select each of the factors that you want users to be able to select.
  3. (Optional) Click Configure for the MFA factors that you’ve selected to configure them individually.

    See Configuring Authentication Factors.

  4. (Optional) Set the Maximum number of enrolled factors that users can configure.
  5. (Optional) Use the Trusted devices section to configure trusted device settings.

    Similar to “remember my computer,” trusted devices don’t require the user to provide secondary authentication each time that they sign in.

  6. (Optional) In the Sign-in rules section, set the Maximum unsuccessful MFA attempts that you want to allow a user to incorrectly provide MFA verification before being locked out.
  7. Click Save changes, and then confirm the change.
  8. Ensure that any sign-on policies that are active allow two-step authentication:
    1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Security and then Sign-on policies.
    2. On the Sign-on policies page, click Default Sign-On Policy.
    3. On the Default Sign-On Policy page, select Sign-on rules.
    4. In the Default Sign-On Rule row, click the Actions menu and select Edit sign-on rule.
    5. In the Edit sign-on rule dialog box, under Exclude users, exclude yourself or another Identity Domain Administrator from this rule until testing is complete. This ensures that at least one administrator always has access to the identity domain should issues arise. Also, ensure that Actions is set to Allow access and Prompt for an additional factor is selected.
    6. Click Save changes.
    7. If other sign-on policies have been added, follow steps c-d above for each of those policies to ensure that MFA is enabled under all conditions where you want it to be enabled.
      Note

      The settings for the default sign-in rule enable MFA globally. Settings for other sign-in rules may override the default sign-in rule for users and groups specified by conditions for those rules. See Managing Password Policies.

      Important

      Ensure you exclude one Identity Domain Administrator from each policy. This ensures that at least one administrator always has access to the identity domain should issues arise.

      Set Enrollment as Optional until you’re finished with testing the sign-on policy.

What to do next:
  1. Enable MFA for a test account. See Configuring an Additional 2–step Verification Method.
  2. Sign out of the Console.
  3. Sign in as the test user. You should be prompted for a second factor.
Configuring Authentication Factors

You can configure the following authentication factors for an identity domain.

  • Security Questions: Prompt the user to answer security questions to verify their identity. After the user enters their user name and password, they must answer a defined number of security questions as the second verification method.
  • Email: Send a one-time passcode in an email to the user. After the user selects Email as the authentication method, IAM sends a one-time passcode to the user’s primary email address for use as a second verification method. The user’s primary email (Email) address is defined in the user’s IAM account.
  • Duo Security: Enable Duo Security as an MFA Factor so that users use the Duo App or other Duo factors to authenticate. If Duo Security is enabled, users that have not enrolled are prompted to do so when a Sign-On policy triggers an MFA verification.
  • Fast ID Online (FIDO): Configure FIDO authentication so that users can use their FIDO authentication device, for example an external authentication device such as a YubiKey, or an internal device such as Windows Hello or Mac Touch ID, to authenticate to an identity domain.
  • Mobile App Passcode: Use an authenticator app, such as the Oracle Mobile Authenticator (OMA) app to generate an OTP. An OTP can be generated even when the user's device is offline. After the user enters their user name and password, a prompt appears for the passcode. The user obtains a generated passcode from the app, and then enters the code as the second verification method.

    IAM also works with any third-party authentication app that adheres to the TOTP: Time-Based One-Time Password Algorithm specification, such as the Google Authenticator.

  • Mobile App Notification: Send a push notification that contains an approval request to allow or deny a login attempt. Push notifications are an easy and quick way to authenticate. After the user enters their user name and password, a login request is sent to the app on their phone. The user taps Allow to authenticate.
  • Text Message (SMS) or Phone Call: Send a passcode as a text message (SMS) or as a phone call to the user. This method is useful for users without Internet connectivity. After the user enters their user name and password, IAM sends a passcode to their device for use as a second verification method.
  • Bypass Code: Use the IAM self-service console to generate bypass codes. The ability to generate a bypass code is available to the user after the user enrolls in 2-Step Verification. Users can generate bypass codes and save for use later. User-generated bypass codes never expire, but can only be used once. Users also have the option to contact an administrator to obtain a bypass code for access.
Configuring Security Questions

Configure security questions settings, select the security questions that a user may use as a second verification method during sign-in, and add custom security questions.

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Security and then Two-factor authentication. Click Security questions.
  2. In the Security questions settings section, set options for answer length and the number of questions a user is asked.
    • Minimum number of questions: The minimum number of security questions a user must configure.
    • Minimum answer length (characters): The minimum number of characters that must be contained in each security question answer.
    • Number of security questions a user is asked: The default number of security questions that a user must set up is set to three.
      Note

      This value can't be changed using the user interface. If you need to change this number, you must use the /SecurityQuestionSettings endpoint.
  3. In the Manage security questions section, select the check boxes for the questions that you want to use. To disable a default security question, clear the check box for that question.
    • Select the Language in which you want to view the questions.
    • To add a custom security question:
      1. Click Add question.
      2. In the Add a security question page, enter the custom security question in the Default language field. Optionally, enter the translated question text into the appropriate language row. When you view the custom security questions in a different language, those questions appear in your default language if you don’t provide translated question text.
      3. Click Save.
      4. Confirm your changes.

        Your custom question is added at the bottom of the user-defined Questions list.

    • To edit a custom question:
      1. Locate the custom question in the user-defined Questions list.
      2. Click the menu to the right of the question and select Edit.
      3. Make your changes and click Save.
    • To remove a custom question:
      1. Locate the custom question in the user-defined Questions list.
      2. Click the menu to the right of the question and select Remove.
      3. Click Remove in the confirmation dialog box.
Configuring OTP Text Messages and Phone Calls

Configure passcode settings for sending users a one-time passcode (OTP) as a text message or as a phone call. Use a text message template to create the wording in the text message and use a phone call template to configure the phone call.

Before you can configure phone call settings, you must first set up a Vonage provider.
  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Security and then Two-factor authentication. Click Phone number.
  2. Make any necessary changes to the Passcode length and Passcode validity duration. These settings apply to one-time passcodes sent in text messages and phone calls.
    • Passcode length: The number of characters in the passcode.
    • Passcode validity duration: The number of minutes for which the passcode will be valid, after the passcode was sent.
  3. Configure a text message. Select the language and create the wording that is sent in the text message to users.
    1. Select the language for the text message.
    2. Modify the template.

      IAM provides a fixed list of message variables for your use. Click Message variables to view the available variables and variable definitions.

      Note

      When you use the ${companyName} variable, be sure to add your company name to the Company name field on the Branding page in Settings. If you don't add the company name, your company details don't appear in email notifications, text notifications, or in the Oracle Mobile Authenticator (OMA) app when a user completes MFA enrollment.

  4. Configure a phone call. Select a language, enter your Vonage provider settings, and create the phone call that users receive.
    1. Expand the Phone call provider section.
    2. If you haven't already done so, set up your Vonage provider.
    3. Enter the Vonage provider settings.
    4. Select the language for the text message.
    5. Modify the template.

      IAM provides a fixed list of message variables for your use. Click Message variables to view the available variables and variable definitions.

      Note

      When you use the ${companyName} variable, be sure to add your company name to the Company name field on the Branding page in Settings. If you don't add the company name, your company details don't appear in email notifications, text notifications, or in the Oracle Mobile Authenticator (OMA) app when a user completes MFA enrollment.

  5. Click Save changes.
  6. Confirm your changes.
Configuring Email Settings

Configure settings for sending a one-time passcode (OTP) to a user's primary email address.

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Security and then Two-factor authentication. Click Email.
  2. In the Configure the email settings for MFA section, set the passcode length and the passcode validity.
  3. In the Configure the email settings for account recovery and activation section, configure activation and password reset validity and whether you want to allow the user to add an alternate email address for account recovery.
  4. Click Save changes.
  5. Confirm your changes.
To access the email template that's sent to the user's primary email account:
  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains.Select the identity domain you want to work in and click Settings and then Notifications.
  2. Select the Email templates tab.

    The template name is 2-Step email one-time passcode verification.

Configuring Duo Security

If you have implemented or want to implement Duo security as a third-party multi-factor authentication (MFA) solution, and IAM manages your primary authentication and identity management, you can connect to and integrate with Duo to secure Oracle IaaS, PaaS, or SaaS applications or to secure applications already secured by IAM.

  • Download and install the Duo Mobile app from the Google Play Store or the Apple Store.
  1. Subscribe to Duo and create a Duo administrator account.

    Go to https://duo.com/ to set up your subscription and to set up your Duo administrative account. Refer to the Duo documentation for the latest instructions.

  2. Create and activate the Duo-protected Web SDK app.
    To create and activate the Duo-protected Web SDK app, refer to the Duo documentation for the latest instructions.
  3. Note the credentials and connecting host information.

    These values were generated when you created and activated the Duo-protected Web SDK app. You need the values for Integration key, Secret key, and API hostname. Refer to the Duo documentation for the latest instructions.

  4. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Security and then Two-factor authentication. Click Duo security.
  5. Enter the credentials and connecting host information (Integration key, Secret key, and API hostname) that was generated from your Duo Administrative account, and then choose a User identifier.
    The User identifier that you choose must map to the user identifier set in the Duo user account. For example, User Name in the identity domain user account must map to Username in the Duo security user account.
  6. Click Save changes.
  7. Confirm your changes.
Configuring Fast ID Online (FIDO) Authenticator

Configure FIDO authentication so that users can authenticate with an external authentication device such as a YubiKey, or an internal device such as Windows Hello or Mac Touch ID.

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Security and then Two-factor authentication. Click FIDO authenticator.
  2. Configure the FIDO Authenticator settings:
    • Time-out (milliseconds): The length of time the user has to take action. If the user doesn't take action within this period, authentication fails. The default is 60,000 milliseconds (6 seconds).
    • Attestation
      • None
      • Indirect
      • Direct
    • Authenticator selection attachment: Controls the authenticator type a user register with.
      • Platform. Windows Hello and Mac Touch ID.
      • Cross Platform. Choose to use a cross-platform authenticator such as YubiKey.
      • Both (default).
    • Authenticator selection resident key: Whether Resident key support should be enabled.
      • Required.
      • Preferred.
      • Discouraged.
      • None (default). The private key is encrypted and stored on the server.
    • Authenticator selection user verification: Relying Party's requirements regarding user verification during Registration:
      • Required.
      • Preferred (default).
      • Discouraged.
    • Public key types: The cryptographic algorithm used to generate a public key pair during Registration. IAM only certifies ES256 (the default) and RS256.
    • Exclude credentials: Used by Relying Parties to limit the creation of multiple credentials for the same account on a single authenticator. Default value is false.
  3. Click Save changes.
  4. Confirm your changes.
FIDO authentication is now an additional sign-in factor
Configuring Mobile OTP and Notifications

Configure policy for the time-based one-time passcode (OTP), and protection and compliance policies for the Oracle Mobile Authenticator (OMA) app.

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Security and then Two-factor authentication. Click Mobile app.
  2. In the Passcode policy section, make any necessary changes.

    The default values are the industry-recommended settings:

    • Change the Passcode length or leave the default.
    • Change the Hashing algorithm or leave the default.
    • The value in the Passcode generation interval (seconds) box indicates the number of seconds before a new passcode must be generated.

      To avoid clock skew, which is the time difference between the server and the device, the user must ensure that their device clock is synchronized. The maximum allowed time difference between the server and the device is 90 seconds.

    • The value in the Secret key refresh interval (days) box indicates the number of days before you want to refresh the shared secret.

      Each time that a user enrolls a mobile device, a secret key is pushed and securely stored on the device by using the scanned Quick Response (QR) code or when the user enters the key manually. This key is the input to the OTP algorithm that is used to generate the OTP. The key is refreshed silently, so no user action is required.

  3. In the Notification Policy section, select Enable pull notifications to allow the OMA App to pull pending notification requests from the server.

    Pull notifications are updates that are delivered to a mobile device or computer in response to a user who is manually checking for login request notifications. You can only enable this option if you enabled the Mobile app notification factor on the Multi-factor authentication (MFA) settings page.

    Pull notifications are useful in scenarios where the GCM service (Android) or Firebase Cloud Messaging (FCM), APNS Service (iPhone), or WNS service (Windows) doesn’t work. For example, China blocks the GCM service, so users don’t receive notifications that are pushed to their device. However, if pull notifications are available, the user can manually pull notifications from a server using the OMA app. Also, offering pull notifications is useful in situations where push notifications are not 100% reliable.

  4. Configure the App protection policy and Compliance policy for the OMA app.

    Compliance policy checks are performed each time that the OMA app opens.

  5. Click Save changes.
  6. Confirm your changes.
Configuring Text Message (SMS) Settings

Configure settings for sending a passcode as a text message (SMS) to the user. This method is useful for users without Internet connectivity.

  1. Open the navigation menu and click Identity & Security. Under Identity, click Domains. Select the identity domain you want to work in and click Security and then Two-factor authentication. Click Phone number.
  2. Make any necessary changes to the settings for the one-time passcode that is sent in a text message or phone call to the user's device.
    • Passcode length: The number of characters in the passcode.
    • Passcode validity duration: The number of minutes for which the passcode will be valid, after the passcode was sent.
  3. TEXT MESSAGESelect the language in which you want to view the text message, and then click View to preview the text message.
  4. Use the message template to create the wording that is sent in the SMS message to the user.

    IAM provides a fixed list of message variables for your use. Click Message variables to view the available variables and variable definitions.

    Note

    When you use the ${companyName} variable, be sure to add your company name to the Company name field on the Branding page in Settings. If you don't, your company details don't appear in email notifications, SMS notifications, or in the Oracle Mobile Authenticator (OMA) app when a user completes MFA enrollment.

  5. Click Save changes.
  6. Confirm your changes.