Sessions: what happens after sign-in

You change your password after losing a laptop. The laptop is already signed in. Has its access ended? That depends on how the service manages sessions, not just passwords.

session: A mechanism linking later requests to an established interaction or authenticated identity.

A session is a continuing agreement

Authentication checks evidence about an identity. A session lets later requests refer to that earlier event. An opaque session identifier usually points to server-side state; a signed token can carry claims the receiving service validates. Neither design removes the need for authorization on each protected action.

Think of a hotel key: reception checks you in, but the key should open only your room and stop working when its stay ends. Changing your booking password does not magically reprogram a key.

Three cookie controls, three different jobs

Secure limits a cookie to secure transport. HttpOnly prevents ordinary page JavaScript from reading it. SameSite restricts some cross-site sending; its behavior depends on the chosen mode and browser rules. These controls complement each other. HttpOnly does not stop a compromised page from making requests using the session, and SameSite is not a complete substitute for a considered CSRF defense.

Life cycle matters as much as the first login

Renew the session identifier when authentication or privilege changes. Distinguish idle timeout from absolute lifetime: activity may reset an idle clock, but should not extend a session forever. Sensitive changes may need recent authentication.

Logout should invalidate the relevant server session or otherwise prevent continued acceptance. Self-contained tokens can require a revocation strategy, short lifetimes, or additional server checks. A password reset should have an explicit policy for existing sessions. Record creation and revocation events without logging the secret itself.

Turn the hotel analogy into a reviewable contract

Our fictional volunteer portal keeps a separate server session for each browser sign-in. Its agreed policy allows thirty minutes of inactivity and an eight-hour absolute lifetime. These are teaching assumptions, not recommended limits for every service. Changing the payout destination requires authentication within the previous five minutes, plus permission to change that destination.

Recent authentication is evidence about freshness, not a new role. A volunteer who authenticates again still cannot perform an accountant-only action. Conversely, an accountant’s role does not establish that the person recently demonstrated control of their authenticator. The two checks answer different questions.

Follow the boundary beyond the browser

The browser stores a session secret and sends it under the browser’s rules. The application decides whether to accept it. Cookie expiry can help clear the browser’s copy, but the trusted service must enforce its own validity limits. Removing a cookie from one browser does not demonstrate that all other copies or associated credentials became unusable.

If a system issues access and refresh tokens, describe both lifetimes. An access token authorizes its intended protected services under validated claims; a refresh token may obtain replacements. Ending renewal is useful, but an already issued access token may remain acceptable until expiry unless the resource service also applies revocation. A signature validates the token’s integrity and issuer under the verification rules; it does not reveal whether a user just reported a lost device.

PredictThe portal promises that device revocation stops protected actions immediately. Its supplied design revokes refresh tokens, but accepts existing access tokens for another ten minutes. Does it meet the promise?

No. Renewal ends, but the acceptance window remains. The team must either change the design to enforce the promised boundary or explicitly revise the requirement after reviewing the consequences. A short window can be a deliberate tradeoff; calling it immediate revocation would still be inaccurate.

Ask what survives each ending

Logout from this browser, logout from all devices, password reset, and removal from a project need separate definitions. Project removal may revoke one permission while leaving the account’s unrelated work available. A sign-in provider can also have its own session, separate from the application’s session, so “signed out” needs a clear scope.

Review creation, renewal, rejection, and revocation using fictional event records with times and non-secret correlation references. Do not include usable session values in logs or screenshots. Check that an expired or revoked request has no protected effect, and that the user receives a practical route back to permitted work. A clean logout screen is useful evidence of the interface, but not proof of the service’s acceptance policy.

EXPLORE THE CONCEPT

Which access actually ends?

Change one part of the story and examine the remaining session.

Close the tab

Closing a tab does not necessarily invalidate a server session. Persistent cookies and other active devices may retain access.

Revoke the lost device

A device-specific server session can be invalidated while other sessions remain. Verify what the service actually revokes.

Reset the password

The password changes. Existing session access depends on the service’s revocation policy; verify rather than assume.

A simplified learning model. It connects to no systems and uses no real data.

Turn the idea into a decision

When reviewing a design, ask four questions: how is the session created, where is it accepted, when is it renewed, and how does it end? A login screen answers only the first.