How to Secure Microservice Access: Design Principles and Practical Solutions

Introduction

We start with access security design for traditional monolithic applications, then analyze the principles for modern microservice architectures, review common design schemes, and finally focus on how Spring Cloud solves access security.

1. Access Security Design for Traditional Monolithic Applications

The diagram shows the request flow in a monolithic app: the client sends HTTP/HTTPS requests, which pass through a load balancer to the monolith, then through an auth layer for authentication and authorization, often interacting with a backend database, before reaching the business logic layer and returning a response.

Principles of Monolithic Access Security

Each request must be verified for safety. Two cases exist:

Stateless requests require credential verification, identity retrieval, and session creation.

Requests with an existing session only need session validity verification.

User operations run in a single backend process, fully dependent on method reliability; failures cannot be retried automatically.

Advantages and Cautions

Summary: Monolithic apps have fewer exposed entry points, reducing attack surface, but they store all credentials in the backend, risk full data exposure if compromised, and cause high database load due to frequent DB interactions.

Backend stores all sensitive credentials.

Compromise of the app can expose all stored data.

Each operation typically requires database access, increasing load.

2. Access Security Design Principles for Microservice Architecture

The typical microservice diagram highlights three features:

Each service can only operate on its own responsibilities.

User authentication and authorization are handled by an independent gateway service.

The external load‑balancer cannot directly access the business service layer.

Key pain points in microservice access security include:

Single sign‑on across many independent services.

Stateless services cause every request to be authenticated, potentially creating an auth‑service bottleneck.

Fine‑grained permission management requires careful planning.

Non‑browser clients need proper operability.

3. Common Access Security Design Schemes for Microservices

HTTP Basic Authentication + Independent Auth DB

HTTP Basic Authentication + Central Auth DB

API Tokens

SAML

第一种，使用HTTP Basic Auth协议，加上独立的Auth数据库。

第二种，也是使用HTTP Basic Auth协议，跟第一种不同的是，使用集中式的Auth数据库

第三种，API Tokens协议，这种大家应该比较熟悉，很多公有服务（比如Github、Twitter等）的API都是用这种方式。

第四种，SAML，即Security Assertion Markup Language，翻译过来，是『安全声明标记语言』，它是基于XML的一种协议，企业内使用得较多。

1. Basic Auth + Independent Auth DB

Each service stores its own credentials in a dedicated database. Basic Auth adds an Authorization: Basic base64(username:password) header to each request, which all browsers support.

Each service has its own authentication/authorization mechanism.

Each service keeps its own database for sensitive data.

Every request must carry user credentials.

Benefits:

Microservices can be 100% stateless.

Implementation is simple with Basic Auth.

Considerations:

Design how each service stores and retrieves credentials.

Plan credential management for every request.

2. Basic Auth + Central Auth DB

All services share a single authentication database while still using Basic Auth.

Each service retains its own auth logic.

A shared DB stores credentials, simplifying management.

Requests still carry user credentials.

Benefits: Reduces the overhead of maintaining multiple credential stores.

Considerations:

The central DB may become a performance bottleneck.

Each service must implement logic to query the shared DB.

3. API Tokens

Token‑based authentication replaces user credentials with a token generated by an authorization server (e.g., OAuth2).

User sends username/password to obtain a token.

Authorization server issues a token.

Client includes the token in subsequent requests.

Server validates the token before granting access.

Benefits: Sensitive user credentials are never exposed to downstream services.

Considerations: The auth service must handle token issuance at scale.

4. SAML

SAML is an XML‑based protocol for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP).

Typical SAML SSO flow:

User requests a protected application.

Application creates a SAML authentication request and redirects the user to the IdP.

IdP authenticates the user and returns a signed SAML response.

Application validates the response and grants access.

Benefits: Provides a trusted, standards‑based access model.

Considerations: XML processing is complex and less friendly for non‑browser clients.

4. Spring Cloud Security Solution

Key features:

Configurable SSO based on OAuth2 and OpenID.

Token‑based resource protection.

UAA (User Account and Authentication) service managing accounts, OAuth2 clients, and JWT tokens.

UAA, originally from CloudFoundry, issues OAuth2 tokens for client applications. It defines authentication objects (users, clients, resource servers), authentication types (authorization code, password, client credentials), and scopes attached to access tokens.

A typical Spring Cloud microservice setup includes Eureka for service discovery, Config for centralized configuration, Auth (UAA) for authentication, Account for business data, and other services.

Auth component defines client authentication types and scopes (e.g., browser‑side password with scope "ui", account service client_credentials with scope "server"). Config routes /uaa/** to Auth and /accounts/** to the Account service.

When a user logs in, the browser sends a POST to /uaa/oauth/token with credentials and scope; the server returns an access_token, which is then used in the Authorization header for subsequent API calls.

Account service obtains tokens from Auth via clientID/clientSecret, accessTokenUrl, grant‑type client_credentials, and scope "server" for inter‑service communication.

Methods in the Account component use @PreAuthorize annotations to enforce scope‑based access control.

Final Summary of Spring Cloud Security:

Based on UAA and OAuth2, it never exposes user credentials.

Fine‑grained authorization via authentication types and scopes.

Good operability for non‑browser clients.