How-tos

Using Two-Factor Authentication for Access Control

Discover Multi-factor Authentication (MFA) use cases that Cloudentity supports. Check how to enable MFA in your workspace and how to set up the MFA protection for basic scenarios.

Prerequisites

  • Access to an Cloudentity tenant

  • MFA services (SMTP gateway and Twilio) must be configured and enabled in your tenant.

  • Incoming IDP claims must provide user’s e-mail address and/or phone number. These claims must be mapped to their corresponding authentication context attributes: email, email_verified, phone_number, phone_number_verified.

    Identity Pools

    Identity Pool IDPs do not support MFA yet.

MFA in a nutshell

MFA is a security mechanism that add an extra layer of protection so that the authentication is performed using at least two factors, for example, the username-password and the verification code. In context of the OAuth 2.0 flow, this security layer is applied when the resource owner is asked for an authorization grant by the client app via the authorization server (see rfc6749 section 1.2 and 1.3) - which is Cloudentity in our case. As part of this process, Cloudentity must authenticate the resource owner and ask for authorization. MFA can be applied at both of these stages.

MFA is a secure way of verifying who the user is before allowing them to access the desired application or perform any other sensitive operation. It is mostly used during the login process. MFA provides increased security and is a core component of a strong identity and access management policy. It helps reduce risk of unauthorized access and ensures that the party initiating the sensitive operation is the right one. This usage of MFA is what is called transactional since it occurs outside the traditional authentication context.

MFA requires multiple methods of authentication from independent categories of credentials. It combines two or more credentials, each corresponding to a different category (authentication factor). There are three most common authentication factors:

  • Knowledge factor: what the user knows (for example, a password or PIN)
  • Possession factor: what the user has (for example, a mobile phone, a security token, a mailbox)
  • Inherence factor: what the user is (for example, biometric verification or voice recognition).
[mermaid-begin]
flowchart LR subgraph Authn factor 1 A[Username & password] end A[Username & password] --> B{OK?}; style F fill:#f9f2ab,stroke:#333 B -->|Yes| C[MFA enabled?]; B -->|No| F[Login failure]; style A fill:#62bed4,stroke:#333 subgraph Authn factor 2 D[MFA challenge] end C -->|Yes| D[MFA challenge]; style D fill:#62bed4,stroke:#333 D --> G{Passed?}; C -->|No| E[Login success]; style E fill:#ade48c,stroke:#333 G -->|Yes| H[Login success]; style H fill:#ade48c,stroke:#333 G -->|No| I[Login failure]; style I fill:#f9f2ab,stroke:#333

There are a number of MFA types:

  • Mobile apps: MFA software’s mobile apps
  • Software token: Offline tokens that enable users to use MFA mobile apps
  • Push notifications: Sent to a user’s mobile device asking them to approve or deny the authentication request
  • Hardware token: Pieces of hardware users carry with them to authenticate their identity, for example, USB devices
  • One-time passwords (OTP): Authentication codes sent via via SMS, voice, or email
  • Risk-based authentication (RBA) software: Intelligent or adaptive MFA uses real-time information about end users to evaluate their risk and prompt them to authenticate when needed.
  • Passwordless authentication: Passwordless (invisible) authentication uses RBA factors (for example, location or IP address).
  • Biometrics: Biometric authentication factors, for example, facial or fingerprint recognition
  • MFA as a service: Using an MFA provider who offers a cloud-based MFA solution as a service
  • On-premises MFA: On-premises MFA solutions run locally on your server.
  • Offline-available MFA: Authentication using a mobile app with offline access to OTPs or one that uses a hardware-based U2F security key
  • Enterprise solutions: Companies that manage MFA at a large scale for a number of users need software offering administrator consoles, endpoint visibility, and single sign-on (SSO)

MFA with Cloudentity

Cloudentity supports MFA mechanisms both in SaaS and local deployments. As an administrator, you can configure and enable MFA for specific tenants, particular workspaces, and individual users.

MFA supported in Cloudentity uses the combination of the knowledge factor (username and password) and the possession factor (One Time Password (OTP)). OTP used for an additional verification of the user’s identity can be handled in Cloudentity in two ways:

  • OTP sent via SMS (supported by Twilio)
  • OTP sent via mail (supported by any SMTP gateway)

With Cloudentity, you can use the transactional MFA in the following scenarios:

  • To restrict the access to the client application for the user

    After the user enters the username and password, they are prompted to select an additional verification method: e-mail or SMS. The methods are available depending on what data the user has added and enabled for MFA on the identity provider (IDP) side. After selecting the email verification, for example, a one-time-password (OTP) code is sent to the user via mail. After providing the code, it’s verified and, either allows the access or denies it, depending on the outcome of the verification. If the whole process succeeds, the client app can proceed to asking for the access token. This process is outlined in the diagram below:

    [mermaid-begin]
    sequenceDiagram participant User participant Cloudentity participant Client app User->>Client app: Login request Client app->>Cloudentity: Redirect Cloudentity->>User: Request credentials via IDP User->>Cloudentity: Provide credentials via IDP Cloudentity-->>Cloudentity: Check MFA requirements Cloudentity->>User: Send MFA challenge (E-mail/text) User->>Cloudentity: Send MFA challenge response (OTP code) Cloudentity-->>Cloudentity: Verify MFA response Cloudentity->>User: Ask for consent User->>Cloudentity: Respond with consent grant Cloudentity-->>Cloudentity: Verify consent Cloudentity->>Client app: Grant authorization

    At the end of the process, client app has the authorization code from Cloudentity, which it can use to ask for the access token.

  • To restrict the consent grant for scopes

    After the user enters the username and password (and possibly completes the authentication MFA), the consent screen gets displayed with the requested scopes listed. When MFA protection is enabled on selected scopes, additional actions are required. The user needs to select the MFA method and enter OTP provided by them via mail or SMS. As soon as the verification code is provided and its verification is successful, the scope becomes available for granting.

Assign the MFA Policy

To configure Cloudentity so that it prompts for MFA in specific scenarios, you need to assign a policy with the MFA validator. Cloudentity provides such a policy out of the box, as shown later in this document.

You can assign the MFA policy to different entities, depending on what you want to protect with MFA.

Restrict Access to the Client

In this scenario, you assign the MFA policy to an application as a mechanism enforcing an additional authentication of the user who tries to access the application, which is when the policy gets validated.

Step-by-step

  1. Select a workspace from Workspace Directory.

  2. From the sidebar, select Policies and make sure you have an MFA policy defined on the policies list (it should be there by default).

  3. From the sidebar, select Application > Application-of-your-choice.

  4. Navigate to the Governance section, open the policy selector for User policy, pick the MFA policy, and save the new setup.

    Result

    Users now have to complete MFA in order to log in to the target application. Cloudentity validates this by checking the presence of the following claims in the token received from the IDP:

    • email claim must be present together with the email_verified: true flag in case of e-mail verification.

    • phone_number claim must be present together with the phone_number_verified: true flag in case of phone verification.

Check how it works

To check if the access to the application is restricted with the MFA policy as assigned, take the following steps:

  1. Try to log in to your application (Cloudentity Demo Portal is shown in the video).

  2. In the MFA-method-selection window that shows, select a method you want to use for an additional verification of your identity.

  3. Check your mail/phone for the verification code, enter it into the field, and select Verify.

    Result

    You can access the application now.

Restrict Granting Scopes

In this scenario, you assign the MFA policy to a scope as a mechanism enforcing an additional authentication of the user who tries to grant the scope, which is when the policy gets validated.

Video Guide

Step-by-step

  1. From the sidebar, select Applications > Services > Service-of-your-choice > Scopes > Scope-of-your-choice (the video shows the Email scope, found under Applications > Services > Profile > Scopes > Email).

  2. For the scope of your choice, open the policy selector for Consent Grant, pick the MFA policy, and save the new setup.

Check How It Works

To check if the scope is protected with the MFA policy as assigned, take the following steps:

  1. Try to log in to your application (Cloudentity Demo Portal is shown in the video).

  2. In the consent screen that shows, select the grayed-out scope, which requires your attention.

  3. From the additional verification section that unfolds, select VERIFY NOW.

  4. In the MFA-method-selection window that shows, select a method you want to use for an additional verification of your identity.

  5. Check your mail/phone for the verification code, enter it into the field, and select Verify.

    Result

    You can now grant the MFA-protected scope.