Authentication and Security in System Design

# CHAPTER 13

Authentication and Security in System Design #

1. Chapter Introduction #

You can design a system capable of handling 10 million TPS, but if a single hacker can download your entire user database, your architecture is a catastrophic failure. In senior FAANG interviews, security is a first-class citizen. You must explicitly build security into the API Gateway and Load Balancers. This chapter covers the critical difference between Authentication and Authorization, the mechanics of stateless JWTs, OAuth integration, and DDoS protection via Rate Limiting.

2. Authentication vs. Authorization #

Never confuse these two terms in an interview:

• Authentication (AuthN): "Who are you?" (Verifying identity via Username/Password, Biometrics, or 2FA).

• Authorization (AuthZ): "What are you allowed to do?" (Verifying permissions. Can this User delete this specific Database record? Role-Based Access Control).

3. Stateful vs. Stateless Authentication #

How does a stateless Microservice know who the user is on every single HTTP request?

1. Stateful Sessions (The Old Way):

• User logs in. Server creates a Session ID and stores it in its local RAM (or Redis). The Server sends a Cookie containing the Session ID to the browser.

• *Problem:* If the user's next request hits a different server (due to Load Balancing), that server doesn't have the Session ID in RAM. The user is logged out.

2. Stateless JWT (JSON Web Tokens - The Modern Way):

• User logs in. Server validates password and generates a signed JWT containing the user's ID and Roles (e.g., {"id": 123, "role": "admin"}).

• The Server does *not* save this token in a database. It sends it to the Client.

• The Client includes the JWT in the Authorization: Bearer <token> header of every subsequent HTTP request.

• *Solution:* ANY microservice can mathematically verify the cryptographic signature of the JWT to ensure it wasn't tampered with, extract the User ID, and process the request without ever querying a central Session Database.

4. Single Sign-On (SSO) and OAuth 2.0 #

In system design, you rarely build your own massive identity management system from scratch. You use OAuth. *OAuth 2.0* is the industry standard protocol that allows a user to grant a third-party application access to their information without giving them their password. *Example:* "Log in with Google."

1. 1. User clicks "Log in with Google" on your app.

1. 2. User is redirected to Google.com and enters their password.

1. 3. Google sends an Authorization Code back to your App.

1. 4. Your App trades the Code for an Access Token.

1. 5. Your App uses the Access Token to fetch the user's email from Google and creates a local account.

5. Rate Limiting (DDoS Protection) #

A Distributed Denial of Service (DDoS) attack involves millions of compromised computers spamming your API to crash your servers. A Rate Limiter is placed at the API Gateway or Load Balancer. It controls the number of requests a client can make in a given timeframe.

*Common Rate Limiting Algorithms:*

1. 1. Token Bucket: A bucket holds 'tokens'. Every request costs 1 token. Tokens refill at a steady rate. If the bucket is empty, requests are dropped (HTTP 429 Too Many Requests). *Best overall.*

1. 2. Leaky Bucket: Requests enter a queue. The queue processes requests at a fixed, steady rate, smoothing out massive spikes.

1. 3. Fixed Window: Limits requests per minute (e.g., 100 requests between 10:00 and 10:01). *Flaw:* A burst of 200 requests at 10:00:59 and 10:01:01 can overwhelm the server at the window edges.

6. Security Best Practices at the Architecture Level #

• HTTPS Everywhere: All communication from the Client to the Load Balancer MUST be encrypted using TLS/SSL to prevent Man-in-the-Middle attacks.

• VPC (Virtual Private Cloud): Your databases and internal microservices should NEVER have public IP addresses. They should exist inside a Private Subnet. Only the Load Balancer/API Gateway exists in the Public Subnet, acting as the sole entry point.

• Principle of Least Privilege: Microservice A should only have read access to the exact database tables it needs, nothing more.

7. Real-World Scenario: The API Gateway Security Layer #

*Scenario:* You are designing a Microservices architecture for a bank. *Candidate Error:* "The mobile app will send a JWT to the Transfer Microservice, which will validate the JWT and process the transfer." *The Fix:* "Security should be centralized. The mobile app sends the JWT to the API Gateway. The API Gateway handles Rate Limiting and validates the JWT cryptographic signature. If valid, it strips the token, appends the User ID to the HTTP header, and routes the request to the internal, hidden Transfer Microservice. The internal microservices do not waste CPU validating tokens."

8. Mini Project: Design a Rate Limiter #

Whiteboard a distributed Rate Limiter using Redis.

1. 1. User IP 192.168.1.1 makes an API request.

1. 2. API Gateway queries Redis: GET rate_limit:192.168.1.1

1. 3. If value < 100, INCR the value and allow request.

1. 4. If value >= 100, return HTTP 429.

1. 5. Set the Redis key to expire (TTL) every 60 seconds.

9. Common Mistakes #

• Storing Passwords in Plain Text: Passwords must ALWAYS be hashed and salted using robust algorithms like bcrypt or Argon2. Never use MD5 or SHA-256 for passwords.

• Putting secrets in code: Never hardcode API keys or database passwords in the application code. Use a centralized Secrets Manager (e.g., AWS Secrets Manager, HashiCorp Vault).

10. Best Practices #

• Sanitize All Inputs: Treat all user input as malicious. Sanitize inputs to prevent SQL Injection and Cross-Site Scripting (XSS). Use parameterized queries in your database access layer.

11. Exercises #

1. 1. Explain why using a Stateful Session ID in a cluster of 50 stateless microservices creates a massive architectural bottleneck.

1. 2. What is the difference between OAuth 2.0 and JWT?

12. MCQs #

14. Interview Questions #

• Q: "An attacker is using a botnet of 10,000 different IP addresses to brute-force passwords on our login endpoint. How do you design a rate limiter to stop this, since IP-based rate limiting won't work?"

15. FAQs #

• Q: Are JWTs encrypted?

A: Usually, NO. Standard JWTs are Base64 encoded and *signed*, but not encrypted. Anyone who intercepts a JWT can read the JSON payload (like User ID or Email). Never put highly sensitive data (like a credit card number) inside a standard JWT payload.

16. Summary #

Security must be baked into the architecture from day one. Use JWTs to facilitate stateless authentication across distributed microservices. Centralize your security checks (Token validation, Rate Limiting for DDoS protection) at the API Gateway. Ensure all databases and internal services are hidden in Private Subnets, and always hash passwords using modern algorithms.

17. Next Chapter Recommendation #

With 50 microservices running securely in the cloud, how do you know if one of them is secretly failing? In Chapter 14: Monitoring, Logging, and Observability, we will learn how to track errors, aggregate distributed logs, and set up alerting systems to catch bugs before users do.