Skip to main content

Discovery

Learn how to get configuration information for the CIS2 Authentication environments.

Overview

You can get configuration information for our Path to Live (PtL) and production environments by accessing the configuration document at one of the well-known endpoints listed below:

Environment Usage Configuration document URI
Integration Development and integration testing View URI
Deployment Not our preferred environment, but still used by some suppliers for testing and end user training. View URI
Production The production environment View URI

This approach conforms to OpenID Connect Discovery 1.0.

You should do this at runtime - the information, including the URLs, might change over time.

You don't need to retrieve the configuration document every time you need it - you can cache it for a short period - up to an hour is reasonable.


Configuration document

The response is a JSON document containing a set of claims about our configuration for the given environment, including all necessary endpoints and public key location information.

For an example response, see the current response from our Integration environment.

Notable claims

The OpenID Provider Configuration Document contains the following notable items:

Claims Description
issuer Our Issuer Identifier - a case sensitive URL which will be returned in the ID Token we create for you.
 
scopes_supported A list of scopes we support. For further information see Scopes and claims.
acr_values_supported A list of Authentication Context Class References we support. An ACR value corresponds to a supported authentication mechanism. For further details see Authenticator guidance for developers.
authorization_endpoint   URL of our OAuth 2.0 authorisation endpoint to which you should submit authentication requests.
token_endpoint URL of our OAuth 2.0 token endpoint at which you can exchange an authorisation code an ID token and access token.
userinfo_endpoint URL of our Open ID Connect user info endpoint at which you can obtain claims about an end user using an access token.
jwks_uri URL of our JSON Web Key Set document. This contains the signing key(s) for you to use to validate signatures. See Key management for further details.

Firewall configuration

In all environments, our endpoints use dynamic IP addresses which can change on a regular basis. You should ensure any firewall rules or other security measures allow access via the domain name and the current set of IPs in use and do not rely on a static IP list.

We use a content delivery network (CDN) in front of our endpoints which can cause issues if incorrectly configured proxies are used between an application and our endpoints. Note that a proxy may legitimately be used to funnel requests over a private (HSCN) network or as a security boundary.

The CDN requires that the proxy supports both the HTTP host header and also SNI as part of the TLS handshake in order to correctly respond. Proxies solely relying on the IP address and not providing these values will see an error being returned.

An example NGINX configuration is as follows (please adjust to meet your requirements):

Example NGINX configuration

proxy_ssl_name "am.nhsidentity.spineservices.nhs.uk";
proxy_ssl_server_name on;
proxy_ssl_protocols TLSv1.2 TLSv1.3;
proxy_ssl_session_reuse off;

Last edited: 21 January 2026 10:08 am