Cookie value is not the session.
Cookie value is usually a pointer to server-side session state.

session_id -> authenticated subject + auth time + expiry + device + tenant + assurance + metadata

If Redis loses session, user logs in again. No big deal.

Can we kill all sessions for one account?
Can we kill all sessions for one tenant?
Can we kill one device session?
Can we rotate session id after login?
Can we expire idle sessions reliably?
Can we detect concurrent session abuse?
Can we survive Redis/node restart?
Can we avoid stale authorization after role change?
Can we audit session creation and destruction?

Browser credential transport  : cookie carrying session id
Server-side continuity state : session record in store

The cookie is only a lookup key. The authority remains server-side.

A session id must be unguessable, scoped, rotatable, expirable, and revocable.

Session store reads happen on almost every authenticated request.

session_id
account_id
subject_id
created_at
last_seen_at
expires_at
idle_expires_at
status

session_id
account_id
subject_id
tenant_id
active_tenant_membership_id
authentication_time
authentication_methods
assurance_level
mfa_satisfied_at
credential_version_at_login
authority_version_at_login
session_version
created_at
last_seen_at
absolute_expires_at
idle_expires_at
revoked_at
revoked_reason
ip_first_seen
ip_last_seen
user_agent_hash
device_id
risk_score_at_login
csrf_secret_or_reference
security_context_snapshot

Store enough state to enforce security invariants.
Do not turn session into arbitrary user profile cache.

public record AuthSession(
    String sessionId,
    UUID accountId,
    UUID subjectId,
    UUID tenantId,
    Instant authenticationTime,
    Set<String> authenticationMethods,
    int assuranceLevel,
    long credentialVersion,
    long authorityVersion,
    Instant createdAt,
    Instant lastSeenAt,
    Instant idleExpiresAt,
    Instant absoluteExpiresAt,
    SessionStatus status
) {}

enum SessionStatus {
    ACTIVE,
    REVOKED,
    EXPIRED
}

public interface SessionStore {
    AuthSession create(CreateSessionCommand command);
    Optional<AuthSession> findActive(String sessionId, Instant now);
    AuthSession rotate(String oldSessionId, RotationReason reason);
    void touch(String sessionId, Instant now);
    void revoke(String sessionId, RevocationReason reason, Instant now);
    void revokeAllForAccount(UUID accountId, RevocationReason reason, Instant now);
    List<AuthSession> findActiveByAccount(UUID accountId);
}

Browser SID -> Tomcat/Jetty/Undertow memory

single-instance internal tool
low-risk app
non-critical admin prototype
local development

multi-node production
regulated workflow
high availability system
multi-region system
forced logout requirement

Sticky session can reduce pain, but it does not remove distributed session semantics.

CREATE TABLE auth_session (
    session_id_hash      bytea PRIMARY KEY,
    account_id           uuid NOT NULL,
    subject_id           uuid NOT NULL,
    tenant_id            uuid,
    authentication_time  timestamptz NOT NULL,
    assurance_level      integer NOT NULL,
    credential_version   bigint NOT NULL,
    authority_version    bigint NOT NULL,
    created_at           timestamptz NOT NULL,
    last_seen_at         timestamptz NOT NULL,
    idle_expires_at      timestamptz NOT NULL,
    absolute_expires_at  timestamptz NOT NULL,
    revoked_at           timestamptz,
    revoked_reason       text,
    user_agent_hash      bytea,
    ip_last_seen         inet,
    metadata             jsonb NOT NULL DEFAULT '{}'::jsonb
);

CREATE INDEX idx_auth_session_account_active
ON auth_session (account_id, absolute_expires_at)
WHERE revoked_at IS NULL;

CREATE INDEX idx_auth_session_tenant_active
ON auth_session (tenant_id, absolute_expires_at)
WHERE revoked_at IS NULL;

cookie SID = random 256-bit value
store key  = HMAC-SHA-256(server_secret, SID)

public final class SessionIdHasher {
    private final MacPrototype macPrototype;

    public byte[] hash(String rawSessionId) {
        Mac mac = macPrototype.newMac();
        return mac.doFinal(rawSessionId.getBytes(StandardCharsets.US_ASCII));
    }
}

Do not update last_seen_at on every request.
Update only if last_seen_at older than threshold, e.g. 60 seconds.

UPDATE auth_session
SET last_seen_at = now(),
    idle_expires_at = now() + interval '30 minutes'
WHERE session_id_hash = :hash
  AND revoked_at IS NULL
  AND idle_expires_at > now()
  AND absolute_expires_at > now()
  AND last_seen_at < now() - interval '60 seconds';

sess:{sessionIdHash} -> hash/json session payload, TTL = absolute expiry
acct:{accountId}:sessions -> set of sessionIdHash
user_session:{sessionIdHash}:csrf -> csrf secret/reference

HSET sess:{hash} account_id ... subject_id ... expires_at ...
EXPIRE sess:{hash} 28800
SADD acct:{accountId}:sessions {hash}
EXPIRE acct:{accountId}:sessions 28800

DEL sess:{hash}
SREM acct:{accountId}:sessions {hash}
PUBLISH auth-session-revoked {hash}

HSET sess:{hash} status REVOKED revoked_at ... revoked_reason ...
EXPIRE sess:{hash} 600

EXPIRE session absolute_seconds_remaining

On request:
  load session
  if now > idle_expires_at -> reject
  if now - last_seen_at > touch_threshold -> update last_seen_at + idle_expires_at + expire

public Optional<AuthSession> loadAndMaybeTouch(String sid, Instant now) {
    AuthSession session = redisSessionRepository.find(sid).orElse(null);
    if (session == null) return Optional.empty();

    if (session.revoked() || session.idleExpiresAt().isBefore(now) || session.absoluteExpiresAt().isBefore(now)) {
        redisSessionRepository.delete(sid);
        return Optional.empty();
    }

    if (session.lastSeenAt().isBefore(now.minusSeconds(60))) {
        redisSessionRepository.touch(sid, now, now.plus(Duration.ofMinutes(30)));
    }

    return Optional.of(session);
}

HttpSession API remains familiar.
Storage moves out of servlet container.
SessionRepository becomes the persistence abstraction.

<dependency>
    <groupId>org.springframework.session</groupId>
    <artifactId>spring-session-data-redis</artifactId>
</dependency>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

@Configuration
@EnableRedisHttpSession(
    maxInactiveIntervalInSeconds = 1800,
    redisNamespace = "auth:session"
)
public class SessionConfig {
}

spring.session.store-type=redis
spring.data.redis.host=redis
spring.data.redis.port=6379
server.servlet.session.cookie.http-only=true
server.servlet.session.cookie.secure=true
server.servlet.session.cookie.same-site=lax

RedisSessionRepository       = simple session storage
RedisIndexedSessionRepository = indexed sessions, useful for querying sessions by principal

Do not enable indexed sessions casually. Enable it because you need account/device/concurrent-session operations.

find session by session_id

find all sessions for account_id
find all sessions for principal_name
find all sessions for tenant_id
find all sessions for device_id

sess:{sidHash}                      -> session payload
idx:account:{accountId}:sessions    -> set sidHash
idx:tenant:{tenantId}:sessions      -> set sidHash
idx:device:{deviceId}:sessions      -> set sidHash

When session expires naturally by TTL, secondary indexes may still contain dead session ids.

ZADD idx:account:{accountId}:sessions <absolute_expiry_epoch> <sidHash>
ZRANGEBYSCORE idx:account:{accountId}:sessions -inf now -> expired refs
ZREMRANGEBYSCORE idx:account:{accountId}:sessions -inf now

Anonymous SID stays same after login.

Anonymous session id -> login succeeds -> create/rotate authenticated session id

Any transition from unauthenticated to authenticated must change the session id.

public enum RevocationReason {
    USER_LOGOUT,
    LOGOUT_ALL_DEVICES,
    PASSWORD_CHANGED,
    ACCOUNT_DISABLED,
    TENANT_SUSPENDED,
    ADMIN_FORCED,
    INCIDENT_RESPONSE,
    SESSION_ROTATED,
    EXPIRED
}

Logout must invalidate server-side session and clear client-side cookie.

Session deleted but cookie remains -> next request gets unauthenticated, okay but noisy.

Cookie deleted but server session remains -> stolen cookie may still work.

Delete/revoke session store record + Set-Cookie expired with identical Path/Domain/SameSite/Secure context.

Allow unlimited sessions.
Allow max 5 active sessions per account.
Allow max 1 active admin session.
Allow max 1 active session per regulated operator per tenant.
Allow many sessions but show device management UI.

public AuthSession createSession(CreateSessionCommand command) {
    List<AuthSession> active = sessionStore.findActiveByAccount(command.accountId());

    if (command.policy().maxSessions().isPresent()
            && active.size() >= command.policy().maxSessions().getAsInt()) {
        AuthSession victim = selectVictim(active);
        sessionStore.revoke(victim.sessionId(), RevocationReason.CONCURRENT_LIMIT, clock.instant());
    }

    return sessionStore.create(command);
}

Admin removes user's role, but user's old session still contains old authority.

ALTER TABLE account ADD COLUMN authority_version bigint NOT NULL DEFAULT 1;
ALTER TABLE account ADD COLUMN credential_version bigint NOT NULL DEFAULT 1;

session.authority_version_at_login
session.credential_version_at_login

if (session.authorityVersion() < account.currentAuthorityVersion()) {
    sessionStore.revoke(session.sessionId(), RevocationReason.AUTHORITY_CHANGED, now);
    throw new AuthenticationCredentialsNotFoundException("Session no longer valid");
}

Checking DB account version on every request is expensive.

Store entire UserDetails object graph in session.

{
  "v": 3,
  "accountId": "...",
  "subjectId": "...",
  "tenantId": "...",
  "authTime": "2026-07-03T04:00:00Z",
  "amr": ["pwd", "totp"],
  "aal": 2,
  "credentialVersion": 17,
  "authorityVersion": 42,
  "createdAt": "...",
  "lastSeenAt": "...",
  "idleExpiresAt": "...",
  "absoluteExpiresAt": "..."
}

v = session payload schema version

switch (payload.version()) {
    case 1 -> migrateV1(payload);
    case 2 -> migrateV2(payload);
    case 3 -> parseV3(payload);
    default -> rejectAndForceLogin();
}

Fail closed or fail open when session store is unavailable?

Fail closed.

If session cannot be validated, request is unauthenticated.

Redis timeout -> let request continue as authenticated

@Transactional
public Order submitOrder(...) {
    sessionStore.touch(sessionId); // inside large order transaction
    ...
}

Authenticate before business transaction.
Do session touch separately or asynchronously with bounded semantics.

Redis = active session hot path
PostgreSQL = durable session event/audit history

Active session validity comes from Redis.
Historical evidence comes from audit store.

Pod dies -> sessions on that pod die.

Pod dies -> session survives if store survives.

1. Login as user.
2. Start multi-step form.
3. Roll deployment.
4. Continue action.
5. Verify session remains valid or fails predictably.
6. Verify no privilege drift or partial-auth state loss.

Session store persists enough data to reconstruct SecurityContext.
SecurityContextHolder exposes authentication for current request/thread.

Session state may survive requests.
Thread-local SecurityContext must not.

SecurityContext not cleared -> authentication leak across reused container threads.

public final class SessionAuthenticationFilter implements Filter {
    private final SessionStore sessionStore;
    private final Clock clock;

    @Override
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
            throws IOException, ServletException {

        HttpServletRequest request = (HttpServletRequest) req;
        HttpServletResponse response = (HttpServletResponse) res;

        try {
            Optional<String> sid = readSessionCookie(request);
            if (sid.isPresent()) {
                sessionStore.findActive(sid.get(), clock.instant())
                    .ifPresent(session -> {
                        AuthPrincipal principal = AuthPrincipal.from(session);
                        request.setAttribute("auth.principal", principal);
                    });
            }

            chain.doFilter(request, response);
        } finally {
            // If using ThreadLocal custom context, clear it here.
            AuthContext.clear();
        }
    }
}

request is anonymous

create new session
then delete old session

old session may still be valid briefly

transaction / Lua script / compare-and-swap operation

public interface SessionStore {
    RotationResult rotateSession(
        String oldSessionId,
        CreateSessionCommand newSession,
        RotationReason reason,
        Instant now
    );
}

public sealed interface RotationResult {
    record Rotated(AuthSession newSession) implements RotationResult {}
    record OldSessionNotFound() implements RotationResult {}
    record OldSessionExpired() implements RotationResult {}
}

-- KEYS[1] = old session key
-- KEYS[2] = new session key
-- ARGV[1] = new payload
-- ARGV[2] = ttl seconds

if redis.call('EXISTS', KEYS[1]) == 0 then
  return 0
end

redis.call('DEL', KEYS[1])
redis.call('SET', KEYS[2], ARGV[1], 'EX', ARGV[2])
return 1

Idle timeout     = expires after inactivity
Absolute timeout = expires after max lifetime regardless of activity

A continuously active stolen session may live forever.

A forgotten browser session stays usable until absolute expiry.

boolean active = session.status() == ACTIVE
    && now.isBefore(session.idleExpiresAt())
    && now.isBefore(session.absoluteExpiresAt());

public final class SessionIdGenerator {
    private final SecureRandom secureRandom = new SecureRandom();

    public String generate() {
        byte[] bytes = new byte[32]; // 256 bits
        secureRandom.nextBytes(bytes);
        return Base64.getUrlEncoder().withoutPadding().encodeToString(bytes);
    }
}

String sid = accountId + ":" + System.currentTimeMillis();

String sid = UUID.randomUUID().toString();

@Bean
SecurityFilterChain security(HttpSecurity http) throws Exception {
    return http
        .logout(logout -> logout
            .logoutUrl("/logout")
            .invalidateHttpSession(true)
            .clearAuthentication(true)
            .deleteCookies("SID")
            .logoutSuccessHandler((request, response, authentication) -> {
                response.setStatus(HttpServletResponse.SC_NO_CONTENT);
            })
        )
        .build();
}

public void logout(HttpServletRequest request, HttpServletResponse response) {
    readSessionCookie(request).ifPresent(sid ->
        sessionStore.revoke(sid, RevocationReason.USER_LOGOUT, clock.instant())
    );

    Cookie cookie = new Cookie("SID", "");
    cookie.setHttpOnly(true);
    cookie.setSecure(true);
    cookie.setPath("/");
    cookie.setMaxAge(0);
    response.addCookie(cookie);
}

Cookie deletion must match name, path, and domain used during creation.

SESSION_CREATED
SESSION_ROTATED
SESSION_REVOKED
SESSION_EXPIRED
SESSION_LOOKUP_FAILED
SESSION_STORE_UNAVAILABLE
SESSION_AUTHORITY_VERSION_MISMATCH
SESSION_CREDENTIAL_VERSION_MISMATCH

String sidFingerprint = hex(hmacSha256(logKey, rawSid)).substring(0, 16);

1. Start app instance A and B sharing Redis.
2. Login through A.
3. Access through B with same cookie.
4. Logout through B.
5. Access through A must fail.

Session id must change after login.
Session id must change after MFA.
Server must reject old session after rotation.
Session cookie must be HttpOnly/Secure/SameSite.
No raw session id in logs.

If session revocation and device visibility matter, design indexes from day one.
If scale and latency matter, keep hot path in Redis.
If audit matters, emit durable session events.
If simplicity matters, use Spring Session before building custom plumbing.

Put entire user profile, permissions, preferences, and business context in session.

Store identity continuity. Fetch/cache business data separately.

Logout just clears cookie.

Stolen cookie remains valid.

Anonymous SID becomes authenticated SID.

Session fixation.

maxmemory-policy allkeys-lru

Random logout and unpredictable auth behavior.

GET /api Cookie: SID=abc...

Log leak becomes session takeover.

[ ] Session id is cryptographically random.
[ ] Session id is rotated after login.
[ ] Session id is rotated after MFA/step-up.
[ ] Session id is never stored plaintext in durable DB.
[ ] Cookie uses Secure and HttpOnly.
[ ] SameSite policy is explicit.
[ ] Logout revokes server-side session.
[ ] Logout clears browser cookie correctly.
[ ] Idle timeout is enforced.
[ ] Absolute timeout is enforced.
[ ] Session payload is versioned.
[ ] Session payload is small and explicit.
[ ] Session store fails closed.
[ ] Session store latency is monitored.
[ ] Session revocation is observable.
[ ] Account-wide logout exists if required.
[ ] Tenant-wide purge exists if required.
[ ] Redis/DB failure behavior is tested.
[ ] No raw session id appears in logs/traces.
[ ] Authorization version drift is handled.
[ ] Deployment does not silently corrupt sessions.

com.example.auth.session
  AuthSession.java
  SessionStatus.java
  SessionStore.java
  SessionIdGenerator.java
  SessionIdHasher.java
  SessionCookieWriter.java
  RedisSessionStore.java
  JdbcSessionAuditWriter.java
  SessionAuthenticationFilter.java
  SessionRevocationService.java
  SessionPolicy.java

Controller does not know Redis.
Business service does not parse cookie.
SessionStore does not decide authorization policy.
Authentication filter builds request identity.
Authorization layer checks permissions.
SessionRevocationService handles operational revocation.

- 20,000 users
- 2,000 concurrent users
- multi-tenant
- admin can force logout user
- tenant can be suspended
- role changes must take effect within 1 minute
- Kubernetes deployment
- Redis available
- PostgreSQL available

1. GET /login and capture anonymous cookie.
2. POST /login with same cookie.
3. Assert response Set-Cookie has different value.
4. Assert old cookie cannot access /dashboard.
5. Assert new cookie can access /dashboard.

1. User logged in.
2. Stop Redis or block connection.
3. Request authenticated endpoint.
4. Verify request fails closed.
5. Verify no 500 leak for normal user path if app chooses redirect/401.
6. Verify alert is emitted.

Who is authenticated?
Until when?
With what assurance?
Under which tenant/context?
Can we invalidate it now?
Can we explain later what happened?
Can the system survive deployment and partial failure?