How Authentication Works in Web Applications

In this post, let's understand how authentication in web applications works.

We'll cover two common approaches:

• Session based authentication
• Token based authentication (usually JWT)

The Core Problem Authentication Solves

Imagine a server as a guarded building.

Before you're allowed inside, you need to prove who you are. Once you've proven it, the server needs a reliable way to recognize you again on every subsequent request without asking for your username and password each time.

That "recognition" is what authentication mechanisms provide.

Security Essentials

Before diving into the mechanisms, two critical requirements:

HTTPS is mandatory. Sending credentials or tokens over HTTP means they can be intercepted in transit. Authentication must always happen over encrypted connections.

Passwords are never stored directly. Servers store salted hashes (using bcrypt, Argon2, or similar) that can verify but not reveal the original password. When you log in, the server hashes your input and compares it to the stored hash never the plaintext password.

Session Based Authentication

What Actually Happens

1. A user enters their username and password on a login page.
2. The browser sends these credentials to the server.
3. The server verifies them against its database.
4. If they match, the server creates a session.
5. The server sends back a session ID inside a cookie.
6. The browser stores this cookie automatically.
7. From this point onward, every request the browser makes includes that cookie.

Note: You don't need to set the cookie manually in subsequent requests. Your browser automatically includes it on all requests that match the cookie's domain.

The cookie itself does not contain user data. It simply contains a session identifier.

Where the State Lives

On the server.

When the server issues a session ID, it also stores something like this internally:

• Session ID → User ID
• Session status (active / expired)
• Optional metadata (timestamps, IP, etc.)

Every incoming request follows this flow:

1. Read the session ID from the cookie
2. Look it up in the server's session store
3. Verify that the session is still valid

As long as that session exists and is active, the user is authenticated.

This is why session based authentication is called stateful. The server is actively tracking who is logged in.

Client

Server

Database

• No cookie yet

• Cookie
  sid=abc123

• No cookie yet

• users
  42 → pw hash

• users
  42 → pw hash
• sessions
  abc123 → user 42

• users
  42 → pw hash

Login·Step 1 of 7

Client sends credentials

Client → ServerPOST /login { email, password }

The username and password travel to the server over HTTPS.

Server checks the password

Server → Databasefind user 42

Database → Serverpassword hash matches

The server hashes the submitted password and compares it with the stored hash. The plaintext password is never stored.

Server creates a session

Server → Databasecreate session abc123 → user 42

The server records who is logged in. Keeping this record is what makes session auth stateful.

Server returns the session ID in a cookie

Server → Client200 OK · Set-Cookie: sid=abc123

The cookie holds only the session ID, no user data. The browser stores it automatically.

Browser attaches the cookie

Client → ServerGET /dashboard · Cookie: sid=abc123

You don't add it yourself. The browser includes the cookie on every request to the matching domain.

Server looks up the session

Server → Databaselook up abc123

Database → Serveruser 42 · active

Every request costs one lookup in the session store.

Request succeeds

Server → Client200 OK

The session exists and is still active, so the user is authenticated.

Logging Out

When a user logs out:

1. The client sends a logout request to the server
2. The server deletes the session from the database
3. The server responds with success
4. The client removes the cookie

Since the session is deleted from the server's session store, any subsequent requests with that session ID will be rejected.

Client

Server

Database

• Cookie
  sid=abc123

• No cookie

• Cookie
  sid=abc123

• users
  42 → pw hash
• sessions
  abc123 → user 42

• users
  42 → pw hash

• users
  42 → pw hash
• sessions
  abc123 → user 42

Logout·Step 1 of 7

Client asks to log out

Client → ServerPOST /logout · Cookie: sid=abc123

The logout request carries the session cookie like any other.

Server deletes the session

Server → Databasedelete session abc123

The session ID no longer points to anyone.

Server confirms the logout

Server → Client200 OK

The response tells the client the session is gone.

Client removes the cookie

Clientcookie cleared

The browser drops the now useless session ID.

Someone replays the old session ID

Client → ServerGET /dashboard · Cookie: sid=abc123

For example, a copy of the cookie captured before logout.

Server looks up the session

Server → Databaselook up abc123

Database → Servernot found

The ID is no longer in the session store.

Request rejected

Server → Client401 Unauthorized

Deleting the session revokes it everywhere at once. This is why sessions are easy to revoke.

Token Based Authentication (JWT)

Token based authentication follows a very similar start, but a very different continuation.

What Happens During Login

1. The user enters their username and password.
2. The browser sends them to the server.
3. The server validates the credentials.
4. Instead of creating a session, the server generates a token.
5. Most commonly, this token is a JWT (JSON Web Token).
6. The token is returned to the client and stored either:
   • In memory
   • In local storage
   • Or sometimes in a cookie

What's Inside the Token

A JWT contains:

• User identification (e.g., user ID)
• Optional metadata (roles, expiry time)
• A cryptographic signature

The signature is created using a secret key known only to the server.

This is the critical part.

Making Authenticated Requests

For every subsequent request:

1. The client sends the token in the Authorization header
2. Typically as: Authorization: Bearer <token>

When the server receives the request:

1. It verifies the token's signature using its secret
2. It checks expiry and validity
3. If valid, the request is authenticated

No database lookup is required.

The server does not store session state.

This is why token based authentication is called stateless.

Why the Token Can't Be Tampered With

Any changes to the token content modifies the signature, causing signature verification to fail on the server.

Since the client doesn't have the secret key, any tampering to the token is impossible. The client cannot create a valid signature for modified content.

This guarantees integrity without requiring server side storage.

Client

Server

Database

• No token yet

• JWT
  eyJhbGciOi…

• No token yet

• Secret key
  ••••••••

• Secret key
  ••••••••

• users
  42 → pw hash

• users
  42 → pw hash

Login·Step 1 of 10

Client sends credentials

Client → ServerPOST /login { email, password }

The username and password travel to the server over HTTPS.

Server checks the password

Server → Databasefind user 42

Database → Serverpassword hash matches

The server hashes the submitted password and compares it with the stored hash. The plaintext password is never stored.

Server signs a JWT

Serversign({ sub: 42, exp }, secret)

The token holds the user ID and expiry, plus a signature made with the secret key. Nothing is saved on the server.

Client stores the token

Server → Client200 OK · { token: "eyJhbGciOi…" }

In memory, in localStorage, or sometimes in a cookie.

Client sends the token in a header

Client → ServerGET /dashboard · Authorization: Bearer eyJhbGciOi…

Unlike a cookie, the client attaches the token itself.

Server verifies the signature

Serververify(token, secret) ✓ signature ✓ not expired

No database lookup. The signature and expiry are all the server needs, which is what makes this stateless.

Request succeeds

Server → Client200 OK

The token is valid, so the user is authenticated.

Someone edits the token

Client → ServerBearer eyJhbGciOi… (sub changed 42 → 1)

Say they change the user ID to act as another account.

The signature doesn't match

Serververify(token, secret) ✗ signature mismatch

Changing the content changes the expected signature. Without the secret key, nobody else can produce a valid one.

Request rejected

Server → Client401 Unauthorized

Integrity is guaranteed without storing anything on the server.

Logging Out

Token based logout is simpler because there's no server side session to invalidate:

1. The client simply removes the token from storage (memory/localStorage)
2. No server communication is required

The token becomes useless once removed. However, if the token is stolen before logout, it remains valid until expiry.

If it's critical for your app to not allow requests from a token after logout, you can blacklist the token by adding revoked tokens to an in memory database.

The other solution is to have access tokens with short validity periods, limiting the window of risk.

Client

Servernot used

Databasenot used

• JWT
  eyJhbGciOi…

• No token

• No token

• Secret key
  ••••••••

• Secret key
  ••••••••

• users
  42 → pw hash

• users
  42 → pw hash

Logout·Step 1 of 4

Client deletes the token

ClientlocalStorage.removeItem("token")

That's the whole logout. No request is sent to the server.

A copy stolen before logout is used

Client → ServerGET /dashboard · Authorization: Bearer eyJhbGciOi…

Deleting the token on one client doesn't affect copies of it elsewhere.

The signature still checks out

Serververify(token, secret) ✓ signature ✓ not expired

The server kept no record of the token, so it has nothing to invalidate.

The stolen token works until it expires

Server → Client200 OK

To limit this, use short-lived access tokens or keep a denylist of revoked tokens.

Key Differences at a Glance

Aspect	Session Based	Token Based
Server state	Stored on server	Not stored
Scalability	Harder (shared state)	Easier
Cookie usage	Required	Optional
Revocation	Easy	Harder
Stateless	No	Yes

Final Thoughts

Both approaches exist for good reasons.

Session based authentication is simple, intuitive, and easy to revoke.

Token based authentication scales better and works naturally with distributed systems.

The important part isn't choosing one blindly. It's understanding where the state lives, how identity is verified, and what trade-offs you're making.

Once that's clear, authentication stops feeling like magic and starts feeling like engineering.