Authentication and Authorization

# CHAPTER 8

Authentication and Authorization #

1. Introduction #

2. Learning Objectives #

• Define the critical difference between Authentication and Authorization.

• Explain why storing plain-text passwords is an architectural crime (Hashing vs. Encryption).

• Compare stateful Server Sessions against stateless JSON Web Tokens (JWT).

• Architect a highly scalable, stateless JWT authentication flow.

• Understand the basics of OAuth 2.0 and Single Sign-On (SSO).

3. Authentication vs. Authorization #

• Authentication (Who are you?): The process of verifying a user's identity. (e.g., A user provides an email and a password. The system verifies they match).

• Authorization (What are you allowed to do?): The process of verifying a user's permissions. (e.g., The system knows you are John. But is John allowed to delete the database? No, because John has the role of 'Viewer', not 'Admin').

4. Storing Passwords (Hashing) #

• The Rule: You must use a Cryptographic Hash function (like bcrypt or Argon2).

• How it works: A hash is a one-way mathematical function. It turns the password apple123 into $2b$12$L7.... It is mathematically impossible to reverse the hash back into the word apple123.

• The Verification: When a user logs in, the server hashes the password they just typed and compares the *new hash* to the *saved hash* in the database.

5. Stateful Sessions (The Scaling Problem) #

• The Flow: User logs in. Server creates a "Session" in its local RAM (Session ID: xyz123 = User: John). Server sends a cookie containing xyz123 to the browser. Every subsequent HTTP request includes the cookie. The server looks up xyz123 in its RAM, sees it's John, and approves the request.

• The Architecture Flaw: As discussed in Chapter 2, if you have 100 Web Servers, and Server 1 holds John's session in its RAM, John's next request *must* be routed to Server 1. If it hits Server 2, Server 2 has no idea who John is, and logs him out. This breaks Horizontal Scaling.

• The Patch: To fix this, architects must move the Sessions out of local RAM and into a centralized, distributed Redis Cache. Now, all 100 servers check Redis to verify the session.

6. JSON Web Tokens (Stateless Scaling) #

• The Flow: User logs in. Server verifies password. The Server creates a JWT (a long cryptographic string) that contains the user's data payload ({"userId": 5, "role": "admin"}). Crucially, the server signs the token using a secret cryptographic key, and sends it to the client.

• The Magic: The server saves *nothing* in its RAM or Database. It forgets the user instantly.

• The Verification: When the user makes their next API request, they attach the JWT. The server uses its secret key to verify the cryptographic signature of the JWT. If the signature is valid, the server trusts the data inside the token (userId: 5).

• The Benefit: Because the token itself contains all the required proof, the server doesn't need to check a database or Redis cache. Infinite horizontal scaling with zero memory overhead.

7. Diagrams/Visual Suggestions #

[ Client App ]
      |
      | 1. POST /login (email, password)
      v
[ Auth Server ] --> (Verifies DB) --> Creates Signed JWT
      |
      | 2. Returns JWT Token to Client
      v
[ Client App ] (Saves token locally)
      |
      | 3. GET /api/data + Header: "Authorization: Bearer <JWT>"
      v
[ Any Web Server ] --> (Mathematically verifies signature) --> Returns Data

8. Best Practices #

• Role-Based Access Control (RBAC): Build Authorization logic early. Every user should have a role (e.g., guest, user, admin). Every sensitive API endpoint must check the user's role before executing logic. If an API blindly trusts that only Admins will access the Admin Dashboard, a hacker will manually hit the /deleteUser endpoint and bypass the UI entirely.

9. Common Mistakes #

• The Un-revokable JWT: Because JWTs are stateless and the server doesn't track them in a database, you cannot easily "log out" a user or ban them instantly. If a hacker steals a JWT, they can use it until it expires. *The Fix:* JWTs MUST have a very short expiration time (e.g., 15 minutes). To keep the user logged in seamlessly, architects implement a complex "Refresh Token" system to silently generate new short-lived JWTs in the background.

10. Mini Project: Trace an OAuth Login (SSO) #

1. 1. The Goal: Add "Log in with Google" (OAuth 2.0).

1. 2. The Redirect: User clicks the button. Your app redirects them to Google's highly secure servers.

1. 3. The Auth: The user logs into Google (handling 2FA, passwords, etc.). Google asks: "Do you allow this app to see your email?"

1. 4. The Callback: Google redirects the user back to your app with an "Authorization Code."

1. 5. The Token: Your backend server securely trades that Code with Google's API for an "Access Token," proving the user's identity without your server *ever* seeing or storing their actual password.

11. Practice Exercises #

1. 1. Define the difference between Authentication and Authorization. Give a real-world example of an interaction failing due to an Authorization error.

1. 2. Explain why storing "Stateful Sessions" in the local RAM of a web server destroys the ability to perform simple Horizontal Scaling.

12. MCQs with Answers #

13. Interview Questions #

• Q: Explain the mechanical difference between Hashing a password and Encrypting a password. Why do we strictly Hash passwords, but Encrypt credit card numbers?

• Q: Walk me through the security vulnerability of "Stateless" JWTs regarding compromised accounts. If a hacker steals a user's JWT, why is it incredibly difficult for the system architect to instantly revoke access, and how does the "Refresh Token" pattern mitigate this risk?

• Q: What is OAuth 2.0? Describe a scenario where an architect would choose to implement an external Identity Provider (like Auth0 or Okta) rather than building a custom username/password database from scratch.

14. FAQs #

15. Summary #

16. Next Chapter Recommendation #