Adaptive MFA
To use Adaptive MFA, you must have an Enterprise Plan with the Adaptive MFA addon. Refer to Auth0 Pricing for details.
With Adaptive MFA, you can:
Only trigger MFA when needed to present friction to bad actors and keep the experience for your users unchanged.
Write custom rules to trigger MFA only when a login is high-risk using your own definition of overall confidence measured by a series of confidence assessors.
Write custom rules to force users to provide additional authentication factors when there is a risk.
Adaptive MFA custom rules are only recommended in scenarios where end users are enrolled in MFA. If a user is not enrolled in MFA and your rule assesses a high risk, you will have very limited options to stop a bad actor. If the end-users are not enrolled in MFA, we recommend using the default policy that ships with adaptive MFA, which will take care of adding extra security for this use case.
If you already use rules to trigger MFA from confidence scores and you enable Adaptive MFA in the Auth0 Dashboard, some actions may be different.
How it works
Adaptive MFA not only triggers MFA when the confidence is low (high-risk), but also ensures that when a login is risky (a bad actor is attempting to log in), and a user is not enrolled in MFA, the flow does not allow the bad actor to enroll in MFA or login at all.
Because Auth0 performs risk assessment at login time, an interesting issue arises. When a login is determined to be risky and you have reason to believe it is a bad actor, it is critical to examine the actions you will allow that user to perform. This is true when the user is not enrolled in MFA and therefore you don’t have additional authenticators to challenge the user.
If a login attempt is known to be risky (low confidence score) and the user is not enrolled in MFA, consider the following scenarios:
Allowing the user to login (bypassing MFA) would let the bad actor in.
Allowing the user to enroll in MFA would allow the bad actor to add their own authenticators, thereby allowing the bad actor in.
Therefore, Auth0 challenges users with the only authenticator available other than password (email OTP). Once the user passes the email challenge, Auth0 can decide to collect a phone number from the user (asking them to enroll in MFA).
Security flows to handle this scenario are built into Adaptive MFA so that you do not have to build in extra security.
With Adaptive MFA enabled, Auth0 uses a combination of three confidence scores to assess risk and assign an overall risk score:
| Assessor | Risk Signal | How it is computed |
|---|---|---|
NewDevice |
User attempts to sign in from a device that has not been used to access the account in the last 30 days. | User agent and browser cookies identify a device. At login time, the device information is compared to the list of devices for the account. |
ImpossibleTravel |
User attempts to sign in from a geolocation that indicates an impossible travel situation when compared to the last login. | The distance between the last valid location and the location of the attempted sign in is computed; the time difference between the sign in attempt is used to compute a hypothetical travel velocity. Velocity is compared to a reasonable travel velocity. |
UntrustedIP |
User attempts to sign in from an IP address known to be associated with suspicious behavior. | Auth0 uses intelligence from traffic events to determine the likelihood that the IP address has been used by bad actors to perpetrate high velocity attacks. |
| Overall Risk Score | A combination of all 3 factors above. | Auth0 uses all 3 scores to assign an overall score. Use rules if you want to implement your own business logic. |
When Auth0 triggers MFA on low confidence (high-risk) logins, we disregard any existing MFA session such as when the user checks Remember this browser. Users have no way to go around the MFA challenges triggered by Adaptive MFA.
Customize Adaptive MFA
You can use Auth0 rules to customize how the risk is assessed in your business environment. You can access individual scores for each login attempt to build rule actions to add additional logic. To learn more, read Customize Adaptive MFA with Rules.
The risk assessments in rules will not work unless you enable Adaptive MFA under Security > Multi-factor Auth in the Auth0 Dashboard.
Support and limitations
Authorization flows
All endpoints that provide an auth flow to the user are available for use with Adaptive MFA. These flows typically start with a call to /authorize with different grant types and/or prompts:
Single Sign-on (existing session)
OAuth2 (implicit, authorization code, hybrid)
SAML
WS-Federation
Auth0 Adaptive MFA does not work in M2M scenarios such as client credentials or legacy calls directly to the /token endpoint.
Social connections
Adaptive MFA is supported for social connection types where an email address is available for each user. Most connection types fit into this category. An email address is required because of the email challenge step when users are not already enrolled. Without an email address, Auth0 cannot perform the email challenge and the transaction will be blocked. This may be a limitation that you accept, but it is not a security risk.
Adaptive MFA is not supported for connection types where an email address is not available for each user. These situations occur typically for Facebook connections if the email claim is not requested and with Azure Active Directory if the identifier is a username and email address is not available.
Auth0 feature support
The following table lists Auth0 implementations and their functionality with Adaptive MFA:
| Login Flow Implementation | Adaptive MFA Support Level |
|---|---|
| New Universal Login | Supported |
| Classic Universal Login with no customization | Supported |
Classic Universal Login (hosted by Auth0), custom login page with lock.js Lock template |
Supported |
Classic Universal Login (hosted by Auth0), custom login page with auth0.js Custom Login Form template |
Supported |
Classic Universal Login (hosted by Auth0), custom login page with passwordless flow and lock.js Passwordless template |
Not supported because it does not make an email address available, which is a requirement. |
Web or native apps using Resource Owner Password Grant (ROPG) flow (including those using older versions of lock.android and lock.swift SDKs |
Supported with the following limitations: • Works when all end users are already enrolled in MFA (when users are required to enroll on signup). Users who are not already enrolled will be blocked in risky scenarios. • Risk assessment to determine if a user is logging in from a new device will not work. The ROPG flow does not support the browser cookies needed to determine risk. • You must pass auth0-forwarded-for header with information from the originating IP address for risk assessments for IP reputation to work. |
| Native apps using newest version of SDKs that support embedded Universal Login | Supported |
| Native apps using newest version of SDKs and ROPG flow | Supported with the following limitations: • Works when all end users are already enrolled in MFA (when users are required to enroll on signup). Users who are not already enrolled will be blocked in risky scenarios. • Risk assessment to determine if a user is logging in from a new device will not work. The ROPG flow does not support the browser cookies needed to determine risk. • You must pass auth0-forwarded-for header with information from the originating IP address for risk assessments for IP reputation to work. |
Flows hosted by you (not Auth0) using lock.js or auth0.js that perform cross-origin authentication (co/authenticate endpoint) |
Supported |