You cannot integrate Datadog directly into the cloud-hosted version of FusionAuth. The only relevant section in the documentation is "Use Datadog Agent on a Remote Host." This requires setting up Datadog to monitor FusionAuth using the Prometheus Metrics API endpoint. For monitoring failed 2FA rates, FusionAuth does not currently have built-in support. There is no webhook for failed MFA, but you can use the failed login webhook to monitor incorrect password attempts.

Retrieve system metrics using Prometheus
Use the Datadog Agent on a remote host
User login failed webhook

It makes sense that this problem is happening. Once we have a SSO session on the computer/browser, then if MFA is required as part of the hosted workflows, FusionAuth will prompt for it based on the existing SSO session.

To solve this problem, you could opt to not make use of the FusionAuth SSO session. So, if you are using our Advanced themes, you could remove the option for an SSO session by removing the Keep Me Signed In checkbox from the theme. Using our Simple Themes, you would set the SSO Session to a really short duration in Tenant Settings (2 seconds, for instance) thus effectively removing the SSO session. Both of these options would eliminate this problem described above.

If you still wanted to generate a FusionAuth SSO session, and you wanted to solve this specific problem, you could use Advanced Themes and hardcode a logout link on this MFA page to allow a user to reset the session and login again. This same solution is not possible using Simple Themes, but a feature request could be logged if you wanted to see this logout link included in Simple Themes at a later date.

With the Essentials plan, you do have MFA available to you on a Tenant level under Tenant>Multi-Factor. To have users set up MFA you either need to set MFA to Required, where users will need to set up MFA to complete a login or you will need to enable the “Self Service Account Management” page so users can visit it to set up MFA. So you can set up MFA for any Tenant to make it available to users.

https://fusionauth.io/docs/lifecycle/authenticate-users/multi-factor-authentication

https://fusionauth.io/docs/lifecycle/manage-users/account-management/

In order to change MFA settings at the Application level for enabling MFA on a project by project basis, you would need to upgrade to the Enterprise plan.

Thanks for the question! If you navigate to Applications > Index View - FusionAuth > Multi-Factor Tab then you can see an option to require MFA for the FusionAuth Admin UI Application. You will likely want to enable application specific trust as well.

You’re correct that user_support_manager is the right role, but it has a limitation: it can only remove MFA devices if the manager has the user’s MFA code or recovery codes. Only admins can disable MFA without those.

If you want to remove MFA without needing a code, you’d need to use the User API to clear the user’s MFA data. Also, confirm that both support managers have the same role assigned under their registrations in the FusionAuth application. Check this under each user’s Source tab in the Admin UI under registrations.roles.

More details:

Update a User via API

FusionAuth Admin UI Roles

Just an FYI, as of 1.59.0, phone number verification is now fully supported in FusionAuth.

Read more here: https://fusionauth.io/docs/lifecycle/manage-users/verification/gate-accounts-until-user-phone-verified

This is a known issue with Twilio’s SMS service. A good approach is to use a dedicated Twilio phone number only for MFA codes, and another number for other notifications so users are less likely to reply with “STOP.” Alternatively, you could switch to other MFA methods like TOTP, using apps such as Google Authenticator or Authy, or use email-based MFA. Keep in mind that once a user sends “STOP,” Twilio blocks all future messages until they opt back in by texting “START.” Educating users not to reply “STOP” to MFA messages is also helpful.

FusionAuth's TOTP implementation is compatible with most popular authenticator apps that follow the industry-standard TOTP algorithm, specifically those using HMACSHA1. While we cannot provide an exhaustive list, here are some commonly used authenticator apps that are known to work with FusionAuth:

Google Authenticator Authy Microsoft Authenticator LastPass Authenticator 1Password

Compatibility Check:

If an authenticator app does not support FusionAuth’s TOTP, it will simply fail to recognize the QR code when scanned.

Documentation Reference:

For more details about FusionAuth's TOTP implementation and requirements, refer to the FusionAuth TOTP Documentation.

Most users should have no issues using any modern TOTP-based authenticator app.

FusionAuth does not currently provide out-of-the-box support for security questions.

If security questions are critical to your solution, you would need to implement this functionality externally and integrate it with FusionAuth using API calls. For example:

Authoring Security Questions: Create a custom interface for users to set up their security questions and store these securely in your system. Using Security Questions During Registration: Extend your registration workflow to include security questions, then associate the responses with the user data stored in your database. Using Security Questions During Credential Recovery: Implement a custom flow to verify the user's identity using security questions before proceeding with a password reset, and use FusionAuth’s APIs to handle credential recovery.

By building this functionality externally and integrating it via FusionAuth’s APIs, you can achieve the desired security question workflow while maintaining compatibility with FusionAuth.

FusionAuth does not currently provide out-of-the-box support for security questions.

If security questions are critical to your solution, you would need to implement this functionality externally and integrate it with FusionAuth using API calls. For example:

Authoring Security Questions: Create a custom interface for users to set up their security questions and store these securely in your system. Using Security Questions During Registration: Extend your registration workflow to include security questions, then associate the responses with the user data stored in your database. Using Security Questions During Credential Recovery: Implement a custom flow to verify the user's identity using security questions before proceeding with a password reset, and use FusionAuth’s APIs to handle credential recovery.

By building this functionality externally and integrating it via FusionAuth’s APIs, you can achieve the desired security question workflow while maintaining compatibility with FusionAuth.

FusionAuth's TOTP implementation is compatible with most popular authenticator apps that follow the industry-standard TOTP algorithm, specifically those using HMACSHA1. While we cannot provide an exhaustive list, here are some commonly used authenticator apps that are known to work with FusionAuth:

Google Authenticator Authy Microsoft Authenticator LastPass Authenticator 1Password

Compatibility Check:

If an authenticator app does not support FusionAuth’s TOTP, it will simply fail to recognize the QR code when scanned.

Documentation Reference:

For more details about FusionAuth's TOTP implementation and requirements, refer to the FusionAuth TOTP Documentation.

Most users should have no issues using any modern TOTP-based authenticator app.

Hi Martin, we updated the feature matrix here: https://fusionauth.io/pricing?step=plan&hosting=self-hosting to make it clear that application specific MFA configuration is an enterprise only feature.

Cheers!

@dan Also, depending on the workflow, if a user does NOT federate but does NOT check "trust this computer" they will NOT establish "MFA trust". Without trust, a user will be prompted to MFA again. Of couruse, With "MFA trust", they will not be prompted. This answer is implicit to this conversation, but MFA policies and FusionAuth center around this check box and trust (with the current edge case of Federation noted).

You can't do this with the hosted login pages, but there is an issue to allow/disallow MFA on an application by application basis: https://github.com/FusionAuth/fusionauth-issues/issues/763

Currently, you can't bypass MFA, but you can do an end run around by using the Login API.

You can start multi factor with a code you provide: https://fusionauth.io/docs/v1/tech/apis/two-factor/#start-multi-factor

Then complete the login process with that known code: https://fusionauth.io/docs/v1/tech/apis/login/#complete-multi-factor-authentication .

Thanks for addressing this use case. Your proposal, however, runs counter to any standardization effort: Long live OAuth! 🙂

A better approach would be to switch from a password grant to the use of authorization codes (instead of passwords) to obtain the access token. This is fully within the OAuth framework and does not introduce fusionauth-specific hacks into the solution.

We have created as simple html page that redirects to the fusionauth authorize endpoint with grant_type=authorization_code. The browser handles MFA as usual. Upon redirecting to this page, the page can harvest the authorization code for the user to copy. From there proceed with into authorization code in place of a password.

PS: Long live OAuth!

There is no out of the box solution for this. See https://github.com/FusionAuth/fusionauth-issues/issues/763 for the tracking issue.

However you can still do this with the API.

If you are consuming a JWT, you can see if a user has enabled two factor authentication by putting a claim in the JWT using a populate lambda. Look at the user object and if the twoFactor.methods array isn't empty, they have enabled MFA. If you are not using a JWT but instead examining the user object directly, you can look at the same attributes.

In each case, you should set up a page to allow the user to enable MFA and keep directing them there until they have done so. You can either build your own 'MFA enable' page or, if you have a paid edition, use the themeable account self service pages, as documented here: https://fusionauth.io/docs/v1/tech/account-management/