9. Session management

The aim of this section is to present guidance on best practice for session management, both in general and with NHS CIS2 Authentication in particular. Much of this guidance is drawn from the Digital Identity Guidelines produced by the National Institute of Standards and Technology (NIST) part of the U.S. Department of Commerce.

In a federated identity scenario, the subscriber does not authenticate directly to the Relying Party. Instead, the federation protocol defines a mechanism for an Identity Provider (IdP) to generate an assertion for the identifier associated with a subscriber, usually in response to a request from the Relying Party. By this definition the NHS CIS2 Authentication OpenID Provider is acting as an IdP.

The NIST Digital Identity Guidelines for Federation and Assertions (PDF) provides technical and procedural guidelines for the implementation of federated identity systems. This includes guidance on federated session management, the significant parts of which are reproduced below:

In a federated environment, the RP manages its sessions separately from any sessions at the IdP. The session at the RP starts when the RP processes the federation protocol from the IdP. At the time of a federated login, the subscriber MAY have an existing session at the IdP which MAY be used as part of the authentication process to the RP. The IdP SHALL communicate any information it has regarding the time of the latest authentication event at the IdP, and the RP MAY use this information in determining its access policies. Depending on the capabilities of the federation protocol in use, the IdP SHOULD allow the RP to request that the subscriber reauthenticate at the IdP as part of a federation request.

Due to the distributed nature of a federated system, the subscriber is capable of terminating sessions with the IdP and RP independently of one another. The RP SHALL NOT assume that the subscriber has an active session at the IdP past the establishment of the federated log in. The IdP SHALL NOT assume that termination of the subscriber’s session at the IdP will propagate to any sessions that subscriber would have at downstream RPs.

Assertions

In the context of OpenID Connect references to assertion in the following discussion should be taken to mean the ID Token.

All assertions SHALL include the following assertion metadata:

• Subject: An identifier for the party that the assertion is about (i.e., the subscriber).
• Issuer: An identifier for the IdP that issued the assertion.
• Audience: An identifier for the party intended to consume the assertion (i.e., the RP).
• Issuance: A timestamp indicating when the IdP issued the assertion.
• Expiration: A timestamp indicating when the assertion expires and SHALL no longer be accepted as valid by the RP (i.e., the expiration of the assertion and not the expiration of the session at the RP).

Although details vary based on the exact federation protocol in use, an assertion SHOULD be used only to represent a single login event at the RP. After the RP consumes the assertion, session management by the RP comes into play; an assertion SHALL NOT be used past the expiration time contained therein. However, the expiration of the session at the RP MAY occur prior to the assertion’s expiration. 

The assertion’s lifetime is the time between its issuance and its expiration. This lifetime needs to be long enough to allow the RP to process the assertion and create a local application session for the subscriber, but should not be longer than necessary for such establishment. Long-lived assertions have a greater risk of being stolen or replayed; a short assertion lifetime mitigates this risk. Assertion lifetimes SHALL NOT be used to limit the session at the RP. 

The NIST Digital Identity Guidelines Authentication and Lifecycle Management (PDF) provides technical and procedural guidelines focusing on the authentication of subjects but also includes guidance on session management, the significant parts of which are reproduced below.

From the above discussion it should be clear that these requirements apply to sessions being managed by the RP.

In the following sections CSP is used as an abbreviation for Credential Service Provider which is a role taken by NHS CIS2 Authentication. 

Once an authentication event has taken place, it is often desirable to allow the subscriber to continue using the application across multiple subsequent interactions without requiring them to repeat the authentication event. This requirement is particularly true for federation scenarios where the authentication event necessarily involves several components and parties coordinating across a network.

To facilitate this behaviour, a session MAY be started in response to an authentication event, and continued until such time that it is terminated. The session MAY be terminated for any number of reasons, including but not limited to an inactivity timeout, an explicit logout event, or
other means. The session MAY be continued through a re-authentication event wherein the user repeats some or all of the initial authentication event, thereby re-establishing the session.

Session management is preferable over continual presentation of credentials as the poor usability of continual presentation often creates incentives for workarounds such as cached unlocking credentials, negating the freshness of the authentication event.

A session occurs between the software that a subscriber is running — such as a browser,  application, or operating system (i.e., the session subject) — and the RP or CSP that the subscriber is accessing (i.e., the session host). A session secret SHALL be shared between the subscriber’s software and the service being accessed. This secret binds the two ends of the session, allowing the subscriber to continue using the service over time. The secret SHALL be presented directly by the subscriber’s software or possession of the secret SHALL be proven using a cryptographic mechanism.

The secret used for session binding SHALL be generated by the session host in direct response to an authentication event. A session SHOULD inherit the AAL (Authenticator Assurance Level) properties of the authentication event which triggered its creation. A session MAY be considered at a lower AAL than the authentication event but SHALL NOT be considered at a higher AAL than the authentication event.

Secrets used for session binding:

• SHALL be generated by the session host during an interaction, typically immediately following authentication.
• SHALL be generated by an approved random bit generator and contain at least 64 bits of entropy.
• SHALL be erased or invalidated by the session subject when the subscriber logs out.
• SHOULD be erased on the subscriber endpoint when the user logs out or when the secret is deemed to have expired.
• SHOULD NOT be placed in insecure locations such as HTML5 Local Storage due to the potential exposure of local storage to cross-site scripting (XSS) attacks.
• SHALL be sent to and received from the device using an authenticated protected channel.
• SHALL time out and not be accepted after the times appropriate for the AAL.
• SHALL NOT be available to insecure communications between the host and subscriber’s endpoint. Authenticated sessions SHALL NOT fall back to an insecure transport, such as from https to http, following authentication.

URLs or POST content SHALL contain a session identifier that SHALL be verified by the RP to ensure that actions taken outside the session do not affect the protected session.

There are several mechanisms for managing a session over time. The following sections give different examples along with additional requirements and considerations particular to each example technology. Additional informative guidance is available in the OWASP Session Management Cheat Sheet.

Browser cookies are the predominant mechanism by which a session will be created and tracked for a subscriber accessing a service. Cookies:

• SHALL be tagged to be accessible only on secure (HTTPS) sessions.
• SHALL be accessible to the minimum practical set of hostnames and paths.
• SHOULD be tagged to be inaccessible via JavaScript (HttpOnly).
• SHOULD be tagged to expire at, or soon after, the session’s validity period. This requirement is intended to limit the accumulation of cookies, but SHALL NOT be depended upon to enforce session timeouts.

An access token — such as found in OAuth — is used to allow an application to access a set of services on a subscriber’s behalf following an authentication event. The presence of an OAuth access token SHALL NOT be interpreted by the RP as presence of the subscriber, in the absence of other signals. The OAuth access token, and any associated refresh tokens MAY be valid long after the authentication session has ended and the subscriber has left the application.

Other methods of secure device identification — including but not limited to mutual TLS, token binding, or other mechanisms — MAY be used to enact a session between a subscriber and a service.

Continuity of authenticated sessions SHALL be based upon the possession of a session secret issued by the verifier at the time of authentication and optionally refreshed during the session. The nature of a session depends on the application, including:

• A web browser session with a “session” cookie, or
• An instance of a mobile application that retains a session secret.

Session secrets SHALL be non-persistent. That is, they SHALL NOT be retained across a restart of the associated application or a reboot of the host device.

Periodic reauthentication of sessions SHALL be performed to confirm the continued presence of the subscriber at an authenticated session (i.e., that the subscriber has not walked away without logging out) in line with the table below:

Note that for access to national clinical systems an AAL3 authentication is required.

Reauthentication from a Federation or Assertion

When using a federation protocol to connect the CSP and RP (as is the case with OpenID Connect), special considerations apply to session management and reauthentication. The federation protocol communicates an authentication event between the CSP and the RP but establishes no session between them. Since the CSP and RP often employ separate session management technologies, there SHALL NOT be any assumption of correlation between these sessions. Consequently, when an RP session expires and the RP requires reauthentication, it is entirely possible that the session at the CSP has not expired and that a new assertion could be generated from this session at the CSP without reauthenticating the user.

An RP requiring reauthentication through a federation protocol SHALL specify the maximum acceptable authentication age to the CSP, and the CSP SHALL reauthenticate the subscriber if they have not been authenticated within that time period. The CSP SHALL communicate the authentication event time to the RP to allow the RP to decide if the assertion is sufficient for reauthentication and to determine the time for the next reauthentication event.

Further information on how this can be achieved with the NHS CIS2 Authentication OpenID Provider by the use of prompt and max_age parameters in the Authentication Request can be found in the Authorization Code Flow section.

This section describes the session types to be taken into account by Relying Parties when designing an application.

An End-User establishes a session on a device when they log in to an account on the device e.g. using Azure Active Directory credentials on a Windows Laptop. Typically devices provide mechanisms to pause a session such as a lock screen and to terminate the session by logging out of the device.

Device sessions are out of scope for NHS CIS2 Authentication, and no capabilities are provided to manage such sessions.

It is RECOMMENDED that Relying Parties ensure that their applications are only used by organisations where:

1. Each user of a shared device has their own account on the device.
2. Devices use a mechanism to lock a user's session after a period of inactivity e.g. a Windows Lock Screen.
3. Devices are not configured to persist session cookies when a user logs out of their device session such as by the use of the 'Continue where you left off' feature in the Chrome browser. 

The NHS CIS2 Authentication OpenID Provider session is established when a End-User wants to authenticate. These sessions are created in the NHS CIS2 Authentication server and maintained on client devices by use of a Secure HttpOnly session cookie. The NHS CIS2 Authentication OpenID Provider allows up to 10 concurrent sessions before previous sessions are terminated on an oldest first basis. 

The use of the cookie provides a SSO capability in that all browser windows and tabs will share the same session state. It should be noted that this session is not shared by other browsers that the End-User may be using i.e. a session established in Chrome is not shared with Firefox. This session state is lost when the browser is fully closed. Re-authentication in the same browser can re-use the previous session state and does not count towards the session quota

The server side session will be terminated under the following circumstances:

1. The session expires. The NHS CIS2 Authentication session length is set to 12 hours, no idle timeout is applied to this session.
2. The session was established using a smartcard and the smartcard session expires.
3. The session was established using a smartcard and the smartcard is removed.
4. The End-User creates an 11th new session in a different browser or on a different device, or in a previously closed browser.

The session will also effectively be ended on the client device if all instances of the browser are closed. This may occur as a result of the End-User choosing to close the browser or as a result of the End-User terminating their device session. 

NHS CIS2 Authentication sessions SHOULD NOT be used on devices that are configured to persist session cookies when a user logs out of their device session such as by the use of the 'Continue where you left off' feature in the Chrome browser.  

NHS CIS2 Authentication now allows up to 10 authentication sessions to be created in different user-agents. This is to allow different applications in different user-agents. A Relying Party that has a security requirement to only allow a single user session at a time MUST implement this requirement in their own business logic. 

When an End-User authenticates with a smartcard using an Identity Agent (IA) a session is created within the IA that persists until the session expires after 12 hours or the smartcard is removed. The NHS IA can be configured to manage its own session, the client device session and browser sessions in a number of different ways, including:

1. Closing all browser windows when the smartcard is removed.
2. Offering the End-User the option to end the IA session or lock the client device when the smartcard is removed.
3. Offering the End-User to remove the smartcard but to continue the IA session by periodically re-entering the smartcard pin.

Further details can be found in the IA User Guides which can be downloaded from http://nww.hscic.gov.uk/dir/downloads/.

As highlighted in the Federated Session Management Guidance above, it is the Relying Party's responsibility to manage their session separately from any session created by NHS CIS2 Authentication. It is also their responsibility to ensure that the session is managed in line with the security requirements of their application.

In brief the NIST guidance above requires that for an AAL3 authentication the following requirements MUST be met:

1. A secure session binding such as a Secure HttpOnly cookie MUST be used.
2. Authentication of the subscriber MUST be repeated at least once per 12 hours during an extended usage session, regardless of user activity.
3. Reauthentication of the subscriber SHALL be repeated following any period of inactivity lasting 15 minutes or longer.

The purpose of this section is to describe how Relying Parties may use the features of OpenID Connect as provided by NHS CIS2 Authentication to manage their sessions in line with the NIST guidance outlined above.

The OpenID Connect 1.0 specification comprises a Core specification and a number of other specifications at various states of development as listed at https://openid.net/connect/. This section concentrates on the capabilities of the Core specification as currently supported by NHS CIS2 Authentication. There are a number of specifications offering additional session management features which NHS CIS2 Authentication may support in the future, these are discussed in the Future Session Management Features section below.

Session management within the Core specification is achieved by the use of the prompt and max_age parameters in the Authentication Request and the auth_time Claim in the ID Token. By using these a Relying Party can if wanted take advantage of SSO, check the current session state at the End-User's browser and force a new authentication to take place.

Note that use of an Authentication Request requires a round trip from the Relying Party web application through the End-User's browser to the NHS CIS2 Authentication OpenID Provider and back again. Relying Parties wanting to take advantage of the capabilities below should design their web application accordingly and in particular those adopting a Single Page Application paradigm need to consider how they will manage reauthentication events. 

This is a case sensitive string that controls how the Authentication Request interacts with the End-User. The NHS CIS2 Authentication OpenID Provider supports three values of this parameter: not present, none and login. 

not present

If the prompt parameter is not present in the Authentication Request then the NHS CIS2 Authentication OpenID Provider will first check whether the End-User has an active NHS CIS2 Authentication session. This is done by checking for the presence of a NHS CIS2 Authentication cookie in the End-User's browser and if one exists validating that it corresponds to an active session at the NHS CIS2 Authentication server.

If the End-User has an active session then the Authorization Code Flow will proceed as normal and the resulting ID Token will contain an auth_time Claim containing the time that the user was last authenticated.

If the End-User does not have an active session then a new authentication will occur in line with the other parameters supplied. If the authentication is successful then the Authorization Code Flow will proceed as normal and the resulting ID Token will contain an auth_time Claim containing the authentication time.

The behaviour of the Authentication Request when no prompt parameter is provided can be further modified by the use of the max_age parameter as described further below.

none

If a prompt parameter is provided with a value of none then the above behaviour is modified so that if no active session exists an Authentication Error Response is returned to the Relying Party's redirection URI. The error returned will have an error code value of interaction_required as in the example response below:

login

If a prompt parameter is provided with a value of login then the End-User will be re-authenticated. (this is equivalent to max_age=0)

When using the iOS CIS2 Application or Windows Hello this will cause a full authentication to occur. When using a smartcard with the Identity Agent the behaviour will depend on the IA session state:

• if a session still exists in the IA then no End-User action will be required
• if a session doesn't exist, the End-User will be prompted to insert their smartcard and enter their pin.

When using a prompt=login parameter the auth_time returned in the ID Token SHOULD be checked as described in the Authentication Time Claim section below.

The max_age parameter can be used to modify the behaviour of an Authentication Request when no prompt parameter is provided. It specifies the maximum allowed time in seconds since the last time the End-User was actively authenticated by the NHS CIS2 Authentication OpenID Provider. If the elapsed time is greater than this value NHS CIS2 Authentication will attempt to actively re-authenticate the End-User. If the authentication is successful then the Authorization Code Flow will proceed as normal and the resulting ID Token will contain an auth_time Claim containing the new authentication time.

When using a max_age parameter the auth_time returned in the ID Token SHOULD be checked as described in the Authentication Time Claim section below.

Relying parties may generally choose to allow a limited max_age of up to 5 minutes to reduce the authentication burden on users. For values greater than this, the confidence that the authenticating user is present decreases rapidly and should only be used in carefully considered situations. It should be avoided in scenarios where the OS session is shared between users.  

The NHS CIS2 Authentication OpenID Provider always returns an auth_time Claim in the ID Token. The auth_time Claim gives the time at which the End-User was last authenticated. Its value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time.

A Relying Party may make use of this Claim to make decisions about the freshness of the current NHS CIS2 Authentication session.

When an authorization request is made with a prompt=login or a max_age parameter the auth_time Claim MUST be checked to confirm that that the request has been honoured and has not been subject to manipulation by an attacker. This can be achieved by checking the auth_time against the current time. Allowance should be made for the time taken between receiving the auth code and obtaining the ID Token and for potential clock skew e.g. the auth_time should be validated that it is within 15 seconds of the current time when prompt=login or max_age=0 is used.

When considering OpenID Connect session management with NHS CIS2 Authentication it is important to understand the differences in behaviour when a user is authenticated using a smartcard versus other authentication mechanisms.

An authentication with the iOS CIS2 Application or with Windows Hello is a one time event which definitively proves the presence of the user at the time of the authentication. However after the initial authentication the continued existence of a NHS CIS2 Authentication session cannot be used to directly infer the presence of the user. The impact of this on the use of the prompt parameter is described in the table below:

An authentication with a smartcard via an Identity Agent is not the same as the iOS CIS2 Application or with Windows Hello. Once the initial authentication has occurred the session is maintained by the continual presence of the smartcard in the smartcard reader so different inferences can be made about the user presence as described below:

The mechanism used to authenticate a user is given by the value of the amr claim in the ID Token as described in the ACR and AMR Values section.

The OpenID Connect Back-Channel Logout Specification describes a logout mechanism whereby a logout notification is sent directly from the OpenID Provider to the Relying Party server component.

Relying Parties supporting this specification register a Back-Channel Logout URI with the OpenID Provider as part of the client registration. The OpenID Provider will then keep track of all End-User sessions for such Relying Parties. When the End-User initiates a logout (either directly with the OpenID Provider or indirectly via the Relying Party) or the OpenID Provider session expires the OpenID Provider will POST a Logout Token to each affected Relying Party over the public internet. The Logout Token is similar to an ID Token in that it contains the End-User’s subject identifier and is a JWT signed with the OpenID Provider's private key. On receipt of the Logout Token the Relying Party destroys the End-Users local session.

Registration

To register for Back-Channel Logout notifications, the Client MUST provide a single public internet facing endpoint where NHS CIS2 Authentication can POST a Logout Token. This configuration is part of the OIDC client registration. The endpoint MUST be secured with HTTPS (using port 443), accessible by a Public DNS Domain and present a server certificate matching its FQDN. The certificate presented MUST include a full certificate chain to a trusted public Root CA e.g. DigiCert.

Notifications will be sent from these address ranges. You should configure your firewall to allow requests to the endpoint from these addresses

Notification

A Logout Token will be sent to a RP when the OpenID Provider session is terminated for one of the following reasons:

1. The session expires. The NHS CIS2 Authentication session length is set to 12 hours, no idle timeout is applied to this session.
2. The session was established using a smartcard and the smartcard session expires.
3. The session was established using a smartcard and the smartcard is removed.
4. The End-User creates an 11th new session in a different browser or on a different device, or in a previously closed browser (see NHS CIS2 Authentication sessions above)

In the future their may be additional scenarios which will cause a session to be terminated e.g. when a Registration Authority revokes an End User's credentials.

Response

As per the specification, these HTTP responses should be used: 

• If the logout succeeded, the RP MUST respond with HTTP 200 OK.
• If the logout request was invalid or the logout failed, the RP MUST respond with HTTP 400 Bad Request.
• The response MAY include an HTTP body consisting of a JSON object with error and error_description parameters conveying the nature of the error that occurred.

For the avoidance of confusion, "HTTP 400 Bad Request" should only be sent if the token was invalid or the logout actually failed. If the specified session does not exist, or the user has no sessions (for those logout tokens without a sid) then the logout request can be considered to be "HTTP 200 OK" as the result is that the session(s) no longer exists.

Logout Token

The Logout Token is a JWT (see JSON Web Token Specification) very similar to the ID Token, it is signed by the same keypair and is therefore subject to the same key rotation requirements.

The Logout Token is sent in a logout_token parameter included in a POST body using the application/x-www-form-urlencoded encoding.

The POST body MAY contain other values in addition to logout_token. Values that are not understood by the Relying Party MUST be ignored.

An example POST request and decoded payload are given below, most of the logout_token contents are omitted for brevity.

Relying Parties MUST validate the Logout Token in the Token Response as per section 2.6 of the OIDC Back-Channel Logout Specification. Note that:

1. The value of the iss Claim MUST exactly match the Issuer Identifier for the NHS CIS2 Authentication OpenID Provider as specified in the OpenID Provider Configuration Document.
2. The aud Claim MUST contain the Relying Party's Client identifier.
3. The Client MUST validate the signature of the logout token according to the JSON Web Signature Specification using the algorithm specified in the JWT alg header parameter. The Client MUST use the keys provided by the NHS CIS2 Authentication OpenID Provider as described in the Key Management section.
4. The Logout Token MUST contain an events Claim whose value is JSON object containing the member name http://schemas.openid.net/event/backchannel-logout.
5. The Logout Token MUST not contain a nonce Claim.
6. Clients MUST validate the iat and exp claims in the same way they are validated in ID Tokens.

Actions

Client applications wishing to implement Back Channel Logout should store the sub and sid claims from the ID Token (see Authorization Code Flow) in their own sessions upon successful login. Upon receipt of a logout token, the Client MUST check the veracity of the token as described above.

If the Logout Token contains both a sub and sid claim, then the Client SHOULD find any application sessions where both the captured sub and sid values match those in the Logout Token and invalidate these sessions. 

If there is no sid claim present in the Logout Token, then the Client SHOULD invalidate all sessions for the user identified by the sub claim.

Client applications MAY choose to implement a client side polling mechanism such that when a session is invalidated on the server the user is also logged out client side. This may give a better user experience than allowing the user to attempt further actions only to be denied as the result of a server side session check.

This section given some examples on how the features described above could be used. These examples are provided for illustrative purposes, the manner of use of these features by a Relying Party should be determined by consideration of their particular security and usability requirements.

NIST AAL3 Use Case

To fully comply with letter of the NIST requirements for AAL3 session management a Relying Party should implement the following.

1. When the Relying Party detects a new End-user accessing their web application they should make an Authentication Request with a prompt=login parameter. On successful authentication the Relying Party should retrieve the ID Token to identify the End-User, create an application session and create an activity timer for the session. 
2. If the End-User has been inactive for 15 minutes or more between visits to the web application the Relying Party should make an Authentication request with a prompt=login parameter. On successful authentication the Relying Party should retrieve the ID Token and validate that the identity is the same as that used to create the application session. 
3. If the End-User has been active for 12 hours without re-authenticating as a result of step 2 the Relying Party should make an Authentication request with a prompt=login parameter. On successful authentication the Relying Party should retrieve the ID Token and validate that the identity is the same as that used to create the application session. 
4. The web application should provide an option in the web application to indicate that wish to log out of the application at which point the application session should be destroyed.

Note that for iOS CIS2 Identity Application and Windows Hello authentications use of the prompt=login parameter will result in the End-User being prompted to provide credentials definitively proving their presence. Whereas for smartcard authentications using the NHS IA a user interaction will only occur if the IA no longer holds an active session, thus End-User presence is only guaranteed in so much as their smartcard has not been removed from the smartcard reader.

Relying Parties implementing applications requiring NIST AAL3 session management may also have a requirement to only allow a single user session at a time. Such Relying Parties are RECOMMENDED to implement this requirement in their own business logic. This recommendation is made as the current single session restriction implemented in NHS CIS2 Authentication may be relaxed in the future to allow an End-User to have sessions on multiple devices at the same time e.g. on their desktop and on a iPad.

NIST AAL3 Use Case with Sensitive  Operations

Relying Parties performing particularly sensitive operations may wish to add an additional confirmatory step before performing such operations. Relying Parties wishing to implement this use case should ensure they understand the limitations as described and are requested to contact [email protected] to check whether the likely volumes of use can be supported.

Two options are possible as described further below.

Option 1 - prompt=none

Before performing the sensitive action the Relying Party could make an Authentication request with a prompt=none parameter. If an active NHS CIS2 Authentication session exists in the End-User's browser then an Authorization Code will be returned as normal and the Relying Party should retrieve the ID Token and validate that the identity is the same as that used to create the application session.

Note that for smartcard authentications using an Identity Agent this will prove that the End-User has not removed their smartcard from the smartcard reader and it can be inferred that the user is present. Whereas for iOS CIS2 Application and Windows Hello authentications this only gives assurance that the End-User has previously been authenticated (at the time given by the auth_time claim in the ID Token) and the session has not expired, presence of the End-User cannot be inferred.

Note that the mechanism by which the End-User was authenticated can be determined from the amr claim in the ID Token as described in the ACR and AMR Values section.

Option 2 - prompt=login

Before performing the sensitive action the Relying Party could make an Authentication request with a prompt=login parameter. On successful authentication the Relying Party should retrieve the ID Token and validate that the identity is the same as that used to create the application session.

Note that for iOS CIS2 Application and Windows Hello authentications this will result in the End-User being prompted to provide credentials and thus presence of the End-User is guaranteed. Whereas for smartcard authentications using the NHS IA a user interaction will only occur if the IA no longer holds an active session, thus End-User presence can be inferred in so much as their smartcard has not been removed from the smartcard reader.

When considering this option thought should be given as to the frequency of use. Too frequent use may give an unacceptable user experience for users of the iOS CIS2 Application and Windows Hello authentication mechanisms.

SSO Use Case

Relying Parties who do not need to meet the stringent standards required for NIST AAL3 session management or whose application is likely to be deployed alongside other applications utilising the NHS CIS2 Authentication OpenID Provider may choose to take advantage of the NHS CIS2 Authentication session to obtain the benefits of SSO.

Two options are possible as described further below.

Option 1 - no prompt parameter

With this option the initial Authentication Request is made without providing a prompt parameter. If the End-User has an active session as the result of an authentication by another application then the Authorization Code Flow will proceed as normal and the resulting ID Token will contain an auth_time Claim containing the time that the user was last authenticated. If the End-User does not have an active session then a new authentication will occur. In either case the resulting ID Token will contain an auth_time Claim containing the authentication time. The Relying Party can use this information to determine whether they wish to create their own application session or to request a new authentication using the prompt=login parameter.

Note that the existence of a previous authentication does not guarantee the current presence of the user. The level of risk to accept is a matter for the Relying Party but it should be noted that for NIST AAL3 session management a period of inactivity of 15 minutes is seen as grounds for re-authentication.

Option 2 - no prompt parameter with max_age

The option above can be modified by the use of a max_age parameter. In this case re-authentication will occur even if a NHS CIS2 Authentication session exists, if the previous authentication occurred longer ago than the time specified in the max_age parameter. The max_age time time should be expressed in seconds e.g. max_age=900 will result in re-authentication if 15 minutes has elapsed since the previous one.

The same caveat applies to this option as for option 1.

This section presents additional session management features that NHS CIS2 Authentication may offer in the future. It briefly discusses OpenID Connect specifications relating to session management and then gives a view of the roadmap to deliver these and other features.

The OpenID Connect Core Specification details how a Relying Party can request an OpenID Provider to authenticate an End-User and provide information about them, but it does not contain any information on how the authenticated session should then be managed e.g. how a End-User can logout and how this is communicated to the Relying Party.

There are however three standards that attempt to address this issue as briefly described below. To date NHS CIS2 Authentication has implemented the Back-Channel Logout specification. In the future an implementation of the other specifications may be considered for implementation.

Session Management

The OpenID Connect Session Management Specification describes a mechanism whereby a Relying Party can determine the state of an authenticated End-User’s session.

This is achieved by the Relying Party instantiating two invisible iframes in the End-User’s user agent, one for the Relying Party and one for the OpenID Provider. The OpenID Provider iframe is responsible for monitoring the user state at the OpenID Provider (the means of achieving this is not specified but could it be for example by use of a state cookie). The Relying Party iframe can then periodically query the OpenID Provider iframe using the JavaScript postMessage function to determine whether the End-User’s authentication state has changed and if so what the new state is.

Front-Channel Logout

The OpenID Connect Front-Channel Logout Specification describes a mechanism whereby front-channel communication via an End-User’s user agent is used to trigger a logout of the user at the Relying Party.

Relying Parties supporting this specification register a logout URI with the OpenID Provider as part of the client registration. The OpenID Provider will then keep track of all End-User sessions for such Relying Parties. When the End-User initiates a logout (either directly with the OpenID Provider or indirectly via by the Relying Party) the OpenID Provider will cause a page to be loaded in the End-User’s user agent that renders the affected logout URIs thus triggering a logout at each of the Relying Parties.

RP-Initiated Logout

The OpenID Connect RP-Initiated Logout Specification describes a mechanism whereby a Relying Party can request that an OpenID Provider logs out the End-User.

An Relying Party may request that the OpenID Provider logs out the End-User by redirecting the End-User's User Agent to the OP's Logout Endpoint. The OpenID Provider will present the user a screen asking them if they want to logout of the OpenID Provider's session as well as the Relying Party application session. The Relying Party may optionally provide a URI to which the User Agent will be directed after the logout.

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