--- term: 'Session Management' seoTitle: 'Session Management: Lifecycle, Cookies, Hijacking, Timeouts' headline: 'What is Session Management?' slug: session-management category: auth-security shortDefinition: 'Session management is a discipline for creating, validating, and destroying the server-side state that ties HTTP requests to one user.' relatedTerms: - json-web-token-jwt - authentication-vs-authorization - cross-site-scripting-xss-prevention - multi-factor-authentication-mfa contrastsWith: - json-web-token-jwt aboutTerms: - 'Session ID' - 'Session Hijacking' - 'Session Fixation' - 'Session Cookies' faq: - question: 'What is a session?' answer: 'A finite period of interaction between a client and a server — the mechanism that ties a sequence of HTTP requests to one user, so a stateless protocol can remember login state, carts, and preferences. It begins at login and ends at logout or timeout.' - question: 'How do sessions work?' answer: 'At login the server creates a session record and issues a random session ID in a cookie; the browser returns the ID with every request, the server looks up the associated state, and the record is destroyed at logout or expiry. The ID is the whole credential — whoever presents it is treated as the user.' - question: 'What is the difference between session and token (JWT) authentication?' answer: 'Where the state lives. Sessions keep it server-side — one lookup per request, revocable instantly. JWTs carry it inside the token — no lookup, verifiable anywhere, but valid until expiry no matter what. Sessions suit single-domain apps needing control; tokens suit APIs and microservices needing portability.' - question: 'What is session hijacking and how do you prevent it?' answer: 'Stealing a valid session ID — via sniffing, XSS, or malware — and presenting it to impersonate the user without ever knowing the password. Defenses: HTTPS everywhere, HttpOnly and Secure cookie flags, high-entropy IDs, short lifetimes, regeneration on privilege change, and anomaly monitoring.' - question: 'What is session fixation?' answer: 'The attacker plants a session ID they already know — via a crafted link or subdomain cookie — and waits for the victim to log in with it; the known ID is now an authenticated session. The complete fix: issue a brand-new ID at every authentication event and reject IDs the server never generated.' - question: 'What do the session cookie flags do?' answer: 'Each blocks one theft route: Secure sends the cookie over HTTPS only (defeats sniffing); HttpOnly hides it from JavaScript (defeats XSS cookie theft); SameSite withholds it from cross-site requests (defeats CSRF); and the __Host- name prefix locks it to one origin.' - question: 'What is the right session timeout?' answer: 'Two clocks, both server-enforced: an idle timeout — minutes for high-value apps, 15–30 for typical ones — and an absolute timeout of a few hours regardless of activity. Federal identity guidance at its second assurance level specifies 30 minutes idle and reauthentication at least every 12 hours.' - question: 'How should logout work?' answer: 'Server-side first: destroy the session record so the ID dies everywhere, then clear the cookie. The classic failure is the reverse — deleting only the cookie leaves the session alive for anyone who captured the ID, turning "logout" into a UI animation.' - question: 'Is "remember me" safe?' answer: 'It is a deliberate trade of security for convenience. Done responsibly: a separate long-lived token, single-use and rotated on each visit, stored in a hardened cookie, revocable server-side, invalidated on password change — and never a substitute for re-authentication before sensitive actions.' - question: 'Where should session data be stored at scale?' answer: 'Server-side, in a store all servers share: in-process memory works only on one server; a database is durable but slower; an in-memory store like Redis is the standard — fast, shared, and the reason any server can answer any request without sticky sessions.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'OWASP Session Management Cheat Sheet' url: 'https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html' - name: 'NIST SP 800-63B §7 — Session Management' url: 'https://pages.nist.gov/800-63-3/sp800-63b.html' - name: 'RFC 6265 — HTTP State Management Mechanism' url: 'https://datatracker.ietf.org/doc/html/rfc6265' - name: 'Using HTTP cookies — MDN Web Docs' url: 'https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies' cta: title: 'Sessions you can query' text: 'Back4app sessions are database objects — per-device, listable for "active sessions" screens, and revocable server-side the instant a user logs out, changes a password, or you say so.' linkText: 'Start building free' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-07-30' translationKey: session-management --- **Session management is a discipline for creating, validating, and destroying the server-side state that ties HTTP requests to one user.** HTTP itself remembers nothing — every request arrives a stranger — so applications bridge the gap with a session: a server-side record plus a random ID the browser presents on each request. The security insight everything else follows from: **that ID is a full credential-equivalent** — whoever holds it *is* the user, no password required — so it deserves password-grade generation, transport, and destruction. ## Key takeaways | Question | Answer | | --- | --- | | The mechanism | Login → server record + random ID in a cookie → ID returned per request | | The insight | The session ID *is* a credential — hijacked ID = account takeover | | The lifecycle | Create → regenerate on login/privilege change → validate → expire → destroy server-side | | The numbers | ≥64 bits of CSPRNG entropy · 15–30 min idle · hours absolute | | The classic bug | "Logout" that deletes the cookie but leaves the server record alive | ## The lifecycle in five stages ```text 1 CREATE at login: server-side record + fresh random ID (≥64 bits, CSPRNG) 2 REGENERATE at EVERY privilege change — login, role elevation, password change — issue a new ID, retire the old (kills fixation) 3 VALIDATE every request: ID exists, not expired, matches this user 4 EXPIRE two clocks, server-enforced: idle timeout + absolute timeout 5 DESTROY logout = delete the server record FIRST, then clear the cookie (cookie-only "logout" leaves the session alive for a thief) ``` Sessions as first-class, queryable objects — the lifecycle with handles on it: **JavaScript:** ```javascript // JavaScript / Node.js — Back4app JS SDK // Sessions are objects: queryable, per-device, revocable const user = await Parse.User.logIn('ada', password); // Session object created console.log(user.getSessionToken()); // r:… — the credential // "Active devices" UI: each login is a Session row (ACL: owner-only) const sessions = await new Parse.Query(Parse.Session).find(); // Logout = server-side destroy — the token dies NOW await Parse.User.logOut(); ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // Sessions are objects: queryable, per-device, revocable final user = ParseUser('ada', password, null); await user.login(); // Session object created print(user.sessionToken); // r:… — the credential // "Active devices" UI: each login is a Session row (ACL: owner-only) final sessions = await QueryBuilder(ParseSession.forQuery()).query(); // Logout = server-side destroy — the token dies NOW await user.logout(); ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // Sessions are objects: queryable, per-device, revocable let user = try await User.login(username: "ada", password: password) print(user.sessionToken ?? "") // r:… — the credential // "Active devices" UI: each login is a Session row (ACL: owner-only) let sessions = try await ParseSession.query().find() // Logout = server-side destroy — the token dies NOW try await User.logout() ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // Sessions are objects: queryable, per-device, revocable val user = ParseUser.logIn("ada", password) // Session object created println(user.sessionToken) // r:… — the credential // "Active devices" UI: each login is a Session row (ACL: owner-only) val sessions = ParseQuery.getQuery(ParseSession::class.java).find() // Logout = server-side destroy — the token dies NOW ParseUser.logOut() ``` ```mermaid flowchart LR accTitle: Session lifecycle from login to server-side destruction accDescr: On login the server creates a session record and issues a random ID in a cookie. The ID is regenerated at privilege changes, validated on every request against the server record, expired by idle and absolute timeouts, and destroyed server-side at logout so the ID dies everywhere. L["Login
(authentication)"] --> C["Create record +
random ID → cookie"] C --> R["Regenerate ID on
privilege change"] R --> V["Validate on
every request"] V -->|"idle / absolute
timeout"| X["Expire"] V -->|"logout"| D["Destroy record
server-side"] X --> D ``` ## Session cookies: the flags, and what each blocks The mapping no ranking page tabulates — every flag is a named attack's tombstone: | Flag | What it does | Attack it blocks | | --- | --- | --- | | `Secure` | Cookie travels over HTTPS only | Network sniffing | | `HttpOnly` | Invisible to JavaScript | [XSS](/glossary/cross-site-scripting-xss-prevention/) cookie theft | | `SameSite=Lax/Strict` | Withheld from cross-site requests | CSRF | | `__Host-` prefix | Locks cookie to origin, no subdomain tricks | Fixation via subdomains | | *(no Max-Age/Expires)* | Dies with the browser session | Stale sessions on shared machines | Per [RFC 6265](https://datatracker.ietf.org/doc/html/rfc6265) semantics, with the practical details on [MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cookies). All five together are the baseline, not the hardened configuration. ## The attacks, each with its defense **Hijacking** — steal a valid ID (sniffing on plain HTTP, XSS, malware) and present it; the server sees the user. Defense: TLS everywhere, the flag table above, short lifetimes, monitoring for impossible travel. **Fixation** — the inversion worth understanding mechanically: the attacker *gives* the victim an ID before login (crafted link, planted cookie); the victim authenticates; the attacker's known ID is now a logged-in session. Defense in one move: **regenerate the ID at authentication** — the pre-login ID the attacker knows becomes worthless the instant privileges attach, and strict servers reject any ID they didn't mint. **XSS theft** — injected script reads the cookie; `HttpOnly` removes that read, which is damage limitation while the [XSS itself gets fixed](/glossary/cross-site-scripting-xss-prevention/). **CSRF** — the browser helpfully attaches cookies to forged cross-site requests; `SameSite` plus anti-CSRF tokens close it. ## Sessions vs. JWTs | | Server-side sessions | JWTs | | --- | --- | --- | | State lives | On the server | Inside the token | | Revocation | Instant — delete the record | Waits for `exp`, or denylist state | | Per-request cost | One store lookup | Signature check | | Scale across services | Needs a shared store | Any key-holder verifies | The crux is **revocability**, and it's an architecture decision, not a feature checkbox: sessions can die the moment you say so; stateless tokens cannot, and every workaround reintroduces the state you removed. The [JWT entry](/glossary/json-web-token-jwt/) argues the stateless side; this article's subject is what doing stateful *well* requires. ## The numbers that make it real [OWASP's cheat sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) puts entropy at **≥64 bits from a CSPRNG** — sixteen random hex characters, enough that brute-forcing IDs takes centuries at realistic request rates — with nothing meaningful encoded in the ID. Timeouts run on two clocks: **idle** (2–5 minutes for high-value applications, 15–30 for typical ones) and **absolute** (a few hours, ending even active sessions so a stolen ID has a hard ceiling). [NIST's digital identity guidelines](https://pages.nist.gov/800-63-3/sp800-63b.html) formalize the same shape: at assurance level 2, reauthentication after 30 idle minutes and at least every 12 hours regardless. ## Scaling sessions: sticky routing vs. shared store | | Sticky sessions | Shared store (Redis-style) | | --- | --- | --- | | How | Load balancer pins user → server | All servers read one session store | | Server dies | Its sessions die with it | Users never notice | | Scaling | Uneven load, drain on deploys | Any server, any request | | Verdict | A routing patch | The architecture | In-process session memory works on exactly one server. Sticky routing stretches it — and turns each server into a small outage waiting to log users out. The standard answer is a shared in-memory store (Redis, Memcached) or the database: session state becomes infrastructure, and the web tier goes stateless — the same property that makes JWT architectures attractive, achieved while keeping instant revocation. ## Sessions as a product feature The security layer doubles as UX when sessions are *visible*: an "active sessions" screen listing each device with its login time and location, a "log out everywhere" button, and automatic revocation of all sessions on password change or suspected compromise. Users read this as safety; engineers should read it as a requirement on the architecture — sessions must be *queryable objects with owners*, not opaque blobs in a cache, which is precisely where session stores built only for lookup fall short. ## Common use cases - **Web app login state** — the canonical case: cookie-carried sessions with the full flag set. - **E-commerce carts and flows** — multi-step state that must survive navigation but not the week. - **Banking and high-value apps** — short idle timeouts, absolute ceilings, [step-up MFA](/glossary/multi-factor-authentication-mfa/) mid-session for sensitive actions. - **Device management** — per-device sessions powering "log out my stolen phone." - **Admin panels** — where regeneration on privilege elevation and aggressive timeouts earn their keep. ## Should you use sessions or tokens? A decision matrix | Situation | Reach for | | --- | --- | | Single-domain web app | Sessions — simpler and instantly revocable | | Instant lockout is non-negotiable | Sessions (or tokens + the state you swore off) | | Many services verify independently | [JWTs](/glossary/json-web-token-jwt/) | | Mobile app on a BaaS | The platform's session tokens — revocable, prebuilt | | Horizontal scale with sessions | Shared store, not sticky routing | | "Active devices" as a feature | Sessions as queryable objects | ## Limitations and trade-offs - **The store is hot-path infrastructure.** Every request reads it; its latency is your latency, its outage is everyone's logout. - **Cross-domain is awkward.** Cookies bind to origins; APIs consumed by many parties push toward tokens — often the honest hybrid is sessions for the app, tokens for the API. - **Timeouts tax users.** Every idle logout is friction; the numbers above are risk decisions, not constants, and deserve product sign-off. - **Revocation needs plumbing users see.** Instant revocation is only valuable if password changes and "log out everywhere" actually trigger it — wire the events, not just the capability. - **Sessions inherit cookie politics.** Third-party-cookie changes and browser privacy work keep shifting the terrain; first-party session cookies remain safe ground, but stay on it deliberately. ## Sessions on Back4app Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. Sessions here are the "queryable objects" this article keeps asking for — literally: each login creates a `Session` object holding the revocable token, its user, creation context, and expiry, ACL-scoped so users see only their own. The code tabs show the consequences: an "active devices" screen is a query; logout is a server-side destroy that kills the token everywhere immediately; password changes can revoke every session; and Cloud Code triggers are the hook for step-up rules and audit trails. Lifecycle, revocation, and the product features sit on the same primitive — sessions as data — with the entropy, storage, and validation machinery run by the platform.