Session Store

What you'll walk away with

Explain the core ideas behind Session Store
Run the sample Redis command or code and verify its output
Apply the technique correctly to the Tutorial Platform and production scenarios

Build the mental model

In a server-side session, the browser stores only a random opaque ID while Redis stores user, role, and CSRF state with a TTL. Session IDs must be cryptographically random; cookies need Secure, HttpOnly, and SameSite attributes; rotate IDs after privilege changes.

Connect it to a real scenario

After login, create `session:<hashed-id>` as a hash with a 30-minute TTL. Refresh sliding expiry on authenticated requests without exceeding an absolute lifetime. Delete the key on logout and use a per-user session index to revoke all sessions after a password reset.

Use opaque random IDs
Every session key needs a TTL
Revoke or rotate on logout and role changes

Try the working example

shell

HSET session:sha256_abc userId 42 role student createdAt 1787875200
EXPIRE session:sha256_abc 1800
HGETALL session:sha256_abc
SADD user:42:sessions session:sha256_abc
DEL session:sha256_abc
SREM user:42:sessions session:sha256_abc

You should see

You create a 30-minute session and a per-user revocation index.

5-minute try-it

Write pseudocode for a seven-day absolute lifetime plus a 30-minute idle timeout.

One important caution

Raw session tokens in Redis keys or logs can turn an observability leak into account takeover; hash tokens before storage.

Redis — Hashes — Redis

Easy traps

Raw session tokens in Redis keys or logs can turn an observability leak into account takeover; hash tokens before storage.
Validate sample commands on a local or test instance with recoverable data before applying them to production Redis.

Exercise

Write pseudocode for a seven-day absolute lifetime plus a 30-minute idle timeout.

You'll know it worked when: You create a 30-minute session and a per-user revocation index.