How Web Authentication Works: Sessions, JWTs, and OAuth

Ever wondered why you can stay logged into your favorite social media app for weeks, but your bank session expires after ten minutes of inactivity?

At its core, authentication is the process of proving you are who you say you are. While we usually simplify this to "entering a password," the actual machinery happening between your browser and the server is a sophisticated dance of tokens, cookies, and encrypted handshakes.

Here is how authentication works on modern websites, from the initial login to the persistent session.

The Fundamental Problem: HTTP is Stateless

To understand authentication, you first have to understand that the web is "stateless."

HTTP (the protocol used to load websites) has no memory. When you click a link on a profile page, the server doesn't naturally know that you are the same person who logged in five seconds ago. Without an authentication system, you would have to send your username and password with every single click.

To solve this, developers use Session Management.

1. Session-Based Authentication (Stateful)

This is the "traditional" approach. It relies on the server remembering who you are.

How it works:

1. The Handshake: You enter your credentials. The server verifies them against a database.
2. The Session ID: If correct, the server creates a "session" (a small file or database entry) and generates a unique Session ID.
3. The Cookie: The server sends this Session ID back to your browser in a Set-Cookie header.
4. The Loop: Every time you make a request, your browser automatically attaches that cookie. The server looks at the ID, finds the matching session in its memory, and says, "Ah, this is User 123," and grants access.

The Downside: As a website grows to millions of users, storing all those sessions in the server's memory becomes expensive and difficult to scale across multiple servers.

2. Token-Based Authentication (Stateless)

Modern web apps—especially those using frameworks like React, Vue, or Python's FastAPI—prefer tokens, most commonly JSON Web Tokens (JWT).

Unlike sessions, the server doesn't store anything. Instead, it gives the "proof of identity" to the user to hold onto.

The JWT Flow:

1. Login: You provide your credentials.
2. The Token: The server creates a JWT. This token contains a "payload" (e.g., your user ID and expiration date) and is digitally signed using a secret key known only to the server.
3. Storage: The browser stores this token (usually in localStorage or an httpOnly cookie).
4. Validation: When you request data, you send the token in the HTTP header. The server doesn't look in a database; it simply checks if the digital signature is valid. If the signature matches, the server trusts the data inside the token.

The Advantage: This is highly scalable. Any server in a cluster can verify the token without needing to check a central session database.

3. Multi-Factor Authentication (MFA)

Because passwords can be stolen or guessed, modern sites add layers of verification. MFA typically combines two or more of these categories: * Something you know: Password or PIN. * Something you have: A smartphone (Authenticator app), a hardware key (YubiKey), or an SMS code. * Something you are: Biometrics like FaceID or fingerprints.

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

You've seen "Log in with Google" or "Log in with GitHub" everywhere. This is powered by OAuth 2.0 and OpenID Connect.

Instead of creating a new account, you are delegating trust. The process looks like this: 1. You tell Website A you want to log in via Google. 2. Website A redirects you to Google. 3. You authenticate with Google. 4. Google sends a "temporary authorization code" back to Website A. 5. Website A exchanges that code for an Access Token.

Website A never sees your Google password; it only receives a token that says, "Google confirms this user is valid and we allow you to see their email address."

Summary: Which one to use?