Staying Logged In: Sessions and Tokens
Olivia logs into her email once in the morning, then reads, replies, and clicks around for an hour — and not once does the site ask for her password again. Something is quietly remembering that she already proved who she is.
That something is a session — the period of "you're already logged in" that begins when you sign in and ends when you log out or it times out. The session is carried by a small piece of data called a token: a hard-to-guess string the site hands your browser at login, which the browser shows back on every later request.
Think of a festival wristband. You show your ID once at the gate, and in return you get a wristband. After that, you flash the wristband — not your ID — at every stage and food stall all day. The session is your day of access; the token is the wristband that proves you already passed the gate.
Why Stay Logged In at All?
Imagine if every single click re-asked for your password — opening a message, sending a reply, switching folders. The site would be correct about who you are at every step, and completely unusable. Nobody would put up with it.
So instead of re-checking your password constantly, the site checks it once at login and then issues a temporary "she's already proven herself" pass. From then on, the pass speaks for you. That pass is the token, and the convenience it buys is the whole reason sessions exist.
What Is the Token?
When you log in successfully, the server creates a token — a long, random, hard-to-guess string — and sends it to your browser. The browser tucks it away and automatically includes it on every following request to that site.
On its end, the server keeps a note that says "this token belongs to Olivia's logged-in session." Each time a request arrives carrying the token, the server matches it to that note and treats the request as coming from Olivia — no password needed. (Browsers usually store and send the token using a small stored note called a cookie, which Chapter 5 looks at on its own.)
The important part is what the token is not: it is not your password. It is a stand-in that the server can recognize, and one it can throw away at any time without you ever changing your password.
Why Sessions Expire
A session does not last forever. After a stretch of time — or a stretch of doing nothing — the token times out and stops working, and the next request gets sent back to the login page.
This is on purpose. If Olivia signs in on a library computer and walks away forgetting to log out, an open-forever session would leave her account exposed to the next person who sits down. A session that expires is a deliberate balance: convenient enough to stay logged in for a while, safe enough that a forgotten login closes itself eventually.
Back to the wristband: it works for the day, but it is not a lifetime pass. Tomorrow you go back to the gate and show ID again.
Why a Stolen Token Is Dangerous
The convenience has a sharp edge, and the rest of this course keeps running into it. The server treats whoever shows a valid token as the logged-in user. It does not re-check a face or a password — the token is the proof.
So if an attacker gets hold of Olivia's valid token, they are treated as Olivia. They walk straight into her account without ever knowing her password — exactly like someone who finds a dropped festival wristband and flashes it at the gate.
That is why many later attacks hunt for tokens rather than passwords. Stealing the password means still having to log in; stealing a live token means already being inside. And because the token travels with every request, anything that can listen in on that traffic, or sit inside the browser, has a shot at grabbing it — which is what makes protecting data on its journey (the next few chapters) such a big deal.
- "Staying logged in means the site stored my password in my browser." What it stored is a temporary token, not your password. The token can be thrown away or revoked on its own, and your password never has to change.
- "A session lasts forever once I'm in." Sessions expire by design. After enough time or inactivity the token stops working, which is exactly why a site periodically sends you back to the login page.
- "Only my password can let someone into my account." A stolen valid token grants access with no password at all — to the server, holding the token is being logged in.
- "The token is just a copy of my password." It is a separate, random stand-in. It proves you already logged in; it does not reveal the password you used to get it.
- Logging out and letting sessions time out are security actions, not annoyances — each one voids a token so a forgotten or stolen pass can't keep being used.
- It reframes what attackers are after: a live token is often a faster way in than a password, because it skips the login entirely.
- Because the token rides along with every request, it sets up why protecting data in transit — the focus of the chapters ahead — is so important.
Knowledge Check
Olivia logs in once and then reads her email for an hour without re-entering her password. What is keeping her logged in across all those clicks?
- A token her browser shows the server on every request
- Her password being silently re-verified in the background on every single click and page load
- The strength of the password she chose
- The fact that the connection is encrypted
Why do websites issue a session token instead of asking for your password on every single click?
- Typing a password on every click would make the site unusable
- Because a token is much harder to steal than a password, so attackers can never really get hold of one
- Because the token is just a faster copy of the password
- Because a token is designed to keep you logged in forever
Why does a session expire after a while instead of lasting forever?
- So a forgotten login closes itself instead of staying open
- Because storing session tokens takes up server memory and causes the site to slow down for all logged-in users
- Because your password has to be changed every few minutes
- Because the password slowly wears out and stops working
An attacker gets a copy of Olivia's valid session token but never learns her password. Why is that still a serious problem?
- The server treats whoever holds the token as the logged-in user
- It isn't a problem, since only the password can ever grant access
- Because the token quietly tells the attacker what the password is
- Because the attacker has to wait for the token to expire first
You got correct