lesson_14: how login state survives between requests
01 — why this lab matters
session lab teaches how login state survives between separate requests.
a web application does not keep a magical live wire between the browser and the server.
most of the time, the client sends one request, the server returns one response, and the connection ends or becomes part of a lower-level connection pool.
the next request must carry enough state for the server to decide what it means.
that is the heart of session design.
this lab simulates that process with a fake browser cookie jar, a fake server session store, a login flow, a protected /me request, logout behavior, cookie flags, session rotation, and a copied-token test.
no real network traffic is sent.
the point is to make the session model visible.
micro meaning
• request = one client message
• response = one server answer
• cookie jar = browser-side cookie memory
• session store = server-side memory
• login state = server decision based on state
• session = continuity across requests
02 — a session begins as absence
before login, the browser usually has no session cookie for the application.
the first visit may look like this:
get /
there may be no cookie header.
the server sees a request, but it has no remembered identity for that browser context.
so the server treats the user as anonymous.
that is why the lab begins with a visit step.
it shows the starting point: no cookie, no server session, anonymous result.
micro meaning
• anonymous request has no recognized session state
• no cookie means the server has no session pointer
• first visit can still return a page
• session starts only when state is created and repeated
03 — login creates state
a login request is not only a username and password check.
if login succeeds, the server usually creates some form of state.
in a classic server-side session model, the server creates a random session id and stores identity on the server.
the response sends a cookie back to the browser:
set-cookie: session_id=abc123; path=/; httponly; secure; samesite=lax
the browser stores that cookie.
later, the browser sends it back automatically when the cookie rules match.
micro meaning
• login validates credentials
• set-cookie tells the browser to remember state
• session_id is usually an opaque pointer
• server store gives the pointer meaning
• later requests carry the cookie back
04 — server-side session model
in a server-side session model, the browser usually stores only a session identifier.
example browser cookie:
session_id=sid_1001_ab12cd
example server store:
sid_1001_ab12cd → user=marko@example.test, authenticated=true
the cookie value does not need to contain the user profile.
it only needs to identify a server-side record.
that makes the cookie a pointer.
the server decides what the pointer means.
if the server deletes the session record, the same cookie becomes useless.
micro meaning
• server-side session stores meaning on the server
• cookie carries a pointer
• session id should be opaque and hard to guess
• server lookup turns id into identity
• deleted session makes old cookie stale
05 — where sessions live in backend applications
in a real backend application, session logic usually lives in application code or middleware.
examples:
• express-session in node / express
• django sessions in django
• flask session or server-side flask session extensions
• rails session middleware
• spring security session management
• laravel session handling
that backend layer decides how session state is created, stored, refreshed, expired, and destroyed.
in simple apps, sessions may live in process memory.
in production systems, sessions often move to shared storage such as:
• redis
• database table
• memcached
• distributed cache
• signed encrypted cookie
• identity provider token flow
this matters because backend architecture changes session behavior.
if one backend instance stores the session only in memory, another backend instance may not know about it.
that is why production systems often need shared session storage, sticky sessions, or stateless token models.
micro meaning
• backend app creates and validates session state
• middleware often handles session mechanics
• in-memory session can break across multiple servers
• shared store lets many backend instances read the same session
• architecture changes how sessions survive requests
06 — backend sessions in distributed systems
backend sessions become more complicated when an application runs on multiple servers.
one request may hit server a.
the next request may hit server b.
if session state exists only inside server a memory, server b may not recognize the user.
production systems solve this in several ways:
• shared session store
• redis-backed sessions
• database-backed sessions
• load balancer sticky sessions
• stateless signed tokens
• central identity provider
sticky sessions keep the same user routed to the same backend instance.
shared session stores let any backend instance look up the same session id.
stateless tokens reduce lookup, but make logout and revocation harder.
micro meaning
• load balancer can route requests to different servers
• sticky session keeps a user tied to one backend instance
• shared store makes sessions available across instances
• stateless token reduces server lookup
• distributed backend makes session design an architecture problem
07 — browser sessions and api sessions are related but not identical
not every session comes from a browser page.
backend systems also handle sessions and auth state for:
• mobile apps
• desktop clients
• single-page apps
• server-to-server integrations
• api clients
• cli tools
• webhooks
browser apps often rely on cookies, httponly flags, samesite rules, and cors boundaries.
api clients often use bearer tokens, api keys, oauth access tokens, refresh tokens, or signed requests.
mobile apps may store tokens in secure storage and attach them as authorization headers.
server-to-server clients may use m2m oauth, signed jwt assertions, mutual tls, or api keys.
so the broad session question is not only:
what cookie does the browser send?
it is also:
what state proves continuity for this client type?
micro meaning
• browser session often uses cookies
• api session often uses bearer tokens
• mobile session often uses secure token storage
• server-to-server auth may use oauth, mtls, or signed assertions
• client type changes how session state travels
08 — token / jwt-style model
the lab also includes a token / jwt-style mode.
this mode teaches a different pattern.
instead of storing all session meaning in a server-side session store, a signed token can carry claims.
example claims may include:
• subject
• user id
• role
• expiration
• issuer
• audience
a real jwt is signed so the server can verify that the claims were not changed.
this lab does not implement real cryptography.
it uses a simplified token-style demo to teach the model.
micro meaning
• server-side session uses lookup
• token-style session carries claims
• signature protects token integrity
• claims describe identity or permissions
• demo token is not real cryptography
09 — cookie is transport state
a cookie is not automatically the whole session.
a cookie is browser-managed state that can be sent with later requests.
in a server-side session model, the cookie may contain only:
session_id=abc123
the real meaning may live in the server store.
in a token-style model, the cookie may contain a token that carries claims.
both patterns use cookies as a transport mechanism.
the difference is where meaning lives.
micro meaning
• cookie carries state between requests
• server-side session keeps meaning on server
• token-style model carries meaning in token claims
• browser sends cookie when rules match
• server decides whether cookie is accepted
10 — request /me tests the session
the /me request is a common way to test login state.
it asks the server:
who am i in this current request context?
if no cookie or token is sent, the server returns anonymous or unauthorized.
if a valid server-side session id is sent, the server can look it up.
if a valid signed token is sent, the server can verify and read claims.
in the lab, request /me shows the relationship between browser cookie, server logic, and server response.
micro meaning
• /me means “identify this request”
• no cookie usually means anonymous
• valid session id maps to server state
• valid token maps to verified claims
• response shows what the server believes
11 — logout has two sides
logout can mean more than deleting a browser cookie.
there are two sides:
• browser-side cleanup
• server-side invalidation
browser-side cleanup removes the cookie from the current browser.
server-side invalidation removes the session record from the server store.
for server-side sessions, both matter.
if logout only deletes the browser cookie but leaves the server session alive, another copy of the same session id may still work.
that is why the lab has a switch for server invalidates on logout.
micro meaning
• delete cookie removes local browser state
• invalidate session removes server state
• logout should usually do both
• copied session id may survive weak logout
• server invalidation kills the session everywhere
12 — copy token test explains stolen state
the copy token test simulates a second browser or attacker holding a copied session value.
this is not an attack tool.
it is a teaching model.
it asks:
if someone already copied the session id or token, what happens after logout?
in server-side session mode, if the server invalidated the session, the copied value should fail.
if the server did not invalidate the session, the copied value may still work.
in token-style mode, the copied token may remain valid until expiry unless the server uses a denylist, revocation strategy, or short-lived tokens.
micro meaning
• copied token tests replay risk
• server invalidation stops copied session ids
• jwt-style token may survive logout until expiry
• denylist can revoke token-style access
• short expiry reduces exposure window
13 — session rotation reduces fixation risk
the lab includes rotate after login.
session rotation means issuing a new session id after authentication.
this matters because a session id used before login should not necessarily remain the same after login.
if an attacker can force or predict a pre-login session id, and the application keeps that same id after login, the attacker may benefit from session fixation.
rotation reduces that risk by replacing the old id with a new authenticated session id.
micro meaning
• rotation changes session id after login
• pre-login id should not become trusted forever
• session fixation abuses reused session ids
• new id reduces fixation risk
• login is a good time to rotate session state
14 — httponly protects cookie readability
httponly is a cookie flag that blocks javascript from reading the cookie through document.cookie.
the browser can still send the cookie with matching requests.
that distinction matters.
httponly does not mean the cookie is unused.
it means page scripts cannot directly read it.
this is important because if an attacker injects script into a page, httponly can reduce the chance that the session cookie is stolen directly through javascript.
micro meaning
• httponly hides cookie from javascript
• browser can still send the cookie
• document.cookie will not show httponly cookies
• xss risk is reduced but not erased
• httponly is a cookie confidentiality control
15 — secure restricts cookie transport
secure is a cookie flag that tells the browser to send the cookie only over https.
for real authentication cookies, secure should normally be on.
without secure, a cookie may be allowed over plaintext http in situations where that still exists.
that creates unnecessary exposure.
the lab shows secure as a switch because cookie transport rules are part of session safety.
micro meaning
• secure restricts cookie sending to https
• https protects transport with tls
• auth cookies should normally use secure
• transport exposure can leak session state
• cookie flags change browser behavior
16 — samesite controls cross-site sending
samesite controls when cookies are sent in cross-site situations.
the common values are:
• lax
• strict
• none
strict is the most restrictive.
lax allows some top-level navigations while reducing many cross-site risks.
none allows cross-site sending, but modern browsers generally require secure with samesite=none.
samesite is important for reducing some cross-site request forgery patterns.
micro meaning
• samesite controls cross-site cookie sending
• strict sends less often cross-site
• lax balances usability and protection
• none allows cross-site use
• samesite=none usually requires secure
17 — browser cookie jar vs server store
the lab separates browser cookie jar and server session store.
that separation is the lesson.
the browser can hold a cookie.
the server can hold a session record.
those two can fall out of sync.
examples:
• browser has no cookie, server has no session
• browser has cookie, server has matching session
• browser has cookie, server session was deleted
• browser deleted cookie, copied token still exists elsewhere
• token-style model has no classic server session store
micro meaning
• cookie jar is client-side state
• session store is server-side state
• matching id creates continuity
• stale cookie no longer authenticates
• state location changes logout behavior
18 — jwt-style logout needs strategy
in token-style systems, logout is different.
if the token is self-contained and valid until expiration, deleting it from one browser does not erase copies that already exist elsewhere.
real systems often manage this with:
• short access-token lifetime
• refresh token rotation
• server-side denylist
• token versioning
• revocation checks
• session binding
• risk-based invalidation
the lab simplifies this, but the principle is real.
token logout needs a strategy.
micro meaning
• self-contained token can outlive local deletion
• expiry limits token lifetime
• denylist can reject revoked tokens
• refresh rotation reduces replay risk
• logout semantics depend on token architecture
19 — simulation is useful because it removes noise
this lab does not send real network traffic.
that is intentional.
a real application has many distractions: frameworks, browser devtools, backend code, redirects, proxies, real auth, real cookies, and real security policies.
the simulator reduces the model to the core pieces:
• browser request
• server logic
• server response
• browser cookie jar
• server session store
• cookie flags
• logout behavior
• copied token behavior
that makes the lifecycle easier to see.
micro meaning
• simulation isolates the concept
• no traffic means no real target is touched
• fake server shows logic
• fake cookie jar shows browser state
• simplified model teaches before real systems add complexity
20 — what this lab makes visible
this lab makes the session lifecycle observable.
it surfaces:
• visit
• login
• request /me
• logout
• copy token test
• session type
• cookie flags
• browser cookie jar
• server session store
• auth result
• request text
• server logic
• response text
• warnings
the value is not that the tool performs authentication.
the value is that the tool shows the moving parts that real authentication depends on.
micro meaning
• request panel shows what the client sends
• server logic shows interpretation
• response panel shows what comes back
• cookie jar shows browser state
• session store shows server state
• warnings show unsafe configuration
21 — what the user should learn
the user should leave understanding that login state is not a single thing.
it is a coordinated model between client, server, cookie rules, token rules, and logout behavior.
the important questions are:
• where is identity stored?
• what does the browser send back?
• what does the server look up or verify?
• what happens on logout?
• can a copied value still work?
• which cookie flags protect the session?
• does the system rotate session ids?
a good session model should make state location clear.
micro meaning
• client state and server state are different
• cookie is not automatically identity
• token is not automatically safe
• logout must match architecture
• security flags change browser behavior
22 — final line
login creates state.
cookies carry state forward.
server-side sessions store meaning on the server.
tokens can carry claims inside the value.
logout is only safe when it kills the right state.
good session design begins with three questions:
• where does the session meaning live?
• who can copy or read the state?
• what makes the state stop working?