Choosing an authentication component
NHS CIS2 Authentication has some specific requirements for auth that suppliers need to be able to support.
Overview
NHS CIS2 Authentication has some specific requirements for auth that suppliers need to be able to support - some are essential, others only needed when, for example, JWKS endpoints need to be supported.
Examples of these third-party components are Cognito, Okta, Auth0.
Application suppliers and developers should consider carefully whether their chosen (or incumbent) component/service offers sufficient control over the authentication process. Suppliers are also strongly encouraged to raise deficiencies in their chosen products with the relevant providers, such as AWS Customer Managers for issues with Cognito.
Required capabilities
Additional query string parameters
The ability to add directives to the authorise request is extremely important. Some components do not allow attributes that are part of the OIDC spec.
For example:
- authentication requirements - required to be able to request "SSO" type behaviour, or not
- prompt=login
- max_age=[x]
- acr values - used to indicate what types/levels of authentication are acceptable and should be offered to the user
- acr_values
ID Token introspection
For example examination of the auth_time, and rejection of the token if it is too old.
This is required to ensure that any authentication requirement directives have been followed, and check that the initial authorize url was not tampered with. A malicious actor could remove the prompt=login or max_age value to allow an existing session to be used, and if the relying party do not check this value then this will go unnoticed.
ID Token availability
For example the ability to receive the NHS CIS2 Authentication ID Token in the application code.
This is most often required so that the relying party application can then exchange the NHS CIS2 Authentication ID Token for an API platform access token, using separate authentication and authorisation.
Desirable capabilities
Support for better client authentication
Most implementations allow the user of client id and client secret for an OIDC client to authenticate against the OpenID provider (e.g. NHS CIS2 Authentication). However, this form of client authentication, while simple, is less secure than others, and does not allow for seamless rollover of client credentials.
Not all components will allow the preferred "private_key_jwt" client authentication with client JWKS endpoint. See detailed guidance on this topic.
Workarounds
Sometimes, it may be possible to work around the deficiencies of a product.
For example, for Cognito, which doesn't currently support the query string parameters, or JWKS endpoint, one can use a Lambda process to decorate to effect change on the authorize URL, or JWKS endpoint provision. See an example.
Last edited: 18 June 2024 2:52 pm