Jan Mikoláš
Glossary
Session
A session connects otherwise independent HTTP requests. It lets the server invalidate state immediately, but requires carefully designed storage and secure handling of the identifier.
Short definition
The session is server-side state; the session ID is only a key to it.
HTTP is stateless: one request does not normally know which request came before it. A session fills that gap. After login, the application stores a server-side record such as the user identity, creation time, and inactivity period. It returns an unpredictable session ID to the browser, typically in a cookie, so it can find the correct record on the next request.
A session ID is a credential: anyone who presents a valid one may be treated as the holder of the session. It must therefore be random, protected in transit with HTTPS, and never appear in a URL. A session does not replace authorization. Even after identifying the user, the server verifies the current role, tenant, resource ownership, and business rules before performing an action.
What it is used for
Signed-in browsers and short-lived connected flows
A session makes most sense when the application controls both the server and browser client and needs to revoke or change the session continuously.
- customer accounts, online-store administration, and internal applications with signed-in users
- temporary state for a multi-step form when it is not stored directly in the business database
- storing a CSRF value or information about an authentication step in progress
- central logout and session invalidation after a password change, risky action, or access revocation
- a server-managed session when linking an external identity through OIDC or another login flow
Practical example
Signing in to online-store administration
An operator authenticates successfully. The server creates a session, stores the account identifier and time limits in it, and sends only its random key to the browser. For every order change, the application verifies the session and independently decides whether the operator may work with an order belonging to the specific organisation.
The identifier is rotated after login so an attacker cannot plant a known session ID before the victim signs in. On logout it is invalidated on the server and the cookie is removed. The pattern below uses the __Host- prefix, which requires Secure, Path=/, and no Domain attribute.
Set-Cookie: __Host-session={náhodný-neprůhledný-identifikátor}; Path=/; Secure; HttpOnly; SameSite=LaxHow it works
A secure session from login to logout
The client-side value identifies the session; the server controls decisions and lifetime.
- The user proves their identity Authentication verifies a password, passkey, multi-factor step, or external identity provider. Failure does not establish a session.
- The server creates or renews the session It generates a cryptographically random session ID, stores the minimum necessary state, and rotates the identifier after login.
- The browser carries the ID in a cookie The cookie has Secure, HttpOnly, and an appropriate SameSite mode. The session ID is not sent in a query parameter, form, or log.
- Every request verifies the session The server looks up the record and checks expiration, logout status, and any other risk conditions. An unknown ID grants no privilege.
- Sensitive actions are authorized The session identifies the subject, but the server still checks permissions for the specific object. After logout or compromise, the session is invalidated.
Main session components
Session security is about more than cookie length
Each item limits a different class of failure: session takeover, fixation, unlimited lifetime, or inconsistent behaviour across multiple instances.
Random session ID
It must have sufficient entropy and be opaque. A sequential number, email address, or derived value is not a secure identifier for a signed-in session.
Identifier rotation
A new ID is issued after login, a permission change, or sensitive verification. This reduces the risk of session fixation, where an attacker knows the session before the victim signs in.
Idle and absolute timeouts
An idle timeout limits an unattended open browser; an absolute timeout prevents a session from being extended indefinitely through regular requests.
Shared storage
A session can live in local storage for one instance. Multiple instances need a shared store, such as a database or Redis, and a plan for its failure.
Invalidation
The server must be able to end the session on logout, password reset, or an incident. Merely deleting the cookie does not revoke a copy of the identifier that someone may have obtained.
Benefits and limitations
Sessions enable immediate control, but require operational discipline
Benefits
- the server keeps sensitive state out of the browser and can invalidate it at any time
- a current permission change takes effect at the next server evaluation
- a browser client can work with ordinary forms and without JavaScript
- the identifier can be small and opaque, without business information
Risks and common mistakes
- passing a session ID in a URL or storing more data in the session than the application needs
- retaining the same ID before and after login or failing to provide revocation
- relying only on hidden frontend navigation instead of server-side authorization
- deploying multiple instances without shared storage, consistent expiration, and a failure plan
When it is suitable
Browser administration often benefits from a server-managed session
A session works well for customer and internal web interfaces where immediate logout, active-session management, or continuous checks of changed roles matter. It does not rule out a separate frontend and backend, but the cookie domain, CORS, CSRF, and login flow must be clearly defined.
JWT may be more practical for some APIs or communication between services, but it is not a stateless shortcut for the entire security design. A token-based system still needs to manage expiration, compromise, renewal, and server-side authorization. Sessions and tokens can both suit different parts of the same system.
What to consider
Design the session as a revocable credential
The greatest benefit of a session comes when the application can manage its entire lifecycle securely.
- transmit the session ID exclusively in a secure cookie, never in a URL or accessible log
- rotate the identifier after successful authentication and invalidate the server record on logout
- set Secure, HttpOnly, an appropriate SameSite mode, and reasonable idle and absolute timeouts
- for multiple instances, verify shared storage, its expiration, availability, and outage behaviour
- test logout, password reset, role changes, an expired session, and attempted access to another tenant
Common questions
Working with server-side sessions
Is a session the same as a cookie?
No. A session is state on the server. A cookie usually carries only the identifier that tells the server which session to find.
Why does the session ID change after login?
Rotation limits session fixation. An attacker should not benefit from an ID obtained or planted before the victim signed in.
Can a session be stored in Redis?
Yes. Redis is often used as shared session storage. Availability, expiration, and secure invalidation must still be addressed just as with any other store.
Is JWT always better than a session?
No. JWT and sessions have different operational trade-offs. A server-side session simplifies immediate invalidation, while a token may help for another type of API. Authorization remains necessary in both cases.
How I approach backends in practice
I connect sessions to the secure application flow, not only the login form.
When developing PHP backends, I address browser sessions, API boundaries, access changes, and e-commerce administration with an emphasis on server-side data checks.