Authentication methods and levels

1 Authentication Context Class (ACR)
2 Authentication Method Reference (AMR)
3 Customizing authentication method selection
- 3.1 Standards based: predefined authentication flows
- 3.2 Extended: Dynamic authentication method selection

The OIDC protocol is designed to be interoperable and independent of authentication methods. In addition, the basic principle and architecture pattern at the core of both OAuth2 and OIDC is delegation. The Relying Party (RP) / client application delegates the responsibility of authentication to the OpenID Provider.

In context of selecting authentication methods in different contexts, there are two terms in the OIDC specification it is important to understand: ACR and AMR

Understanding these terms set the basis for how to integrate when custom selection of authentication methods are required. The options below is mainly relevant to the authorizationendpoint.

Authentication Context Class (ACR)

As described in OpenID Security Domains the OpenID Provider then implements the business rules and policies of a Security Domain. As part of the OIDC protocol the authorization endpoint allows for specification of “acr_values”, in other words the requested level of authentication (Level Of Assurance - LoA) for the authentication process. This is only relevant for OpenID Security Domains with multiple levels of authentication (and hence an optional parameter).

For example the “acr_values” can be set to “edias-loa-substantial” or “edias-loa-high” requesting various levels of authentication for an EIDAS complaint Security domain.

Consequently, the concept is that the RP / client delegates the authentication to the OpenID provider, setting the functional business requirements for the authentication. The OpenID Provider is responsible for allowing only relevant authentication methods (and implement these). The RP / client does not control the actual selection of the authentication method dynamically. Instead, this is preconfigured/delegated to the OpenID Provider, making the integration. This is further emphasized in that there is no standard parameter in the OIDC or OAuth2 protocol for selecting authentication method.

Note that the “acr” claim is returned in the ID Token , describing what LoA the authentication was don on.

Authentication Method Reference (AMR)

As noted in the ID Token description, the OpenID standard also describes an optional claim “amr: JSON array of strings that are identifiers for authentication methods used in the authentication…”. However the standard does not describe the claim further stating “The definition of particular values to be used in the amr claim is beyond the scope of this specification.”

The RFC 8176 elaborates more here, both describing some possible values of the amr claim, in addition to explain what these values should represent and recommended usage. It is particularly interesting to note the discussion related to Authentication Context Class:

An Authentication Context Class specifies a set of
business rules that authentications are being requested to satisfy.
These rules can often be satisfied by using a number of different
specific authentication methods, either singly or in combination.
Interactions using "acr_values" request that the specified
Authentication Context Classes be used and that the result should
contain an "acr" claim saying which Authentication Context Class was
satisfied.  The "acr" claim in the reply states that the business
rules for the class were satisfied -- not how they were satisfied.

In contrast, interactions using the "amr" claim make statements about
the particular authentication methods that were used.  This tends to
be more brittle than using "acr", since the authentication methods
that may be appropriate for a given authentication will vary over
time, both because of the evolution of attacks on existing methods
and the deployment of new authentication methods.

In other words, using the “acr” claim in an RP/client makes the integration less interoperable and more brittle as this creates a dependency between the specific authentication method and the specific RP/client.

Customizing authentication method selection

Given the description of the AMR and ACR claims above, this section describes two alternative integration methods for RPs/clients. One method uses a predefined “flow” setting the available authentication methods, while the other uses a more dynamic approach. The first integration method is according to the OIDC spec and the other uses a custom OIDC parameter.

Standards based: predefined authentication flows

This is the standard integration method, is based on standard OIDC parameters and least “brittle”.

As part of a OpenID Provider setup (and OpenID Security Domains), a set of “authentication flows” are defined. These flows are configured and built using one or more authentication methods. The flows are generic in relation to RPs/clients and can be reused across several. The flows represent the different paths or alternatives to authenticate, for example:

One of: Smart Card, Mobile and FIDO2
Multi factor: First Username/password, then OTP using SMS
Only one: FIDO2

Note that a number of different flows may be defined and implemented (both standard or custom flows), and the flows may or may not present end-user UIs. If relevant, the flows may have different predefined behaviour depending on the “acr_values” parameter if relevant to the OpenID Security Domains and the RP/client.

When configuring a specific OIDC client, a (predefined) flow is associated to that client. Hence, the RP/client does delegates the authentication to the OpenID Provider, and the OpenID Provider uses the associated (possibly shared) flow to run the authentication process.

As a consequence, a flow may be changed on the OpenID Provider side independently of the RPs/clients. For example is a new authentication method is added or removed, this may be done without any dependency to the various RPs/clients.

Extended: Dynamic authentication method selection

This method allows for more dynamic control of the authentication methods. However, this method applies a custom parameter in the OIDC request (the authorization endpoint) and and creates an implicit dependency between the RP/client and the authentication method(s).

As with the standard based setup, the client is configured using a predefined “authentication flow” upon OpenID Provider setup. However, this flow is not static, but allows for a mor dynamic behavior based on a custom parameter: “amr_values”. The custom parameter uses the Authentication Method Reference (AMR) values as described above. By adding a “amr_values” parameter (in addition to the standard “acr_values”), the client may control the custom flow associated to the client.

For example, if the flow is initially set up with “Smart Card, Mobile and FIDO2” the “amr_values” may include only “Mobile and FIDO2” and hence disable the “Smart Card” alternative from the flow in this session. This will also allow the RP/client to select only one of the tre options, ex. “Mobile” allowing for a potentially more optimized end-user interaction.

A small warning

It is worth noting that this creates a dependency between the RP/client, the initial flow and the AMR-naming of the various authentication methods. Both the initial flow and the AMR-naming of various authentication methods may differ between OpenID Security Domains!.

Changes to the flow and/or the removal/introduction of authentication methods may impact the RP/client and changes may need coordination.

The definitions of both “amr” and “acr” values depend on the OpenID Security Domains!