How to Secure Microservices: From SSO to JWT and OAuth2 Explained

As applications evolve from monolithic to distributed and finally to microservice architectures, the security of service access faces continuous challenges. To adapt to architectural and requirement changes, authentication and authorization schemes must also evolve. When dozens or even hundreds of microservices call each other, efficient and secure identity verification becomes critical, as does fine‑grained authorization for external service access.

Monolith vs. Microservices

In a traditional monolithic application, the whole system is a single unit and typically performs permission checks for every request. An interceptor validates permissions, and user information is cached in a session after login, with subsequent requests retrieving the user data from that cache.

In a microservice architecture, an application is split into many small services, each requiring its own authentication and authorization. The traditional monolithic approach no longer fits, especially when calls originate not only from browsers but also from other services. Scenarios such as user‑to‑service and service‑to‑service authorization must be considered.

Four Authentication Solutions Proposed by David Borsos

Single Sign‑On (SSO) – Every user‑facing service must interact with an authentication service, generating a large amount of network traffic and redundant work, which becomes especially problematic with dozens of microservices.

Distributed Session – User authentication data is stored in shared storage (e.g., a distributed cache) and accessed via a session key. This approach offers high availability and scalability but requires secure links to the shared store, increasing implementation complexity.

Client Token (JWT) – Tokens are generated on the client, signed by an authentication service, and contain sufficient information to establish user identity across all microservices. JWTs are simple, well‑supported, and provide good security, though logout handling can be challenging.

Client Token + API Gateway – All requests pass through a gateway that converts the original user token into an internal session‑ID token, effectively hiding microservices. The gateway can revoke tokens during logout, simplifying token invalidation.

Common Security Authentication Schemes in Microservices

HTTP Basic Authentication

The client sends an HTTP request without an Authorization header; the server responds with 401 Unauthorized and a WWW-Authenticate header. The client then resends the request with a Base64‑encoded username and password in the Authorization header. The server validates the credentials and, if successful, returns the requested resource.

Session‑Based Authentication

After successful login, user data is stored in a session. In monolithic deployments the session resides on the application server and the session ID is stored in a browser cookie. In distributed environments, session replication or sticky sessions are used, but both have drawbacks such as increased network traffic or reliance on a load balancer. Therefore, sessions are often externalized to databases or distributed caches (e.g., Redis) for microservices.

Token‑Based Authentication

Tokens differ from session IDs in that they carry user information and can be validated without server‑side state. Public services like Twitter, GitHub, and internal APIs of OpenStack or Kubernetes use token authentication. A typical flow is:

1. The client sends login credentials (or calls a token endpoint). 2. The authentication service verifies the credentials and returns a token containing user info, permissions, and expiration. 3. The client stores the token (e.g., in a cache, database, or cookie) and includes it in the Authorization header of subsequent requests. 4. Each microservice validates the token and, if valid, processes the request.

JSON Web Token (JWT)

JWT is a compact, URL‑safe token format defined by RFC 7519. It consists of three Base64‑URL‑encoded parts: header.payload.signature. The header specifies the token type and signing algorithm (e.g., {"typ":"JWT","alg":"HS256"}); the payload carries claims such as iss, sub, aud, exp, nbf, iat, and jti; the signature is created by signing the header and payload with a secret key.

{
  "typ": "JWT",
  "alg": "HS256"
}

The payload can contain registered claims, public claims, and private claims. Example payload:

{
  "iss": "Online JWT Builder",
  "iat": 1416797419,
  "exp": 1448333419,
  "aud": "www.primeton.com",
  "sub": "[email protected]",
  "GivenName": "dragon",
  "Surname": "wang",
  "admin": true
}

Signature creation example:

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

Advantages of JWT

Cross‑language support due to JSON format.

Stateless on the server side.

Small size, easy to transmit.

Works well for mobile devices.

Enables cross‑program calls without cookie domain restrictions.

Token Revocation

Since tokens are not stored server‑side, revocation is non‑trivial. Common strategies include storing the token in a cookie and clearing it on logout, adding revoked tokens to a distributed cache for lookup, or using short‑lived tokens (e.g., 20‑minute validity) to limit exposure.

OAuth 2.0

OAuth 2.0 is an open protocol that allows secure API authorization for web, desktop, and mobile applications. It defines four roles: client, resource owner, resource server, and authorization server. The typical flow involves the client obtaining an authorization grant from the user, exchanging it for an access token at the authorization server, and then using the token to access protected resources.

OAuth Grant Types

Authorization Code – The most secure flow; the client exchanges an authorization code for an access token via a back‑channel server.

Implicit – Tokens are returned directly in the browser fragment; suitable for pure JavaScript clients.

Resource Owner Password Credentials – The user provides username and password directly to the client, which forwards them to the token endpoint.

Client Credentials – The client authenticates itself (not on behalf of a user) to obtain an access token.

These mechanisms enable fine‑grained, scalable security for modern microservice ecosystems.

Source: https://blog.csdn.net/u011676417/article/details/73481102