Authentication Concepts: Sessions vs. Tokens

"Who are you, and are you allowed to do this?" This is the core question that Authentication (AuthN) and Authorization (AuthZ) answer.

Before we write code, we must decide on the Strategy. In the web world, there are two primary ways to remember who a user is: Sessions and Tokens. FastAPI is built for the latter.

---

1. Stateful Sessions (The Legacy Way)

Common in frameworks like Django or Rails.

1. User logs in.
2. Server creates a "Session ID" and stores it in a Database or memory.
3. Server sends a "Session Cookie" to the browser.
4. Every time the user makes a request, the server looks up the Session ID in its database to see who they are.

The Problem:

• Scaling: If you have 10 servers, they all need to share the same session database.
• Latency: Every request requires a database lookup just to identify the user.

---

2. Stateless Tokens (The JWT Way)

Common in FastAPI and modern Microservices.

1. User logs in.
2. Server creates a JSON Web Token (JWT). This token contains the user's ID inside it, cryptographically signed.
3. Server sends the token to the user.
4. Every time the user makes a request, they send the token in the Authorization header.
5. The Server doesn't look anything up. It simply verifies the signature. If the signature matches, the server trusts the information inside the token.

The Benefit:

• Stateless: The server doesn't "remember" anything. It just validates.
• Extreme Scale: You can have 1,000 servers, and they can all validate tokens without talking to a central database.

---

3. JWT Structure: Header, Payload, Signature

A JWT (e.g., xxxx.yyyy.zzzz) has three parts:

• Header: The algorithm used (e.g., HS256).
• Payload: The "Claims" (e.g., user_id: 123, exp: 2026-01-15).
• Signature: A hash that ensures the payload hasn't been tampered with.

---

4. Authentication vs. Authorization

Don't confuse the two!

1. Authentication (AuthN): Identifying the user (e.g., "Are you Sudeep?").
2. Authorization (AuthZ): Checking permissions (e.g., "Sudeep is identified, but is he an Admin allowed to delete this post?").

---

Visualizing the JWT Flow

sequenceDiagram
    participant U as User (Frontend)
    participant S as Server (FastAPI)
    
    U->>S: POST /login (Username/Pass)
    Note over S: Verify Credentials
    S-->>U: 200 OK (JWT Token)
    
    Note over U: Save token in LocalStorage
    
    U->>S: GET /profile (Header: Bearer TOKEN)
    Note over S: Verify Signature (No DB lookup!)
    S-->>U: 200 OK (User Profile)

---

Summary

• Sessions are stateful (database-dependent).
• Tokens (JWT) are stateless (self-contained and scalable).
• FastAPI excels at token-based auth.
• Signature Verification is the key to trusting the data in a stateless environment.

In the next lesson, we’ll dive into OAuth2 and JWT—the specific tools FastAPI uses to implement this flow.

---

Exercise: The Security Trade-off

If a user changes their password, how do you "Revoke" their old JWT tokens if the server doesn't check a database for every request? Hint: Research the concept of "Token Expiry" and "Blacklisting."