Multi-Factor Authentication#

Multi-factor authentication (MFA) is the practice of chaining a number of authentication methods together to reduce the risk of user accounts being compromised. In the Curity Identity Server, multifactor can be achieved in two ways.

  1. Using a chain of authenticators that run every time
  2. Using a multi-factor action that runs conditionally after an authenticator

Using a Chain of Authenticators#

Every authenticator can be configured with a previous-authenticator option. When this is set, the Authentication Service will ensure that any authenticators configured as prerequisites have been run before the authenticator in question is executed.

Authenticator MFA configuration
Authenticator MFA configuration. (Admin UI version: 10.6)

In the image above the SMS authenticator is configured to have the htmlSql HTML Form authenticator as login pre-requisite, and the same as registration pre-requisite.

If a client requests the SMS authenticator, the Authentication Service would first trigger the htmlSql authenticator to run and then the SMS authenticator. If a user wants to update their phone number, i.e. accesses registration, then htmlSql would also run before that can be achieved.

More than two Factors#

With this construct it is possible to create elaborate chains of authentications. Each authenticator can have a prerequisite configured, thus achieving true multi-factor authentication, not limited to two factors.

It is also possible to configure a Group authenticator as prerequisite, which would allow the user to select a factor to use from the group.

Single Sign-On and Multi-Factor#

If the user already has logged in with the prerequisite factor, the Single Sign-On (SSO) session will be used, and the user is only prompted for the second factor. Vice versa, if there is an existing session for the second factor, the user will only be prompted for the first factor.

Using the SSO expiration time setting on the authenticator , the administrator can control when each factor is triggered. A common scenario is to have a first factor with a short lifetime, and a second factor with a long lifetime.

Example: a user logs in to a Web-based mail client using two factors. The first factor has a SSO time to live set to 1 day, and the second factor set to 30 days. This means that as long as the user uses the same browser they will be asked for the first factor daily, but the second factor will only be requested every 30 days.

Freshness and Forced Authentication#

If a client requests max_age (OpenID Connect) or freshness, all factors are affected. If a max_age of 30 seconds is requested, no SSO session older than that will be used in the multi-factor flow.

The same applies when requesting prompt=login (OpenID Connect) or forceAuthN, then all factors will disregard any existing SSO sessions.

Using the ACR Parameter#

In the example with the SMS authenticator configured with htmlSql as prerequisite factor, the following applies:

  • If the client requests the ACR for the SMS authenticator, both factors will be triggered, and the resulting ACR is that of the SMS authenticator.
  • If the client requests the acr for the htmlSql authenticator, only the htmlSql authenticator is triggered and the resulting ACR is that of the htmlSql authenticator.

Using a Multi-Factor Authentication Action#

Authentication Actions can trigger other authenticators to run. The Curity Identity Server includes pre-built actions that can trigger a second factor.

One of such actions is the Conditional Multi-Factor action , which conditionally triggers a second factor. The difference from this approach to the chained authenticators approach above, is that the second factor can be conditional on any data, such as the user preference, time of day, location, browser, etc. Another difference is that the resulting ACR from this approach will not be the authenticator that the action triggered as second factor, but the authenticator that held the action.

Another of such actions is the Opt-in MFA action , which allows users to add second factors to protect their account (i.e. it’s a self-service approach).

Learn More#

Was this helpful?