1. Registration

Before being able to interact with an OpenID Provider a Relying Party must first register with the provider. During this process the following items will be exchanged:

1. The Relying Party’s Redirection URIs to which responses may be redirected.
2. A client authentication mechanism and associated credentials.
3. Whether or not the Relying Party wishes UserInfo Responses to be signed (see the UserInfo Request section for more information).
4. Whether or not the Relying Party wishes to use the Back-Channel Logout capability and if so their Back-Channel Logout URI (see the Back-Channel Logout section for more information).
5. The URI of the Care Identity Authentication's OpenID Provider Configuration Document.
6. A client identifier uniquely identifying the Relying Party.

To secure your connection to the /access_token endpoint, you select to use one of three authentication mechanisms: Client Secret, Private Key JWT and Client Secret JWT. 

Care Identity Authentication recommend that clients use Private Key JWT authentication for its increased security and ability to seamlessly roll over to new key pairs without additional configuration. If you are new to OIDC, you could choose to start with the Client Secret in the Simple OIDC Realm, but move to private_key_jwt later.

Relying Parties MUST take appropriate measures to ensure that their credentials are stored securely and are not exposed to 3rd parties.

Currently Care Identity Authentication only supports Confidential Clients that can store a credential on a trusted backend server.  Clients wanting to use a Public Client are requested to contact [email protected] to discuss further.

You call the /access_token endpoint on our Authorization Server to exchange an Authorization Code for an Access Token and ID Token.

Client Secret

This mechanism uses a Client Secret in combination with a Client Identifier to authenticate the client.

The Client Secret will be provided to the Relying Party on successful registration. The Client Secret will take the form of a randomly generated 128-bit GUID e.g. 50a6122b-6907-4a13-948e-f31d4c4714d5.

Relying Parties MUST take appropriate measures to ensure that their secret is stored securely and is not exposed to 3rd parties.

Private Key JWT

The Private Key JWT mechanism requires the Client to assert their identity by providing a JWT signed using a private key owned by the Relying Party. The Relying Party will then expose the public key of the keypair in a JSON Web Key Set for Care Identity Authentication server to read. This method allows the Relying Party to initiate a seamless transition from one keypair to another on a regular basis, or if the current keypair becomes compromised.

Care Identity Authentication OpenID Provider supports a range of signing algorithms (when using Private Key JWT), but you might need to check what we support as the minimum level is 256 bit. We recommend 512 bit.

You can do this by looking at the standard OIDC configuration well known endpoint (click here for the Production one), and looking at the values in token_endpoint_auth_signing_alg_values_supported.

More information can be found in the Authorization Code Flow: Client Authentication section.

Client Secret JWT

The Client Secret mechanism requires the Client to assert their identity by providing a JWT signed using an HMAC SHA algorithm, such as HMAC SHA-256. The HMAC (Hash-based Message Authentication Code) is calculated using a client_secret. Clients wanting to use this mechanism are directed to read the Authorization Code Flow: Client Authentication section and are requested to contact [email protected] to discuss further.

The Client Secret will be provided to the Relying Party on successful registration.  For HMAC SHA-256 it will take the form of a randomly generated 256-bit GUID e.g. a17babdb3c3b03ce892c0f0f5817e643f15f69f51ead51aa2c1444396bd9a32c.

Clients wanting to use this mechanism are directed to read the Authorization Code Flow: Client Authentication section and are requested to contact [email protected] to discuss further.

In response to an Authentication Request the OpenID provider will redirect the user back to the Relying Party application with either an Authorization Code or Error Response using the Redirection URI specified in the original request . To protect against the threat of Covert Redirection the Redirection URIs the Relying Party wishes to use should be specified during registration. For more detail on the use of Redirection URIs see the Authorisation Code Flow section.

Redirection URIs SHOULD use the https scheme in most cases. The exception being Native Applications that handle their own localhost callback.

The Care Identity Authentication provides a OpenID Provider Configuration Document for each of the four environments that may be used by a Relying Party as follows:

The contents of the OpenID Provider Configuration Document are described further in the Discovery section.

After successful registration the Relying Party will be issued a Client Identifier to use in calls to the Care Identity Authentication, it will take one of the following forms:

The 12 digit number will be randomly generated in order to prevent Client Identifier from being guessed.

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. Native applications
10. Session management
11. Role selection