Session

Before expiry · 14:29

1. Context. The same browser still holds the cookie for SS61 at 14:29 UTC. It asks CaseDesk to read C52. The service, not the cookie’s presence, decides whether this session remains valid. Completed authentication at 14:00 UTC created a fresh unpredictable opaque identifier in a Secure, HttpOnly, SameSite=Lax host-only cookie. SS61 is its safe record reference. The server maps it to U52 and enforces an exclusive 14:30 absolute expiry. These are independent test requests, not playback advancing a real clock. C52 belongs to U52; the policy permits own-case reads. The chosen lifetime is illustrative.
2. Request. The browser sends the request and its session cookie over HTTPS. CaseDesk shows receipt after arrival. The browser has received neither case content nor a sign-in response yet. The cookie accompanies the protected request; it is not a new login or separate actor. A browser may retain a cookie after server-side expiry. Holding it does not establish service acceptance. The synthetic figure sends no real request or credential.
3. Check. CaseDesk checks SS61 against its own session record: it is valid before 14:30 UTC and maps to U52. The separate own-case policy allows reading C52; the response is still at the service. A session lookup associates the protected identifier with U52 and verifies its current server-side validity. The service also checks C52’s owner and current read permission. These are separate checks: a valid session would not authorize another account’s private case. No password or authenticator is submitted in this request. Both tests concern an unchanged account and case; only their evaluated time differs.
4. Response. The allowed response returns a C52 copy to the browser. Its result appears after arrival. CaseDesk retains the original; the session connects this request to U52 without repeating the earlier authentication. The returned case copy arrives only after the response travels to the browser. This confirms one permitted read under the snapshot assumptions, not every action or a business-task completion. Protecting and invalidating session credentials remains necessary even with strong earlier authentication; a stolen accepted bearer-style session can be replayed without the original authenticator.

At expiry · 14:30

1. Context. The same browser still holds the cookie for SS61 at 14:30 UTC. It asks CaseDesk to read C52. The service, not the cookie’s presence, decides whether this session remains valid. Completed authentication at 14:00 UTC created a fresh unpredictable opaque identifier in a Secure, HttpOnly, SameSite=Lax host-only cookie. SS61 is its safe record reference. The server maps it to U52 and enforces an exclusive 14:30 absolute expiry. These are independent test requests, not playback advancing a real clock. C52 belongs to U52; the policy permits own-case reads. The chosen lifetime is illustrative.
2. Request. The browser sends the request and its session cookie over HTTPS. CaseDesk shows receipt after arrival. The browser has received neither case content nor a sign-in response yet. The cookie accompanies the protected request; it is not a new login or separate actor. A browser may retain a cookie after server-side expiry. Holding it does not establish service acceptance. The synthetic figure sends no real request or credential.
3. Check. CaseDesk enforces the 14:30 UTC expiry. SS61 is now expired, so the service cannot use its old authenticated context and does not reach the case-permission check. At exactly 14:30 UTC the service rejects the old session under its own absolute-expiry policy. It does not treat the still-present cookie as a new authentication, and does not authorize or release C52. This refusal leaves the assumed working HTTPS transport, valid request syntax, account existence, and original case intact. Client-side cookie deletion is not the enforcement mechanism.
4. Response. The sign-in-required response returns to the browser. After arrival, it sees that C52 was not delivered. The old cookie remains held; a fresh authentication and session would be a separate process. The response here is an authored sign-in prompt rather than case data; no particular HTTP status, redirect, or automatic reauthentication sequence is specified. It does not establish that every application session was revoked, the cookie disappeared, or an account was disabled. A replacement authenticated session would require its own completed flow.

SS61 is a record reference, not a usable cookie value. This shows one server-side absolute expiry, not every session format, lifetime, logout, revocation, or fresh sign-in flow.

Flow references: OWASP - server-side session validity and cookie protection · OWASP - per-request application permission