Pattern Overview
This pattern describes a central authentication model suitable for a microservices web application. It builds on several other designs to provide a scalable way to identify, authenticate and authorise access to resources, data and services.
This example uses a role-based authorisation model. A policy-based authorisation model would be more flexible but also more complex.
Illustration
Rousos (2023) Securing .NET Microservices and Web Applications, learn.microsoft.com.(Accessed: 16 May 2023).
This example is for a mobile app. A similar method would work for a static site, calling an API, a Single Page Application, or an MVC application. Use the Backends-For-Frontends pattern to offset any differences.
Benefits of this pattern
- By using the gateway, authentication is offloaded to the gateway and centralised, see Gateways.
- The gateway issues a signed token containing the authorised user's roles, which can be used for the token's lifespan, reducing chatter, see Microservices Anti-patterns.
- Once implemented, downstream services have their role added to the token and respect it.
- Identity management and storage can be offloaded to the customer's preferred vendor using open standards, Including:
- Microsoft, Google or Facebook identities, such as Microsoft AzureAD B2C
- Microsoft Azure AD identities, using B2B Federation
- Any OpenID Connect or OAuth2.0 Identities.
Drawbacks to this pattern
- It assumes simple role-based authorisation. A more complex policy-based model would require additional depth and complexity in the token, increasing its size and complexity.
- The token is easy to hack, so don't use it outside the network. A separate reference token model is recommended, where the token is used within the cluster and used by the gateway as a delegated authorisation.
- The user would have a lean token or reference cookie, which only correlates to the token on the gateway. Think of this model as a delegation rather than an authorisation.
- This pattern creates a dependency on external identity vendors, which can be hard to manage.
When to use this pattern
- In most enterprise or B2B microservice models, this pattern will be beneficial. It is ideal for a containerised application, which needs to minimise cross-talk and have a planned model for authorisation and identity.
When to avoid this pattern
- This pattern is not suitable for use on unsecured networks. A malicious actor can use the token's contents to understand the user and their roles.
- This pattern still promotes zero-trust, as every service will validate the token and must trust the issuer and check for tampering.
- You can work around this limitation by using a reference token issued to the external user at the gateway, which does NOT contain identifiable information.