🟢 Junior Level

Authentication — who are you? (identity verification)

Authorization — what are you allowed to do? (permission check)

The most popular approach — JWT tokens:

1. Client → Login Service → username/password
2. Login Service → JWT token
3. Client → JWT token → API Gateway → token validation
4. API Gateway → forwards to services + userId in header

JWT token contains:

• Who the user is (userId, roles)
• Signature (to prevent forgery)

---

🟡 Middle Level

JWT in API Gateway

@Component
public class AuthFilter extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(HttpServletRequest request,
                                    HttpServletResponse response,
                                    FilterChain chain) {
        String token = request.getHeader("Authorization");

        if (token != null && token.startsWith("Bearer ")) {
            try {
                // JwtUtil — example utility class. In production, use Spring Security JWT
                // or a library like java-jwt (Auth0) / nimbus-jose-jwt.
                Claims claims = JwtUtil.parseToken(token.substring(7));
                request.setAttribute("userId", claims.get("userId"));
                request.setAttribute("roles", claims.get("roles"));
            } catch (JwtException e) {
                response.setStatus(HttpStatus.UNAUTHORIZED.value());
                return;
            }
        }

        chain.doFilter(request, response);
    }
}

OAuth 2.0 / OpenID Connect

Client → Auth Server (Keycloak) → Authorization Code
Client → Auth Server → Access Token + ID Token
Client → API Gateway + Access Token → Service

Common mistakes

1. Token validation in every service:

   Every service validates the token → cryptographic overhead (JWT signing is RSA/ECDSA).
   At 10K req/s across 20 services = 200K HMAC/RSA operations. Solution: API Gateway
   validates once and passes the result via header.
   

---

When NOT to use JWT

• High revocation requirements — JWT is hard to revoke (needs a blacklist)
• Session-based is better when instant session termination is needed
• OAuth2 Device Flow for devices without a browser

---

🔴 Senior Level

Token propagation

Gateway → Service A → Service B
         Access Token is passed along the chain

mTLS (mutual TLS)

Service A ↔ Service B: mutual certificate verification
Additional protection for service-to-service communication

Production Experience

Keycloak + Spring Security:

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: http://keycloak:8080/realms/myrealm
          jwk-set-uri: http://keycloak:8080/realms/myrealm/protocol/openid-connect/certs

Best Practices

✅ Token validation in Gateway
✅ HTTPS always
✅ Short-lived access tokens
✅ Refresh tokens
✅ mTLS for service-to-service
✅ Rotate signing keys

❌ Storing secrets in the token
❌ Without expiration
❌ Validation in every service
❌ HTTP for tokens

---

🎯 Interview Cheat Sheet

Must know:

• Authentication = who are you, authorization = what are you allowed to do
• JWT token: userId + roles + signature, passed in Authorization: Bearer header
• API Gateway validates the token once — services receive the result via header (avoids crypto overhead)
• OAuth 2.0 / OpenID Connect — standard approach with Auth Server (Keycloak)
• mTLS for service-to-service — mutual certificate verification
• Short-lived access tokens + refresh tokens — security balance
• Do NOT use JWT when high revocation requirements exist (need a blacklist)

Frequent follow-up questions:

• Why not validate in every service? RSA/ECDSA signature is expensive. At 10K req/s across 20 services = 200K HMAC operations.
• How to revoke a JWT? JWT is hard to revoke — need a blacklist or short-lived tokens. For instant revocation — session-based is better.
• JWT vs OAuth2? JWT is a token format, OAuth2 is a protocol. OAuth2 can use JWT as an access token.
• What is mTLS? Mutual TLS — both services verify each other’s certificates — service-to-service protection.

Red flags (NOT to say):

• “Every service validates JWT” — no, crypto overhead, Gateway validates once
• “JWT can store secrets” — no, JWT is signed but NOT encrypted (payload is readable)
• “Access token without expiration” — no, if leaked, the attacker has permanent access
• “HTTP for internal services” — no, tokens always over HTTPS

Related topics:

• [[9. What is API Gateway and what problems does it solve]]
• [[15. How to organize communication between microservices]]
• [[7. What is Service Discovery and why is it needed]]
• [[26. What tools are used for microservices orchestration]]
• [[22. What is distributed tracing]]