How Session Tokens Actually Work (and Why MFA Can't Save a Stolen One)

When you log into a web application, you prove who you are once — password, maybe a second factor — and then you click around for an hour without re-entering anything. Something has to remember that you already authenticated. That something is the session token, and understanding it explains a whole class of attacks that otherwise look like magic.

What a session token is

Authentication and authorization are expensive and annoying to repeat. So after you successfully log in, the server hands your browser a token: a string that says, in effect, "the holder of this has already proven they are this user, until it expires." Every subsequent request carries it — usually in a cookie, sometimes in an Authorization header — and the server checks the token instead of asking for your password again.

There are different shapes. An opaque session ID is just a random string that points at server-side state ("session abc123 belongs to user 42, expires at 3pm"). A signed token like a JWT carries the claims inside itself, signed by the server so it can't be tampered with, and is validated without a database lookup. The shape varies; the role is identical. The token is a stand-in for a completed login.

The crucial property: it's a bearer credential

Here is the part that matters for security. A session token is a bearer credential. That means whoever holds it is treated as the authenticated user — full stop. The server does not, on each request, re-check that the holder is the same human who logged in. It can't; the whole point of the token is to avoid re-proving identity. So possession is authentication.

This is by design and it is also the weakness. If an attacker obtains a valid, unexpired session token — copied from a browser, lifted from a network capture, pulled out of malware on the endpoint, or read from a file where it was inadvertently saved — they can present it and be you. They don't need your password. They don't need your phone.

Why MFA doesn't help here

People assume multi-factor authentication protects the session. It doesn't, and the reason is timing. MFA guards the act of logging in — the moment the token is minted. Once the token exists, that work is done and spent. The token represents a login where the password and the second factor were already satisfied. Replaying it doesn't trigger a new login, so there's no second factor to fail.

Put bluntly: MFA protects the front door. The session token is a key that was cut after you walked through it. Steal the key and you don't knock.

What actually protects a session

Since you can't re-litigate MFA on every request, the defenses live elsewhere:

Short lifetimes. A token that expires quickly is a small window. Aggressive expiry plus re-authentication for sensitive actions shrinks the value of any stolen session.
Binding. Tie the token to the device, client, or network it was issued to, so a token presented from somewhere else is rejected. This is the single highest-leverage control: it makes a stolen token non-portable.
Anomaly detection. The same token used from two geographies, two device fingerprints, or two IPs in a short window is a detectable event. This is often how a stolen session is caught.
Revocation. You need a way to kill a token immediately when something looks wrong — which is easier with server-side sessions than with stateless tokens that are valid until they expire.

The one-sentence version

A session token is proof that authentication already happened, handed to whoever holds it — so the entire game is keeping it from being copied, narrowing how long and from where it works, and noticing when it shows up somewhere it shouldn't. MFA was upstream of all of that, which is exactly why it can't help once the token is gone.