Unified SSO via Gateway: Multi‑App Auth & Authz and JWT vs Auth vs Authz

Background

Interview question asks how to build a unified account system that provides single sign‑on (SSO) across multiple applications and to explain the differences between JWT, authentication and authorization.

Solution Architecture

Adopt OAuth2.0 Authorization Code flow and a three‑tier architecture:

Gateway layer (Spring Cloud Gateway) – intercepts all requests, validates JWT and performs permission checks.

Auth server (Spring Security OAuth2) – implements /oauth/authorize and /oauth/token endpoints.

Resource services – trust the JWT and obtain user details from Redis.

Typical flow:

(1) User accesses Mall website → redirects to auth‑server
    https://sso.crazymaker.com/oauth/authorize?response_type=code&client_id=mall-web&redirect_uri=...&scope=user_info&state=abc123
(2) User logs in, auth‑server issues an <strong>authorization_code</strong>
(3) Front‑end receives <code>code</code> and calls POST /oauth/token with <code>client_secret</code>
(4) Auth‑server validates the code and returns a JWT <strong>access_token</strong>
(5) Gateway parses the JWT, injects user context, and forwards the request

Token Types

authorization_code

– one‑time credential, valid 5‑10 min, stored only in the redirect URL, must be exchanged together with client_secret. access_token – bearer token for API calls, valid 1‑2 h, stored client‑side (Cookie / LocalStorage), self‑contained JWT, transmitted over HTTPS. refresh_token – long‑lived credential (days‑weeks), stored in HttpOnly cookie or database, never exposed to the front‑end, can be revoked.

Security Hardening

JWT signed with HS256; the secret is kept only in the auth server and the gateway.

Access token expires after 2 hours; refresh token after 7 days.

Only non‑sensitive claims (userId, role, iss, exp) are placed in the payload.

All traffic forced over HTTPS; CSRF mitigated with the state parameter.

Token blacklist stored in Redis enables immediate revocation on logout.

Performance & Reliability

Daily login requests > 8 million.

SSO success rate 99.95 %.

Average authentication latency (P99) < 120 ms.

System integration time reduced from 3 person‑days to 0.5 person‑day.

Gateway QPS capacity > 15 000.

Permission cache hit latency 8 ms vs 80 ms for a database lookup.

Dynamic RBAC Design

Permissions are stored in MySQL tables sys_permission, sys_role_permission, sys_user_role and cached per userId:systemCode:terminal key in Redis (e.g. user:123:order:app). When a role‑permission mapping changes, a RabbitMQ topic PERMISSION_UPDATE_TOPIC triggers cache invalidation, achieving sub‑second permission updates.

// Example loading permissions from Redis in a gateway filter
String redisKey = "user:" + userId + ":" + systemCode + ":" + terminalType;
List<SysPermission> perms = redisTemplate.opsForValue().get(redisKey);
boolean allowed = perms.stream().anyMatch(p ->
    antMatcher.match(p.getPath(), requestUri) && p.getMethod().equalsIgnoreCase(requestMethod));

Key Design Decisions

OAuth2.0 Authorization Code flow chosen for its security (confidential client, short‑lived code, server‑side token exchange).

JWT used as a stateless access token – eliminates session stores and fits microservice architectures.

Redis cache for permission data reduces DB load and brings latency from ~80 ms down to ~8 ms.

Token blacklist in Redis solves the classic “cannot logout” problem of pure JWT.

Typical Interview Answers

Why choose Authorization Code flow? – Most secure for server‑side applications; supports confidential clients.

Difference between JWT and Session? – JWT is self‑contained and stateless, suitable for distributed systems; Session requires server‑side storage and is vulnerable to cookie theft.

How to prevent token theft? – Use HTTPS, short expiration, token blacklist, optional device fingerprint.

How to rotate a compromised signing key? – Publish a new key via a configuration center (e.g., Nacos), gradually invalidate old tokens while keeping services online.