Security considerations

This page summarises the security considerations you need to make with integrating with CIS2 Authentication.

You might also want to read the Security Considerations section of the OpenID Connect Core Specification.

You 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, you must apply confidentiality protection using TLS with a ciphersuite that provides confidentiality and integrity protection.

At the time of writing, the 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. However, we support TLS 1.2 at this time. You must not use of versions earlier than TLS 1.2.

Whenever TLS is used, you must perform a TLS server certificate check as per RFC 6125.

When making a token request to our token endpoint, your application needs to prove its identity so we can be sure your request is genuine.

For more details, see Token request.

Keeping your application secrets secure is very important. The OAuth standard defines two types of system - public clients and confidential clients.

We require you to have a confidential client. In practice this means:

• making token requests and user info requests from a server, not from a client-side application such as a native application or a browser-based application
• making sure the server is secure

For more details, see Securing your confidential client and Native applications.

In order to protect against hijack or re-use of an authentication request, you should provide a state parameter with the request. This value should be unique (for example, a GUID) and tied to the browser that is requesting the authentication journey. 

On a successful authentication, we value this value to you. You should then check the value matches the one you included in the original request, to ensure that the authentication 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 us to authenticate. This can then be tied to the browser by a cookie. If the authentication fails, then the session ends almost straight away. 

Once the authentication journey is completed, the user's browser is redirected back to your redirection URI. This request will contain the cookie from the user's browser, so the session can be retrieved to compare the state value. If the authentication is successful, then you can upgrade the session to a fully authenticated session.

Care Identity Service (CIS) accounts are created with a level of identity proving assurance. This is captured in a value know as the eGIF level, or Identity Assurance Level (IAL). This claim is presented in the ID token as the id_assurance_level claim, and in the user info response as the idassurancelevel claim. 

You should check that the IAL is appropriate for your use case. 

The ID token 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. 

You must check that this value is appropriate for your use case. For more details, see Choosing an assurance level.