Session Based Authentication: Mermaid Flowchart

Session Based Authentication flowchart diagram

About Source

Session-based authentication is the traditional server-side model where the server maintains the state of a logged-in user. Rather than issuing a self-contained token that carries all claims, the server stores session data and gives the client an opaque session ID — typically delivered in a Set-Cookie response header.

When a user submits their credentials, the server validates them against the user store. On success, it creates a session record — containing the user ID, creation time, expiry, and any relevant metadata — and persists it to a session store, which may be an in-memory store like Redis, a relational database, or a distributed cache. The server generates a random, cryptographically unpredictable session ID and sends it to the browser as a cookie (ideally with the HttpOnly, Secure, and SameSite=Strict flags set).

On every subsequent request, the browser automatically includes the session cookie. The server looks up the session ID in the store, validates that the session exists and hasn't expired, retrieves the associated user data, and proceeds with the request. If the session is not found (expired, deleted, or the ID is invalid), the server responds with a redirect to the login page.

The key advantage over JWT Authentication Flow is immediate revocability: to log out a user or invalidate a compromised session, the server simply deletes the session record. There is no need to wait for a token to expire. The trade-off is stateful infrastructure: every server in a horizontally scaled cluster must be able to reach the shared session store, which introduces a network dependency and a potential single point of failure if the session store goes down.

Session-based auth pairs naturally with CSRF Protection Flow since form submissions rely on cookie-based sessions. For secure cookie configuration, see Secure Cookie Flow.

Frequently asked questions

Session-based authentication is a stateful server-side model where the server creates a session record for each authenticated user and issues an opaque session ID stored in a browser cookie. Each request is authenticated by looking up that session ID in the server's session store, which may be Redis, a database, or a distributed cache.

When a user submits valid credentials, the server creates a session record containing the user ID, expiry time, and metadata, then stores it in the session store. It generates a random session ID and returns it as an `HttpOnly`, `Secure`, `SameSite=Strict` cookie. On every subsequent request, the browser sends the cookie, the server looks up the session ID, and if found and valid, the user is considered authenticated.

Sessions offer immediate revocability — deleting the session record instantly invalidates access — and are simpler to reason about. The trade-off is stateful infrastructure: every server must reach a shared session store, introducing a network dependency. JWTs are stateless and scale without a shared store, but cannot be revoked before expiry without a denylist, making incident response slower.

Choose sessions when you need instant revocability (e.g., immediately invalidating compromised accounts), when your backend is a traditional monolith with a single session store, or when you need to tightly integrate with CSRF protection via synchronised tokens. Choose JWTs for stateless APIs, microservices, or mobile backends where a shared session store would add operational complexity.

mermaid

flowchart TD
    A([User submits credentials]) --> B{Credentials valid?}
    B -- No --> C([Return 401 login error])
    B -- Yes --> D[Create session record in store]
    D --> E[Generate random session ID]
    E --> F[Set-Cookie: session_id=XXXX HttpOnly Secure SameSite]
    F --> G([User receives session cookie])

    G --> H([Browser sends request with cookie])
    H --> I{Session ID in store?}
    I -- Not found --> J([Redirect to login])
    I -- Found --> K{Session expired?}
    K -- Yes --> L[Delete session record]
    L --> J
    K -- No --> M[Load user data from session]
    M --> N([Return protected resource])

    N --> O([User clicks logout])
    O --> P[Delete session record from store]
    P --> Q[Clear session cookie]
    Q --> J