Introduction

HTTP requests are normally processed independently. When a browser sends two requests, the server does not automatically know that both requests belong to the same authenticated user or workflow.

Request 1:

POST /login


Request 2:

GET /my-courses


Question:

How does the server know that
Request 2 belongs to the user
authenticated by Request 1?

A session provides continuity across multiple requests. It allows the system to associate a new request with previously established context.

Session context can include:

• An authenticated account identifier
• A trusted tenant identifier
• A session creation time
• An expiration time
• An authentication-strength indicator
• A server-generated anti-forgery value
• Temporary workflow context
• Security and revocation metadata

Prerequisites

What Is a Session?

A session is a controlled relationship between a client and an application that persists across several requests.

Login request
      |
      v
Credentials verified
      |
      v
Session created
      |
      v
Session identifier returned
      |
      v
Client sends identifier
with later requests
      |
      v
Server retrieves and validates session

A session is not necessarily permanent. It normally has an expiration, revocation, and renewal policy.

Authentication vs Session vs Authorization

Session Identifier

A server-side session design commonly gives the client an opaque session identifier.

Client receives:

sessionId = random-unpredictable-value


Session store contains:

sessionId
    -> accountId
    -> tenantId
    -> createdAt
    -> expiresAt
    -> authentication state

The identifier should not contain meaningful business data. It should be difficult to predict, sufficiently unique, and protected during transport and storage.

Cookie-based Session

Browser applications commonly store the session identifier in a cookie.

Session-cookie Response

HTTP/1.1 200 OK
Set-Cookie: session_id=opaque-random-value; Path=/; Secure; HttpOnly; SameSite=Lax

Later Request

GET /my-courses HTTP/1.1
Host: www.example.com
Cookie: session_id=opaque-random-value

The browser sends the cookie according to its domain, path, security, SameSite, and expiration attributes.

Important Cookie Attributes

Cookie attributes should be selected according to the application's authentication flow, deployment domains, and cross-site requirements.

Cookie Scope

Set the narrowest practical cookie scope.

Cookie available to:

- Unrelated subdomains
- Unnecessary paths
- Non-secure requests

Cookie available only to:

- Required hostname or domain
- Required application path
- HTTPS requests

Local In-memory Sessions

In a basic deployment, each server can store sessions in its own memory.

Instance A memory:

session-123
    accountId = 1042
    tenantId = 17


Instance B memory:

session-901
    accountId = 2044
    tenantId = 28

This design can work with one server but creates problems after horizontal scaling.

Login handled by Instance A

Session stored only in A


Next request handled by Instance B

Instance B cannot find the session

Limitations

• The user becomes dependent on one server
• Instance failure can remove the session
• Scaling in can sign out active users
• Rolling deployments can disrupt sessions
• Rebalancing requires session movement or affinity

Sticky Sessions

Sticky sessions, also called session affinity, direct related requests to the same backend.

User A
    -> Instance 1
    -> Instance 1
    -> Instance 1


User B
    -> Instance 2
    -> Instance 2
    -> Instance 2

Possible Benefits

• Supports legacy applications using local sessions
• Can reduce immediate migration changes
• Can reduce repeated session-store lookups in selected designs

Limitations

• Backend failure can lose or strand the local session
• Traffic can become uneven
• Scaling in requires affinity-aware draining
• Users can move after affinity-cookie expiry
• Affinity does not make application state durable

Shared Session Store

In a shared-session design, every application instance retrieves session data from the same authorized session service or datastore.

Client
   |
   | session_id
   v
Load Balancer
   |
   +-- Instance A
   +-- Instance B
   +-- Instance C
           |
           v
   Shared Session Store

The session identifier is sent by the client, while the trusted session data remains on the server side.

Benefits

• Any application instance can handle the request
• Sessions survive one application-instance failure
• Sessions can be revoked centrally
• Expiration can be enforced centrally
• Scale-out does not require session copying between servers

Trade-offs

• Session lookup adds a network operation
• The shared store can become a bottleneck
• Store failure can affect all application instances
• Replication and consistency must be understood
• Session records require expiration and cleanup

Conceptual Session Table

CREATE TABLE application_sessions
(
    session_id_hash VARCHAR(128) PRIMARY KEY,
    tenant_id BIGINT NOT NULL,
    account_id BIGINT NOT NULL,

    created_at TIMESTAMP NOT NULL,
    last_seen_at TIMESTAMP NOT NULL,
    idle_expires_at TIMESTAMP NOT NULL,
    absolute_expires_at TIMESTAMP NOT NULL,

    authentication_level VARCHAR(30) NOT NULL,
    session_status VARCHAR(30) NOT NULL,
    session_version BIGINT NOT NULL
);

Storing a protected hash of an opaque session identifier can reduce exposure if session records are disclosed. Exact implementation depends on the approved framework and security design.

Opaque Session vs Signed Token

A signed token is not automatically safer or more scalable than a server-side session. The choice depends on revocation, claims freshness, privacy, rotation, request size, and service-boundary requirements.

Session Lifetime

A session should not remain active indefinitely without a documented reason.

Idle Expiration

Session expires when:

No accepted activity occurs
during the configured idle period.

Absolute Expiration

Session expires when:

Its maximum lifetime is reached,
even if activity continues.

Why Use Both?

Idle expiration limits abandoned-session lifetime. Absolute expiration limits the maximum lifetime of continuously active session credentials.

Sliding Expiration

Sliding expiration moves the idle-expiration boundary when valid activity occurs.

Initial idle expiry:

12:30


Valid request at:

12:20


Updated idle expiry:

12:50


Absolute expiry remains:

14:00

Avoid updating the shared session record on every high-frequency request when this would create excessive write traffic. Updates can be controlled according to the approved session framework and freshness requirement.

Session Identifier Rotation

The session identifier should be rotated after important security-state changes.

Anonymous session
      |
      v
User authentication succeeds
      |
      v
Old identifier invalidated
      |
      v
New authenticated session
identifier issued

Rotation can be considered after:

• Authentication
• Privilege elevation
• Security-sensitive account changes
• Recovery from a suspected session compromise

Session Revocation

Revocation invalidates a session before its normal expiration.

Reasons can include:

• User logout
• Password change
• Account disablement
• Permission or tenant-access removal
• Suspected session compromise
• Administrative security action
• Maximum-session policy enforcement

Session request received
      |
      v
Session record loaded
      |
      v
Check status
      |
      +-- Active:
      |      continue
      |
      +-- Revoked:
             reject request

Logout

Logout should invalidate the server-recognized session and expire the client's cookie.

HTTP/1.1 204 No Content
Set-Cookie: session_id=; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=0

Clearing only the browser cookie is insufficient if the session identifier remains active and has been copied or stolen.

Session Fixation

Session fixation occurs when an attacker causes a victim to use a session identifier known to the attacker and the application continues using it after authentication.

Attacker obtains or chooses
a known session identifier
      |
      v
Victim authenticates
using that session
      |
      v
Application keeps same identifier
      |
      v
Attacker reuses authenticated session

Rotate the session identifier after authentication and invalidate the previous identifier.

Session Hijacking

Session hijacking occurs when an unauthorized party obtains and reuses a valid session credential.

Risk-reduction controls include:

• HTTPS for the complete authenticated session
• Secure cookie attributes
• Strong unpredictable identifiers
• Bounded idle and absolute expiration
• Session rotation
• Revocation
• Protection against script injection
• Avoiding session identifiers in URLs and logs
• Additional verification for high-risk operations

Do Not Put Session IDs in URLs

/my-courses?sessionId=secret-session-value

URLs can appear in browser history, server logs, analytics, bookmarks, copied messages, screenshots, and referrer information.

Cookie: session_id=opaque-session-value

Cross-site Request Forgery

Browsers can automatically send cookies with requests. An attacker can try to cause a signed-in browser to submit an unintended state-changing request.

Possible defenses include:

• Appropriate SameSite cookie policy
• Anti-forgery tokens
• Origin or request-context validation where appropriate
• Reauthentication for high-risk actions
• Using safe HTTP methods correctly

Cookie-based authentication and token-based API authentication have different browser behaviours. Select controls for the actual client and request flow.

Session and Tenant Isolation

A trusted tenant must be derived from validated authentication and authorization context.

{
  "sessionId": "opaque-session-identifier",
  "accountId": 1042,
  "tenantId": 17,
  "status": "active",
  "expiresAt": "session-expiration"
}

A request parameter such as tenantId=17 is not sufficient proof that the caller belongs to that tenant.

Multiple Active Sessions

One account can have several active sessions from different browsers, applications, or devices.

Account 1042

+-- Session A
|      Browser 1
|
+-- Session B
|      Browser 2
|
+-- Session C
       Mobile application

The security policy should define:

• Whether multiple sessions are permitted
• Whether users can view active sessions
• Whether users can revoke selected sessions
• Whether password changes revoke every session
• Whether inactive sessions are removed automatically
• Whether concurrent-session limits apply

Binding Sessions to Client Signals

Applications sometimes record network or device-related signals for anomaly detection.

Avoid rigidly binding every session to values that can legitimately change, such as a mobile network address. Overly strict binding can sign out valid users and create accessibility or availability problems.

Client signals are better treated as risk inputs unless the security requirement explicitly demands stronger binding.

Session-store Performance

A shared session store can receive at least one lookup for every authenticated request.

A simplified read-rate estimate is:

\[ SessionReadRate = AuthenticatedRequestRate \times LookupsPerRequest \]

Additional writes can occur for:

• Session creation
• Sliding-expiration updates
• Last-activity tracking
• Rotation
• Revocation
• Security-event recording

Avoid unnecessary session writes on every request when the design can safely use a controlled update interval.

Hot Session Keys

A very active account, automated client, or shared service identity can generate concentrated traffic against one session key.

Normal session:

10 requests per minute


Automated session:

20,000 requests per minute


Result:

One session record becomes
a hot key.

Keep session reads lightweight and avoid turning every request into a serialized write against the same record.

Session Cleanup

Expired and revoked sessions should not accumulate indefinitely.

Cleanup approaches can include:

• Native expiry or time-to-live support
• Indexed scheduled cleanup
• Partitioned retention
• Deletion during session access
• Periodic reconciliation

Cleanup should be bounded and indexed. A large unindexed deletion can create database pressure.

Session-store Failure

Client request
      |
      v
Application instance
      |
      v
Shared session store unavailable
      |
      v
Session cannot be validated

The application should fail securely when it cannot establish the caller's trusted session context.

Design:

• Connection and operation timeouts
• Bounded retries
• High availability
• Replication behaviour
• Capacity headroom
• Monitoring and alerts
• Recovery and failover

Session Replication

A distributed session store can replicate session data for availability.

Session write
      |
      v
Primary session location
      |
      v
Replicated session copy

Understand whether the selected read can return stale session information. Staleness is especially important after:

• Logout
• Session revocation
• Permission removal
• Account disablement
• Session rotation

PHP Secure-cookie Example

<?php

declare(strict_types=1);

function sendSessionCookie(
    string $sessionId,
    int $expiresAt
): void {
    setcookie(
        'session_id',
        $sessionId,
        [
            'expires' => $expiresAt,
            'path' => '/',
            'secure' => true,
            'httponly' => true,
            'samesite' => 'Lax'
        ]
    );
}

The exact SameSite, domain, path, and expiration values must match the application's authentication flow and deployment topology.

PHP Session Lookup Example

<?php

declare(strict_types=1);

final class SessionAuthenticator
{
    public function __construct(
        private SessionRepository $sessions
    ) {
    }

    public function authenticate(
        string $sessionId
    ): array {
        if ($sessionId === '') {
            throw new RuntimeException(
                'The session identifier is missing.'
            );
        }

        $session =
            $this->sessions->findActiveSession(
                $sessionId
            );

        if ($session === null) {
            throw new RuntimeException(
                'The session is invalid.'
            );
        }

        $currentTime = time();

        if ($session['idleExpiresAt'] <= $currentTime ||
            $session['absoluteExpiresAt'] <= $currentTime) {

            throw new RuntimeException(
                'The session has expired.'
            );
        }

        if ($session['status'] !== 'active') {
            throw new RuntimeException(
                'The session is not active.'
            );
        }

        return [
            'accountId' =>
                $session['accountId'],

            'tenantId' =>
                $session['tenantId'],

            'authenticationLevel' =>
                $session['authenticationLevel']
        ];
    }
}

Production code should use your approved authentication framework, constant security policies, protected identifiers, trusted tenant context, secure error handling, and tested storage clients.

Session Rotation Example

<?php

declare(strict_types=1);

final class SessionRotationService
{
    public function __construct(
        private SessionRepository $sessions,
        private SessionIdGenerator $sessionIds
    ) {
    }

    public function rotateAfterAuthentication(
        string $oldSessionId,
        int $tenantId,
        int $accountId
    ): string {
        $newSessionId =
            $this->sessionIds->generate();

        $this->sessions->rotate(
            oldSessionId:
                $oldSessionId,

            newSessionId:
                $newSessionId,

            tenantId:
                $tenantId,

            accountId:
                $accountId
        );

        return $newSessionId;
    }
}

The repository operation should prevent both identifiers from remaining independently usable beyond the intended transition.

Session and Health Checks

The application can be alive while the shared session store is unavailable.

Do not include the session store in liveness if restarting the application cannot repair the store.

Readiness treatment depends on whether the service can safely serve any meaningful traffic without session validation.

Liveness:

Application runtime can make progress.


Readiness:

Application can safely serve
its intended request set.


Detailed diagnostics:

Session store unavailable.

Sessions during Scale-in

A shared session remains valid when an application instance is removed.

Instance A marked not ready
      |
      v
New requests go to B and C
      |
      v
Existing requests drain
      |
      v
Instance A terminates
      |
      v
Shared sessions remain available

Local sessions require affinity-aware draining or migration, making scale-in more difficult.

Observability

Useful session metrics include:

• Active-session count
• Session-creation rate
• Session lookup rate
• Session-store latency
• Session lookup failures
• Session expiration count
• Session revocation count
• Session rotation count
• Logout count
• Session-store connection usage
• Session record size
• Expired-record cleanup rate
• Authentication failures
• Sticky-session distribution
• Cross-instance session failures

Avoid recording complete session identifiers in ordinary metrics, logs, or tracing attributes.

Session Audit Events

Security-relevant events can include:

• Session created
• Session rotated
• Session revoked
• Logout completed
• Expired-session use attempted
• Invalid-session use attempted
• Authentication level changed
• All account sessions revoked

Audit records should identify the event without exposing reusable session credentials.

Alert Conditions

Alert when:

• Session-store availability falls below its objective
• Session lookup latency increases
• Invalid-session requests rise unexpectedly
• Session creation increases unexpectedly
• Session cleanup falls behind
• One session key receives disproportionate traffic
• Users lose sessions after application deployment or scale-in
• Revoked sessions remain accepted
• Session-store storage usage grows unexpectedly
• Cookie-security configuration changes unexpectedly

Troubleshooting Workflow

1. Identify whether the client sent the expected session cookie or header.
2. Confirm that HTTPS and cookie scope are correct.
3. Confirm that the session identifier reaches the application.
4. Check whether the session record exists.
5. Check idle and absolute expiration.
6. Check revocation and session status.
7. Check tenant and account context.
8. Check session-store connectivity and latency.
9. Check whether requests reached different application instances.
10. Check sticky-session behaviour if affinity is used.
11. Check recent deployment and scale-in events.
12. Check cookie domain, path, Secure, HttpOnly, and SameSite configuration.
13. Check whether rotation invalidated the previous identifier correctly.
14. Review security events without exposing the session credential.

Common Session Mistakes

Recommended Test Cases

Session Best Practices

Practice Exercise

Implement shared sessions for your horizontally scaled online learning platform.

Requirements

1. Run at least two application instances behind a load balancer.
2. Create an unpredictable session identifier after authentication.
3. Store only the identifier in a protected browser cookie.
4. Store trusted session data in a shared session store.
5. Include account, tenant, creation, expiry, and status information.
6. Use separate idle and absolute expiration.
7. Rotate the session identifier after authentication.
8. Invalidate the previous identifier.
9. Implement logout and server-side revocation.
10. Prevent session identifiers from appearing in URLs and logs.
11. Authorize every protected resource after session validation.
12. Test requests across different application instances.
13. Terminate one application instance during an active session.
14. Test session-store unavailability.
15. Test cross-tenant access attempts.
16. Monitor lookup latency, expiration, rotation, and revocation.

Session-design Template

Frequently Asked Questions