Browse and search developer information

Authentication and Authorisation Deployment Patterns


These patterns outline a few different technical approaches for deploying standard-based authentication and authorisation services to control access to health and care data and services.
The patterns are not intended to be specific implementation views – rather they show a range of ways these services could be deployed. There is no “right” or “wrong” patterns – each solves the basic problem in slightly different ways, and has associated benefits and limitations. The choice of pattern should be driven by the requirements for access control in a specific solution context. Real solutions may use a combination of these patterns, or variations/hybrids of multiple patterns.

These patterns assume:

  • Some level of authorisation is required (services which are “public” are not considered)
  • For all new API developments, authentication and authorisation interactions will use the OpenID Connect standard (IDPs may also use other approaches behind this).


  • Authentication: This is the process of using credentials to verify the user, and match them to identity information about the user, which can be used in subsequent authorisation for access.
  • Authorisation: The process of establishing what data and services an appropriately authenticated user is able to access. This is a mechanism for the data controller to apply appropriate policies to control access to the data they are responsible for.
  • Trust: To establish trust across multiple parties, there is a need for a common framework for that trust – for example using common standards for verifying identities during registration, etc. Often technologies such as digital certificates are used to establish secure links between services that have signed up to a common trust framework. Where there is a desire to federate services, the standards that underpin this trust relationship are essential – for example, consistent standards for the level of verification of user identities, the strength of the authentication mechanisms used, etc.

Pattern Matrix

The below table summarises the various patterns, and where each could potentially be applied – click on the links in each cell to view the details of specific patterns:

Deployment Options
Local* Authentication National Authentication
Local* Authorisation National Authorisation Local* Authorisation National Authorisation
Use Cases System Access Local System Access 1. All Local 5. National Identity, Local AuthZ 7. All National
National Portals 3. Federated Identity, National AuthZ 7. All National
System to System API Calls Direct Local Integration 1. All Local 3. Federated Identity, National AuthZ 5. National Identity, Local AuthZ
6. Federated Identity, Local AuthZ
7. All National
National Services (e.g. SCR, etc.) 3. Federated Identity, National AuthZ 7. All National
Nationally Brokered (SSP) 2. Local only, Simple Broker 4. Federated Identity, Broker AuthZ 5. National Identity, Local AuthZ
6. Federated Identity, Local AuthZ
8. National Identity, Broker AuthZ

* Note: “Local” here refers to either a local or shared regional solution (i.e. non-national)

Authentication and Authorisation Actors

The below actors appear in the patterns playing various roles in the authentication and authorisation process. In many real solutions, individual software components or services may play more than one of the above roles – for example, the Federation Server may also act as an Authentication Server:

End User (aka “Resource Owner”).
This is the user for whom we request identity information.
User Agent
This is the mobile app, web browser or client-side software used by the End User to access resources.
  Client Application (aka Relying Party)
This is the application (e.g. web app, EPR, etc.) accessed by the User Agent which makes requests for resources from one or more resource providers.
  Resource Provider
This is the service holding the data that the End User wishes to access
 Authentication Server
This is the service that verifies credentials with IDPs and provides identity tokens for registered users
Authorisation Server (aka Token Provider)
This is the service that applies any authorisation policy controls and permissions
  Identity Provider (IDP)
This is the service that maintains identity information for registered End Users
Federation Server
This is a service that federates identities provided by external/3rd party authentication servers to allow identities to be linked. It allows user attributes from various IDPs to map to a common model in ID tokens.