8. Security considerations

Your application, as the Relying Party, should be concerned with end-to-end security whilst using NHS CIS2 Authentication platform for authentication. Of particular note are the recommended method of client authentication and the requirements relating to use of TLS from the Security Considerations section of the  OpenID Connect Core Specification. 

Implementations MUST support TLS. Which version(s) ought to be implemented will vary over time, and depend on the widespread deployment and known security vulnerabilities at the time of implementation. To protect against information disclosure and tampering, confidentiality protection MUST be applied using TLS with a ciphersuite that provides confidentiality and integrity protection.

At the time of writing the current set of supported ciphersuites is:

• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-ECDSA-AES256-GCM-SHA384
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-ECDSA-AES128-GCM-SHA256

At the time of writing TLS 1.3 is the latest version. NHS CIS2 Authentication's endpoints support TLS 1.2 at this time. Relying Parties MUST NOT allow use of versions earlier than TLS 1.2.

Whenever TLS is used, a TLS server certificate check MUST be performed as per RFC 6125.

Client Authentication is the term used in the OAuth standard for the system (or software) authentication. This is not the authentication of the healthcare worker, who is also often referred to as the client.

Whilst the simple option of client_id and client_secret is available for a quick start, NHS CIS2 Authentication recommend that clients use the private_key_jwt mechanism with a client hosted jwks endpoint for the public key. This offers increased security and gives clients the control over the credentials, with the ability to seamlessly roll over to a new keypair whenever required. More details can be found in the Authorisation Code Flow: Client Authentication section.

Keeping your application secrets secure is very important. The OAuth standard defines two types of system - public clients and confidential clients. Read more about what this means, and how it helps you design your software, in securing your confidential client.

In order to protect against hijack or re-use of an authorisation request, your application (as the Relying Party) should provide a state parameter in the authorize request. This value should be unique (e.g. a GUID) and tied to the browser (user-agent) that is requesting the authentication journey. 

On a successful authentication, this value is then returned to you. You then check the value matches the one you included in the original request, to ensure that the authorize request cannot be replayed. 

The usual way to achieve this is to store the value in a session store, which you might create when sending the user to NHS CIS2 Authentication to authenticate. This can then be tied to the browser (user-agent) by a cookie. If the authentication fails, then the session ends almost straight away. 

Once the authentication journey is completed, the user is redirected back to your redirect_uri. This request will contain the cookie from the user's user-agent, so the session can be retrieved to compare the state value. If the authentication is successful, then the session can be upgraded to a fully authenticated session on the Relying Party. 

CIS Identities are created with a level of identity proving assurance. This is captured in a value know as the eGIF level, or ID Assurance Level. This claim is presented in the idToken as the id_assurance_level claim, and in the userinfo as the idassurancelevel in the profile section. 

Applications SHOULD check that the id_assurance_level is set to 3 to ensure that the identity has been properly proven and assured. 

The idToken also contains the authentication_assurance_level claim. This value indicates the level of the authentication that has taken place and takes into account the authenticator binding process and type of authenticator. In the future, this may also be dynamically altered depending on the circumstances of the authentication journey. 

Applications MUST check this value and in most cases it is expected that applications will require a Level 3 authentication (a value of 3) providing the highest level of authentication security commensurate with protecting healthcare data. 

1. Registration
2. Discovery
3. Authorization code flow
4. Scopes and claims
5. ACR and AMR values
6. Signatures
7. Key management
8. Security considerations
9. Session management
10. Role selection