Overview
After enabling a social or enterprise connection to allow users to use Single Sign-On (SSO) to log in to the application, the users are forced to use Multi-Factor Authentication (MFA) after logging in.
This can result in the user getting prompted twice for MFA when MFA is triggered on the Auth0 tenant.
Applies To
- Single Sign-On (SSO)
- Enterprise connections
- Social Connections
- Multi-Factor Authentication (MFA)
Cause
When using an Enterprise (or Social) connection, Auth0 authenticates the users using an external Identity Provider (IdP). These external IdPs can mandate additional security, such as MFA, which cannot be controlled from the Auth0 tenant side.
Solution
If MFA is being enforced by a 3rd party IdP, then any changes to MFA requirements within the IdP would need to be configured by the IdP admins and cannot be controlled from the Auth0 side. The user is subject to the IdP’s requirements for authentication before Actions can be triggered in the post-login part of the flow.
- For example, if the IdP is Azure, review How to Enable and Use Microsoft Entra Multifactor Authentication for specific details on the configuration of MFA on the Azure side.
If the end user had previously used a Database connection, for example, they would have only been subject to the Auth0 tenant’s MFA policies, as Auth0 would have been the only IdP involved when using a database-type connection to authenticate users.
Another approach is to suppress the Auth0 tenant’s MFA for just users on connections known to enforce their own upstream MFA on the IdP’s side.
For example, the following post-login action could check the connection ID that was used to authenticate the user, skipping MFA if the ID matched one that has its own MFA and using the Auth0 tenant’s MFA for all other connections:
if (event.connection.id === "<enterprise_or_social_connection_id_here>") {
return //skip MFA and end Action early
}
//trigger MFA
api.multifactor.enable("any",{allowRememberBrowser:false});
NOTE: Care should be taken when allowing MFA to be suppressed. The parameters used for this purpose should not be something end users can manipulate and create an MFA vulnerability.
It may also be possible to determine whether the upstream IdP did prompt for MFA too, but this would be dependent on the IdP providing this information in tokens it returns to Auth0 during the login. For example, please see this article for more information: Determine if User has Passed MFA in Social SSO / Enterprise SSO.