Adventuretube Microservice Security Architecture

🧭 Overview

This document explains the security architecture of the Adventuretube platform, detailing how requests are authenticated and authorized across the API Gateway and individual microservices.

A key design principle in this system is the separation of authentication responsibilities:

• The API Gateway acts as a global interceptor, validating whether requests are secure and forwarding them to the correct microservice if valid.

• A dedicated auth-service handles actual authentication, credential validation, and JWT token issuance.

Unlike traditional architectures that embed Spring Security directly into the gateway, Adventuretube avoids this due to a core architectural mismatch:

• Spring Cloud Gateway is built on Reactive WebFlux (asynchronous, non-blocking).

• Spring Security is traditionally built on Servlet-based architecture (blocking, synchronous).

To address this, authentication logic is centralized in a dedicated servlet-based auth-service, while the gateway only performs stateless JWT validation.

🔄 Gateway Authentication Flow (Stateless)

In the AuthenticationFilter (used in GatewayConfig):

1. Check if the incoming request targets a secured endpoint via RouterValidator.isSecured.

2. If secured, extract the JWT token from the Authorization header.

3. Validate the token (signature, claims, expiration).

4. If valid, forward the request to the respective microservice with the original path (minus the /xxx-service prefix).

👉 Note: The gateway does not perform user authentication—it only validates token authenticity and structure.

if (validator.isSecured.test(request)) {
  // Check Authorization header
  // Extract and validate token
  // If valid, continue filter chain
}

🧠 Centralized Authentication via auth-service

The auth-service is the only module that:

• Authenticates users using their credentials.

• Issues JWT tokens on successful login.

• Provides endpoints like /auth/register, /auth/login, /auth/refreshToken.

Once a user logs in, the client stores the JWT and sends it in subsequent requests.

.addFilterBefore(jwtAuthFilter, UsernamePasswordAuthenticationFilter.class)

The auth-service validates incoming requests by parsing the JWT, verifying its signature and expiration, and setting the SecurityContextHolder.

🔐 Role-Based Access at Downstream Services

Once a request passes through the gateway and reaches a microservice (e.g., member-service, geo-service, web-service):

• The JWT token is re-validated locally (via a filter or interceptor).

• The claims (e.g., user roles, email, channelId) are extracted.

• Access control is enforced based on these claims.

✅ Benefits:

• Each service is protected from unauthorized access.

• Claims provide context to fine-tune access per endpoint.

• No service is directly exposed—all go through the gateway.

✅ Summary

This architecture ensures both scalability and security, avoiding tight coupling and enabling centralized authentication with distributed authorization.