Forem: Zeba

JWT Explained for Beginners — With Simple Math Analogies

Zeba — Sun, 01 Mar 2026 21:33:47 +0000

When a user logs in, the server needs to remember who they are on every request. One way is sessions, but that means storing data on the server. JWT solves this differently — all the user info like user ID, roles, and expiry is packed into the token itself, so the server just verifies the signature on each request without hitting the database every time.

A JWT, or JSON Web Token, is made of three parts joined by dots: Header, Payload, and Signature.
header.payload.signature

The Header tells us which algorithm was used to sign the token — like HS256 or RS256 — along with the token type.
The Payload holds the actual user data, called "claims" — things like the user's ID, their role, when the token was issued (iat), and when it expires (exp). Common claims are:

sub → Subject (user ID) iss → Issuer aud → Audience exp → Expiration time iat → Issued at
The Signature is what keeps the token trustworthy.

To create the Signature, the server takes the Base64-encoded Header and Payload, joins them, and runs them through a hashing function along with a secret key. Think of it like:
Header + Payload = message message + key = signature.
This signature is then attached to the token.

When the user sends the token back, the server needs to verify it. There are two ways depending on the algorithm.
1: With HS256 (symmetric) : During request validation, the server takes the message from the token, uses the same secret to generate a new signature, and compares it with the signature inside the token.
Let's understand with an analogy:
Assume:
secret = 3 & Signing rule is : multiplication by secret signature = message × secret

During token generation

Assume

message = 10

signature = 10 * 3 = 30 So token ---> 10.30

During Token Validation (Coming User Request (with token))

Assume coming token ---> 10.30

Application will recalculate signature using the token's message:

signaure(Coming User Request) = 10 * 3 = 30

Now compare this signature with the signature attched in the token

signature(Request User's 30) == signature calculated (30) 30 == 30 --> True ✔ Token is valid.

Now, assume, attacker modified the message(Token)

Assume coming token ---> 18.30

Application will recalculate signature using the token's message:

signaure(Request) = 18 * 3 = 36
But the signature is 30, so

signature(User's 36) != signature (30) ❌ Token is Invalid.

But what if we don't want to share the same secret key everywhere? That's where RS256 comes in.

2: With RS256 (asymmetric): The server(Application) signs using a private key, but verification is done using a public key. This is useful in microservices where multiple services need to verify tokens without ever seeing the private key.

There are two keys:

Private key → used to SIGN Public key → used to VERIFY

Only the Identity Provider has the private key. Your API only has the public key.

🔐 Signing Process (Token Generation)

Assume a very simple fake math model:

Private key operation = multiply by 3
Public key operation = divide by 3

(Note: This is NOT real RSA — just to understand concept.)

Assume the message generated is 10
message = 10

Now Sign Using Private Key
signature = message × 3 signature = 10 × 3 = 30

So full token conceptually: 10.30

Verification Process:
Requested token: 10.30 message = 10 & signature = 30

public key = divide by 3

Now it verifies:
expected_message = signature ÷ 3 = 30 ÷ 3 = 10Now compare:
expected_message == original message? 10 == 10 → TRUE
✔ Token is valid.

Let's see if the message (token) is modified"

Case 1: Attacker modified the message
Token Received: 20.30, but original token was 10.30 so recieved message = 20 & signature = 30
Verification:
expected_message = signature ÷ 3 => 30 ÷ 3 = 10
Compare:
10 == 20 → FALSE ❌ Token is Invalid.

Case 2: Attacker/User Used the wrong Public Key

Suppose used public key = divide by 5 (original was divided by 3)
Requested token: 10.30

Then:
expected_message = 30 ÷ 5 = 6

Compare:
6 == 10 → FALSE ❌ Invalid

This is why even if someone steals your token and changes the user ID to get admin access, it won't work. The signature will fail verification.

One important thing to remember. The payload is only Base64 encoded, not encrypted. Anyone can decode and read it. So never store sensitive data like passwords inside a JWT. The signature only proves the token wasn't tampered with; it does not hide the data.

Session-Based Authentication in Django (Complete Internal Flow)

Zeba — Tue, 17 Feb 2026 19:02:04 +0000

Complete Internal Flow (From Signup to Request Lifecycle)

Authentication is one of the most fundamental parts of any web application.
In Django, authentication feels simple — you call authenticate() and login() and everything works.

But internally, several layers coordinate:

Database tables
Password hashing
Session engine
Cookies
Middleware
Request lifecycle

Understanding this deeply gives you architectural clarity and debugging power.
This guide explains the complete internal flow of session-based authentication in Django — step by step.

Big Picture: What Django Uses by Default

Django uses server-side session-based authentication by default via django.contrib.auth.
That means:

The server stores session data.
The browser only stores a session ID.
Every request is validated using middleware.

JWT or token-based authentication is not the default — it must be added separately.

Core Components Involved

Before diving into the flow, understand the building blocks.

🔹 A- Database Tables
auth_user(table)
Stores:
- id (primary key)
- username
- email
- hashed password
- is_active, is_staff, etc
Passwords are never stored in plain text.

django_session(table)
Stores:
- session_key
- session_data (encoded)
- expire_date

This table connects session keys to user IDs.

🔹 B. Browser (Client)
The browser:

Stores the sessionid cookie
Automatically sends it with every request

Important:
The browser never knows

The password
The session data
The user ID directly It only knows a random session key.

🔹 C. Middleware
Two critical middleware classes:
- SessionMiddleware
- AuthenticationMiddleware
These run before your view executes.

Let’s understand what happens internally when:

A user signs up
A user logs in
The browser makes future requests

1. User Signup (Creating a User)

What Your Signup View Does

You create a user using Django’s built-in User model:

from django.contrib.auth.models import User
from django.http import JsonResponse

def signup(request):
    username = request.POST.get("username")
    password = request.POST.get("password")

    User.objects.create_user(
        username=username,
        password=password
    )

    return JsonResponse({"message": "User created successfully"})

What Django Does Internally

When you call create_user():

The password is automatically hashed
The user is stored in the auth_user table
The plain-text password is never saved

Important:
At signup time, no session is created.
The user is not logged in automatically.

Signup only creates a database record.

2. User Login (Authentication Step)

Login View

from django.contrib.auth import authenticate, login
from django.http import JsonResponse

def login_view(request):
    username = request.POST.get("username")
    password = request.POST.get("password")

    user = authenticate(username=username, password=password)

    if user is not None:
        login(request, user)
        return JsonResponse({"message": "Login successful"})
    else:
        return JsonResponse(
            {"error": "Invalid credentials"},
            status=401
        )

This flow has two important parts:

authenticate() → validates credentials
login() → creates the session

Let’s break them down.

2.A: What authenticate() Actually Does

authenticate(username, password)

Internally, Django:

Looks up the user in the auth_user table
Hashes the input password
Compares it with the stored hashed password

It returns:

A User object if credentials are valid
None if credentials are invalid

Important:
authenticate() does not create a session.
It only verifies identity.

2.B What login(request, user) Actually Does

This is where session-based authentication begins.
When you call:

login(request, user)

Django performs three key steps.

Step 1: Create a New Session

Django generates a random session key, for example:

 ```
 abc123xyz
 ```

Step 2: Store the Session in the Database
In the djnago_session table:

_auth_user_id stores the logged-in user’s ID.

Step 3: Send Session ID to the Browser

Django sends this header:

```
Set-Cookie: sessionid=abc123xyz

```

The browser stores this cookie automatically. From this point
onward,browser includes sessionID in every request.

3. What Happens on Every Request After Login

For every future request, the browser sends:

   Cookie: sessionid=abc123xyz

Now middleware processing begins.

3A. SessionMiddleware

The first important middleware is SessionMiddleware.
It:

Reads sessionid from cookies
Queries the django_session table
Loads the session data
Attaches it to request.session

Now:

request.session["_auth_user_id"] = 5

3B. AuthenticationMiddleware

Next, AuthenticationMiddleware runs.

It:

Reads _auth_user_id from session
Queries auth_user
Fetches User object
Attaches it to request

Now:

request.user

This is how request.user becomes available in every view.
Complete Request Lifecycle Diagram

Browser Request
Cookie: sessionid=XYZ
        ↓
SessionMiddleware
        ↓
Load session from django_session
        ↓
Attach request.session
        ↓
AuthenticationMiddleware
        ↓
Load user from auth_user
        ↓
Attach request.user
        ↓
Your View Executes

4. AnonymousUser Behavior

Django does not automatically block unauthenticated users.

Even if the user is not logged in:

The view will still execute
request.user will still exist

However:

request.user.is_authenticated  # False

In that case, request.user is an AnonymousUser.

Middleware attaches the user to the request.
It does not enforce access control.

5. Why This View Is Public

def profile(request):
return JsonResponse({"profile": "data"})

This view has no restriction.
Django will not prevent unauthenticated users from accessing it.
Security must be explicitly enforced.

6.How to Restrict Access Properly

Option 1: Using login_required (Recommended)

from django.contrib.auth.decorators import login_required

@login_required
def profile(request):
    return JsonResponse({"profile": "private data"})

Behavior:

If not logged in → redirect to login page
If logged in → view executes normally

Option 2: Manual Check

def profile(request):
    if not request.user.is_authenticated:
        return JsonResponse(
            {"error": "Unauthorized"},
            status=401
        )

    return JsonResponse({"profile": "private data"})

Mental Model

Think of the authentication flow like this:

Signup              → Creates user (no session)
Authenticate        → Validates credentials
Login               → Creates session + sends cookie
SessionMiddleware   → Loads session
AuthenticationMiddleware → Loads user
View execution      → Always happens
Access control      → Must be enforced by you

🏁 Final Deep Mental Model

Think in layers:

Layer 1 → Database (auth_user, django_session)
Layer 2 → Session Engine
Layer 3 → Middleware
Layer 4 → View
Layer 5 → Access Control Logic