Session-Based Auth
A member signs in to the BookNook website once and browses for an hour without typing their password again. The site must recognise every later request as theirs. The classic way is a session: the server remembers the sign-in, and the browser carries a claim ticket.
The rule
The server keeps the memory; the browser keeps only a ticket.
The flow:
- The member posts their email and password once.
- The server checks them, creates a session record in its store (member id, created time, expiry), and generates a long random session id.
- The server sends the id in a cookie.
- The browser attaches the cookie to every later request. The server looks up the id, finds the session, and knows who is calling.
POST /v1/sessions HTTP/1.1
Content-Type: application/json
{"email": "asha@example.com", "password": "..."}
HTTP/1.1 201 Created
Set-Cookie: sid=kT7x2QpZr9WmVb4LcN8sEa1Y; Secure; HttpOnly; SameSite=Lax; Path=/The state lives in the server's session store, a database or a shared cache. Strict REST prefers that servers keep no per-client session state; sessions knowingly bend that rule in exchange for simple sign-out.
Strengths:
- Instant revocation: delete the session record and the ticket is worthless. "Sign out everywhere" is one query.
- Nothing sensitive in the browser: the id is random and means nothing on its own.
Costs:
- A lookup on every request, and every server in the pool must reach the same store.
- Browser-centred: cookies suit websites; mobile apps and other servers usually prefer tokens in a header.
- CSRF risk: because browsers send cookies automatically, another site can trigger requests carrying them.
SameSitecookies and anti-CSRF tokens defend against this.
Security habits: make the id long and random, issue a new id at sign-in so an attacker cannot plant a known one beforehand, expire idle sessions, and delete the record on sign-out.
The shortcut
Trace one request and ask: where does the answer to "who is this?" live? In a session design, the cookie is only a pointer; the answer lives on the server.
Request arrives
GET /v1/members/me/loanswithCookie: sid=kT7x....
Drills
Answer fast — trust the rule.
In session-based auth, what does the browser store?
A member reports a stolen laptop. How does BookNook end that session immediately?
Why should the server issue a new session id when a member signs in?
BookNook runs five API servers, and any of them may receive a member's next request. What must be true for sessions to work?
Remember
- The server keeps the memory; the browser keeps only a ticket.
- Shortcut: ask where "who is this?" is answered — in a session, on the server.
- Trap: forgetting CSRF defences, reusing the pre-login session id, and per-server session memory.