Microservices Security Design Patterns

  • In-memory security context — In-memory security contexts such as ThreadLocal are used to pass around user identities. Services cannot share a memory, so they can’t use an in-memory security context to pass user identities around. We need a different mechanism for passing user identities from one microservice to another in a microservice architecture.
  • Centralized Session — An in-memory security context makes no sense, and neither does an in-memory session. In theory, multiple services could access a database-based session. However, this would violate the loose coupling principle. A microservice architecture requires a different session mechanism.

Authentication in a microservices architecture

  • In pure API clients, credentials are supplied with each request using, for example, basic authentication.
  • Other clients might log in first and then supply a session token with each request.

Access Token Pattern

Authentication flow for API clients:

  1. An API client sends a request containing credentials.
  2. API gateways authenticate credentials, create a security token, and pass that to the service.

Authentication flow for login-based clients:

  1. A client submits a login request containing credentials.
  2. A security token is returned by the API gateway.
  3. The client forwards the security token to the service.

Authorization in a microservices architecture

  1. API Gateway — If a user is not allowed to access a particular path, the API gateway may reject the request before forwarding it to the service. Authorizing in one place also minimizes security risks. API gateway authorization can be implemented using a security framework such as Spring Security. API gateways can usually implement role-based URL access, but not ACLs that control access to individual domain objects.
  2. Services — It is possible for a service to implement role-based authorization for URLs and for methods. The service can also implement ACLs to manage aggregate access.

In a microservice architecture, you need to decide what type of token an API gateway should use to pass user information to the services.

  1. Opaque tokens — Tokens that are opaque are typically UUIDs. A disadvantage of opaque tokens is that they reduce performance and availability and increase latency. The recipient of such a token must make a synchronous RPC call to a security service to validate the token and retrieve user information.
  2. Transparent tokens — Transparent tokens eliminate the need for RPC calls to security services that contain user information. JSON Web Token (JWT) is one such popular transparent token.

JWTs to pass identity and roles

Drawbacks of JWT

  • A token cannot be revoked and can become invalid only after its expiration date.

Security Standard OAuth 2.0

Access delegation problem

  • Access delegation via credential sharing
  • Access delegation with no credential sharing.

OAuth 2.0 is based on the following concepts:

  • Authorization server —Provides an API for authenticating users and getting an access token and a refresh token. Spring OAuth is an example of a framework used for building an OAuth 2.0 authorization server.
  • Access token — Tokens that grant access to a resource server. As with JWTs, the format of the access token is implementation-dependent.
  • Refresh token — Clients obtain a new access token by using a long-lived, yet revocable, token.
  • Resource server — An access token is used to authorize access to a service. The services in a microservice architecture are resource servers.
  • Client — A client that requests access to a resource server. The API gateway is the OAuth 2.0 client in a microservice architecture.

API gateway authentication flow for an API client

  1. A client submits a request supplying its credentials using basic authentication.
  2. API gateway sends an OAuth 2.0 password grant request to the OAuth 2.0 authorization server.
  3. The authorization server validates API client credentials and returns an access token and refresh token.
  4. In the requests it makes to the services, the API gateway includes the access token. The service validates the access token and uses it to authorize the request.

API gateway authentication flow for session-oriented client

  1. Login-based clients POST their credentials to the API gateway.
  2. API gateways make OAuth 2.0 password grant requests to OAuth 2.0 authorization servers.
  3. The authorization server validates the credentials of the client and returns an access token and a refresh token.
  4. API gateways, for example, return access and refresh tokens to the client through cookies.
  5. In its requests to the API gateway, the client includes the access token and the refresh token.
  6. API gateways include the access token in their requests to the services after validating them.
(A)  The client requests an access token by authenticating with the authorization server and presenting an authorization grant.(B)  The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token and a refresh token.(C)  The client makes a protected resource request to the resource server by presenting the access token.(D)  The resource server validates the access token, and if valid, serves the request.(E)  Steps (C) and (D) repeat until the access token expires.  If the client knows the access token expired, it skips to step (G); otherwise, it makes another protected resource request.(F)  Since the access token is invalid, the resource server returns an invalid token error.(G)  The client requests a new access token by authenticating with the authorization server and presenting the refresh token. The client authentication requirements are based on the client type and on the authorization server policies.(H)  The authorization server authenticates the client and validates the refresh token, and if valid, issues a new access token (and, optionally, a new refresh token).

Benefits of OAuth 2.0

  • The OAuth 2.0 standard is a proven security standard.
  • If you use an off-the-shelf OAuth 2.0 authentication server, you don’t have to implement it.

Securing communications among microservices

References

--

--

--

“Walking on water and developing software from a specification are easy if both are frozen”

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

🛡 DeFi. Protect your ass and crypto.

Object oriented programming in Java

Getting started with TablePlus

Ephemeral databases with Spawn

AWS PowerTools Layer — How to setup in SAM

Import HK Road Direction Signs SVG in Unity

Terraform; GCP Service Account with Role and json keys.

Installing Apache Cassandra for JanusGraph

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Neeraj Kushwaha

Neeraj Kushwaha

“Walking on water and developing software from a specification are easy if both are frozen”

More from Medium

Microservices Communication Design Patterns

Securing Microservices with OAuth2

Domain-driven design practice — Modeling payments system

Microservices