Sessions and Credential Lifecycle

Authentication becomes stale when a copied cookie, bearer token, or refresh credential outlives its intended session. A session is server-recognized continuity between authentication events; a credential is secret or cryptographic evidence presented to establish or continue that session. Neither is the person, and neither carries permanent permission.

Today you will create, inspect, expire, revoke, replace, and clean up one disposable session record. Missing AUTH-R01 routes back to Day 01 because lifecycle evidence is useless until authentication and authorization are separate.

Northstar needs Alice's compromised session to stop without logging out Bob or changing supplier policy. The result is AUTH-R02: a normal request, expired-session denial, explicit revocation denial, valid replacement control, and scoped cleanup.

The authentication runtime hashes opaque session tokens before lookup. PostgreSQL owns session state and revocation timestamps; the browser owns only an HttpOnly, Secure cookie; the policy service still owns resource authorization.

Store only a hash of the bearer value, bind the record to subject, tenant, creation event, absolute expiry, idle expiry, and revocation version, then rotate after sensitive reauthentication.

CREATE TABLE demo_session (
  session_id text PRIMARY KEY,
  token_hash text UNIQUE NOT NULL,
  subject_id text NOT NULL,
  tenant_id text NOT NULL,
  expires_at timestamptz NOT NULL,
  revoked_at timestamptz
);

PostgreSQL interprets the constraint and persists state; the API hashes the presented token and loads the record; CPU and storage are local proof only. Delete the disposable row after the exercise. This does not prove secure browser deployment, key custody, distributed revocation, or production availability.

Cookies, RFC 6265 defines the browser cookie mechanism, while OAuth token revocation, RFC 7009 defines a revocation endpoint for OAuth tokens. An application session may use different server-owned state, so document which lifecycle is actually being revoked.

The unscored activity holds Alice and the supplier constant while moving the clock past expiry, setting revoked_at, and issuing a replacement session. Bob's session is the unaffected control.

The scored check supplies all timestamps and one unknown: is this session currently acceptable? Treating a signed or stored token as permanently current triggers feedback that compares issuance with current expiry/revocation state. Declined candidates include password-strength scoring, real credentials, and multi-device incident response.

Seal the session ID, token hash prefix, subject, tenant, issue/expiry/revocation times, observed denials, replacement control, cleanup result, environment, timestamp, and run ID as AUTH-R02. Days 03 and 04 consume it when separating delegated authorization from federated identity.