Enabling MFA in Auth0 for a single client application

Cartoon by Phil Johnson for MIT

Auth0 provides MFA as an additional license add-on to several of its plans. If you don’t build your initial authentication and authorization strategy with MFA, consideration must be given for how you plan to perform enrollment and enforce its use.

You could flip the big switch and require all client connections to use MFA.

Depending on the maturity of your deployment this may be the right option. Topcoder has been using Auth0 for some time with dozens of applications requiring a bit more planning before flipping the big switch.

Phased approach

To better understand the enrollment process and any other operational issues, we’ve decided to enable MFA on a few individual clients applications that are configured to allow Auth0 to function as an IdP.

This approach requires 3 steps

1. Create a rule that uses client meta data
2. Enable multi-factor options that you can support
3. Add meta data to client application.

Auth0 provides the ability to customize the behavior of MFA with rules.

The MFA settings defined in rules will always take precedence over the toggles in the Multifactor Auth section of the Dashboard.

Creating a rule

Navigate to the Rules page under the Auth Pipeline.

Click on +Create in the upper right on the rules page under

Scroll down to the Multifactor section and select Multifactor Authentication

The script for this rule is very concise

function multifactorAuthentication(user, context, callback) {
  /*
  You can trigger MFA conditionally by checking:
  1. Client ID:
  context.clientID === 'REPLACE_WITH_YOUR_CLIENT_ID'
  2. User metadata:
  user.user_metadata.use_mfa
  */
// if (<condition>) {
  context.multifactor = {
    provider: 'any',
// optional, defaults to true. Set to false to force authentication every time.
    // See https://auth0.com/docs/multifactor-authentication/custom#change-the-frequency-of-authentication-requests for details
    allowRememberBrowser: false
  };
  //}
callback(null, user, context);
}

During my testing I updated the condition and hard coded a client ID of one of the services Topcoder uses for SSO where Auth0 is the IdP. To provide more flexibility of applying MFA for a given Auth0 client without updating code and potentially breaking MFA for all connections we use client meta data to indicate if a connection should require MFA.

Adding client meta data

One of the objects that is passed into the rule is the context object. Enabling MFA on a per client bases would be easiest with a configuration change on the client meta. At the bottom of the client application I added a meta data value to indicate if that client would require MFA.

The corresponding code that uses this value is below. I update the rule shown above with this code to provide more flexibility.

function multifactorAuthentication(user, context, callback) {
 if (context.clientMetadata.REQUIRE_MFA === 'true') {
    console.log("found Meta data");
    context.multifactor = {
      provider: 'any',
      allowRememberBrowser: false
    };
  }
callback(null, user, context);
}

Testing enrollment

I navigate to the client that I’ve enabled and begin the login process I see the Topcoder customized lock screen.

After clicking LOG IN I’m presented with enrollment options.

Choosing the Google Authenticator.. provides a standard scanning option. You can also click Trouble Scanning to provide the OTP seed code.

Finally, a recovery code is provided after the correct code is entered.

Limitations

This setup was easy to get started and verify both the enrollment process and test MFA on a small subset of applications and users. After I setup my user I could see MFA enabled in the user record.

I was hoping to query the users database for the MFA attribute to see a list of users that had successfully setup MFA. Unfortunately this is not a queryable parameter. Auth0 support replied with a work around, you have to use the export-user extension and specify the attributes.

Another limitation is that Auth0 doesn’t provide a workflow to self-mange tokens. If a user decides to change their token or wants to add additional methods, this is not currently supported without using the API.