How the server remembers you are logged in across many requests, so you don't re-enter your password on every click.
Why it exists
HTTP treats each request as unrelated to the last, yet a logged-in user expects the site to remember them from page to page. Asking for the password on every click would be absurd. A session exists to carry proof of a completed login across many requests, so the user authenticates once and stays recognized until they leave or time out.
How it actually works
HTTP treats each request as a stranger. Without help, the server would forget you the instant a page loaded. A session fixes this: after you log in, the server issues proof of "this is still you," which the browser sends with every following request.
That proof lives in a cookie or a token. As long as it is valid, you stay logged in. When it expires or you log out, the session ends.
A senior PM walks you through it
A junior PM, stuck
Customers keep messaging that they get logged out at random, mid-browse, without touching anything. The dev said their session expired and closed the ticket. I cannot picture what actually expired, and I need to decide whether 30 days is the right number to argue for on a payments app.
What expired is one line the browser sends on every request: a session cookie. The server hands it out at login and checks it each time, and the moment it is too old the server stops recognizing the user and answers 401, the code for "I do not know who you are." You can read the whole thing in five minutes. Here is the cookie being set at login, the same cookie working inside its window, and the same cookie after it expired, so you can see exactly where the server stops trusting it.
The tb_session cookie across login, a valid request, and an expired one
At login, the server sets the cookie
11.1
2:
3
4200
5:8329146702592000
A request inside the window
61.1
7:832914670
8
9200
10{"orders":[{"order_id":"o_5512"}]}
The same request after it expired
111.1
12:832914670
13
14401
15{"error":"session_expired"}
Click a step to see the lines it points at.
Mistakes I've seen
Treating "logged out at random" as a frontend bug. The cause is almost always the session cookie expiring or being invalidated server side; the screen is just reacting to a 401.
Assuming the cookie holds the password. It holds an opaque handle like 8f3a2b9c1d4e6f70; the server maps that handle to the user. Nothing sensitive is re-sent on each request, which is the point.
Picking a session length by gut. 30 days is convenient on a personal phone and risky on a shared device; on a payments app that trade deserves a number you can defend, not a default nobody chose.
Confusing an expiry with a forced logout. Both end in 401, but expiry is the clock running out while invalidation is the server actively revoking the session; they are fixed in different places.
Reply with: "So this is the tb_session cookie hitting its Max-Age and the server returning 401 session_expired, not a bug. Max-Age is 2592000, which is 30 days. For a payments app I want to argue that down, what would you set it to?" You read the cookie, named what expired, and turned a vague ticket into a deliberate product decision.
Where a PM meets this
Session length is a product-and-security trade: long sessions are convenient but riskier on shared devices. "Stay logged in" is this decision.
"It logged me out randomly" usually means a session expired or was invalidated; understanding sessions helps you spec that behaviour deliberately.
Hear it in a meeting
"Sessions expire after 30 days unless they log out; is that too long for a payments app?"