Multi-factor authentication logins can be enforced for users of a certain client in two ways. The first one is configuring the client in the AAI Resource Registry "Intended Audience and Expert Settings". In this case, the edu-ID OP requires multi-factor authentication, no matter what is specified in the authentication request.
The edu-ID OIDC implementation also supports the use of essential id_token claim request for acr. By adding the following parameter to the OIDC authentication request, a Relying Party can enforce multi-factor authentication for users that want to access the service:
claims=%7B%22id_token%22%3A%7B%22acr%22%3A%20%7B%22essential%22%3A%20true%2C%22values%22%3A%20%5B%22https%3A%2F%2Frefeds.org%2Fprofile%2Fmfa%22%5D%7D%7D%7D
URL-encoded version of:
claims =
{
"id_token":
{
"acr":
{
"essential": true,
"values": ["https://refeds.org/profile/mfa"]
}
}
}
With this approach, a client is able to enforce multi-factor authentication only in some situations (like strongly protected pages) or for some users while not enforcing it for others.
To enforce two-step login, add the above acr claim to the original authentication request. This also works for users already authenticated in the service for whom the second factor is subsequently requested. Note that browsers can remember an MFA-session of users so that they don't necessarily need to re-enter the second factor.
The OIDC core specifications also define the authorize request parameter 'acr_values'. It is a shorthand for the request of ID Token acr claim as mentioned above, however without specifying essential=true. That means, it only asks for MFA without enforcing it. This is the default behavior of the edu-ID OP: Enforcing MFA if the user has it configured or either the organisation policy or the client enforces it, else not asking for it. Setting 'acr_values' only hence has no effect.
However, it is important to note that according to the specifications, when using both the acr_values parameter and the ID Token ACR claim request as above, "the resulting behavior is unspecified". Clients should therefore never use both in the same request.
A client can verify in the ID Token if the user is authenticated with MFA at the OP. This can be done regardless of whether MFA has been enforced via the authorize request.
The user has an MFA session at the OP if and only if the ID Token contains the 'acr' claim with value 'https://refeds.org./profile/mfa'. Clients which enforce MFA are encouraged to check this after receiving the ID Token and before establishing the client-side user session.