1 login session cache throttle and revocation
forgejo-actions edited this page 2026-07-15 12:43:13 +00:00

Login Session Cache, Throttle, And Revocation

Login session cache, throttle, and revocation explain how Redis session cache, Postgres freshness checks, failed-login throttle, refresh rotation, logout, and cache invalidation work together.

Purpose

Use this page when login requests are throttled, sessions appear stale, Redis failures affect auth, or a refresh/logout does not invalidate the expected token.

Required Inputs

Redis stores login:session:* cache records with TTL derived from SQL expiry. Postgres remains the freshness authority. Failed-login throttle tracks attempts and emits Retry-After when the limit is reached.

Procedure

Trust cached sessions only after the freshness check. On refresh rotation, invalidate the old token cache. On logout or revocation, remove cached state and verify the SQL session state. Treat Redis failures in throttle/cache paths as service-impacting.

Failure Modes

Common failures include stale cached sessions, old refresh tokens still cached, Redis latency or outage, login_throttled audit spikes, and confusion between invalid_credentials and throttled responses.

Verification

Inspect auth audit outcome, Redis latency, DB latency, cache TTL, Retry-After, and token rotation logs. Confirm logout invalidates both SQL and cache-visible state.