In the Curity Identity Server multi-factor can be achieved in a two ways.
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.
previous-authenticator
Fig. 117 Authenticator MFA configuration
In the image above the SMS authenticator is configured to have the HTMLSQL 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.
If a user wants to update their phone number, i.e. accesses registration, then HTMLSQL would also run before that can be achieved.
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.
If the user already has logged in with the prerequisite factor, the 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: The user logs in to a web based mail client using both 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.
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.
max_age
freshness
The same applies when requesting prompt=login (OpenID Connect) or forceAuthN, then all factors will disregard any existing SSO sessions.
prompt=login
forceAuthN
In the example with SMS 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.
The Authentication Action SDK allows developers to design their own actions that can trigger other authenticators to run. The Curity Identity Server comes with a pre-built action that conditionally can trigger a second factor.
The difference from this approach to the chained approach above, is that the second factor can be conditional on any data, such as the user preference, time of day, location, browser, or whatever the developer decides when creating the action.
Another difference is that the resulting ACR from this approach will not be the authenticator that the action ran, but the authenticator that held the action.
Example:
HTMLSQL is configured with an action that triggers the SMS authenticator to run if the user has an attribute set in the account. When the client requests HTMLSQL the action will check the condition, and if the user account contains the attribute, SMS will run. The resulting ACR will be that of HTMLSQL, no matter if the second factor ran or not.
For more information about the Multi-Factor Action, see the documentation about the Conditional Multi-Factor action.