Authenticator guidance for developers

CIS2 Authentication supports a range of authentication methods, including Windows Hello, Microsoft Authenticator, iPads, security keys and smartcards. All our authenticators are 'strong' in that they all use multi-factor authentication (MFA), not just a username and password. But some are stronger than others, and our authenticators come in two 'assurance' levels:

• AAL2 - 'high confidence'
• AAL3 - 'very high confidence'

When you integrate your software with CIS2 Authentication, you'll need to decide which assurance level is appropriate for your application, and make sure your users sign in with a suitable authenticator.

At a technical level, this is handled with 'ACR' and 'AMR' values.

For a full list of the authenticators we support, including assurance levels, see Care Identity Service authenticators.

As an application provider, you’ll need to decide which assurance level is suitable for your application. This should be based on:

• the risk profile of your application, meaning what functions and data it provides access to
• the assurance level required by any national APIs you need to access - for details, see the relevant API specifications in our API catalogue

CIS will then allow users to sign in with an appropriate authenticator, as follows:

If your application requires AAL2 for some functions and AAL3 for other functions, it is possible to implement 'step-up' authentication as follows:

• when the user first signs in, use AAL2
• if a given user needs to access an AAL3 function, and they have signed in with an AAL2 authenticator, ask them to re-authenticate with an AAL3 authenticator (you can do this simply by omitting the prompt parameter)

To ensure users sign in to you application with a suitable authenticator, you need to specify an Authentication Context Class Reference (ACR) value when you make an authentication request.

Specifically, include one of the following values in the acr_values request parameter:

The list of authenticators available to the user might be limited based on their client device.

Following a successful authentication request, the resulting ID token will contain:

• an acr claim specifying which of the above ACR values was used to authenticate the user
• an authentication_assurance_level claim which will be either 2 (if an AAL2 authenticator was used) or 3 (if an AAL3 authenticator was used)

You can, in theory, specify multiple ACR values, but we'll only look at the first one.

We offer support for the following additional ACR values, however these are subject to change at any time and should not be used. Requesting a specific authenticator limits the authenticator choice for a user and goes against our National Registration Authority policy in restricting access to national clinical systems.

Use of these ACR values is subject to the following caveats:

1. Use of an ACR value inappropriate for the user's device may cause the authentication to fail.
2. If the user is using more than one application and they use different ACR values then the user may experience multiple authentication events.
3. Providing one of these ACR values will skip the end user prompt to select an authenticator.

If you need to use a specific authentication mechanism, contact us first to discuss.

When you make a token request, we return an Authentication Methods Reference (AMR) value in the amr claim within the ID token. This tells you which authenticator was used when the user signed in, as follows: