Innomerc Learn
English is the default.
Web & Backend Technology

Cookies and Sessions

See how an HTTP cookie can connect separate requests to server-side session state.

Foundational6 min explorationReviewed
My learningNot started

Choose your depth. Learn at your own pace.

Simple explanation

Understand it

A cookie is a small piece of data a browser stores and sends with matching requests. A session is a way for a service to remember an interaction or signed-in identity. A common design stores the session on the server and puts only a random session identifier in a cookie.

The identifier works like a claim ticket. If someone steals a usable session ticket, they may be able to act as its holder without repeating the password step. That is why signing out and protecting session storage matter even when MFA protects sign-in.

Technical explanation

Under the hood

The server can return Set-Cookie with attributes that constrain use. Secure limits sending to secure transport; HttpOnly prevents ordinary script access to that cookie; SameSite influences cross-site sending. Domain and Path affect scope but are not a complete authorization boundary.

Rotate the session identifier after authentication and privilege changes. Use idle and absolute timeouts appropriate to the application and invalidate state on logout. Cookies are sent automatically, so state-changing requests need CSRF protections suited to the architecture.

Practitioner explanation

Practitioner perspective

Review the entire session lifecycle: creation, rotation, parallel sessions, logout, recovery, revocation and device loss. A server that merely deletes a browser cookie at logout may leave copied identifiers valid if server state remains active.

Log creation and revocation events using a non-sensitive correlation value rather than raw session identifiers. HttpOnly reduces one route of token theft but does not stop injected script from issuing actions through the user’s browser.

See the decision happen

Watch it work

A fictional, simplified model. Select a component to inspect it, or follow the steps in order.

Interactive Lab

How credentials are checked

See the difference between storage, proof, validation and authorization.

Steps1. Session cookie 2. Lookup session 3. User + expiry 4. Identity context
Click a box or choose its name to learn what it means.
ClientReadyVerifierReadyCredential storeReadyResourceReadyClientReadyVerifierReadyCredential storeReadyResourceReady
Ready to traceServer session
Before you start · 4 stepsServer session

An opaque cookie identifies server-side session state.

How to use this example

Select Next step to read at your own pace, or Animate step to watch one exchange. Nothing advances until you choose.

Inspect components & read every step
  • Client

    A program that asks another system for information or an action.

    Example: A shopping app requests a list of products from a service.

  • Verifier

    The system checking whether the presented proof is acceptable.

    Example: A sign-in service checks a submitted password against its stored password verifier.

  • Credential store

    Storage for authentication-related records. It should not hold passwords as readable text.

    Example: A service stores salted password hashes and account information.

  • Resource

    The information or action someone wants permission to use.

    Example: A private document or an account setting is a resource.

JWT validation

A readable token is not a trusted token; validate claims before authorization.

  1. Client Verifier: Signed token. The request includes a token, not its signing key.
  2. Credential store Verifier: Trusted public key. Resolve trusted verification material; this may be cached.
  3. Verifier Resource: Validated claims. Check issuer, audience and lifetime, then evaluate permissions.
  4. Resource Client: Allowed response. Only an authorized operation returns protected data.

Server session

An opaque cookie identifies server-side session state.

  1. Client Verifier: Session cookie. The browser sends an opaque session identifier.
  2. Verifier Credential store: Lookup session. The service reads the associated state.
  3. Credential store Verifier: User + expiry. Expiry and revocation affect the result.
  4. Verifier Resource: Identity context. Resource authorization is still required.

Password hashing

Use a password KDF such as Argon2id with a unique salt and suitable cost.

  1. Client Verifier: Password over TLS. The verifier receives the candidate in a protected connection.
  2. Credential store Verifier: Salt + KDF settings. Retrieve the stored salt, parameters and verifier.
  3. Verifier Credential store: Compare verifier. Compare computed and stored verifier safely; do not store plaintext.
  4. Verifier Client: Decision. Apply rate limits and additional factors where required.

Refresh token

Renewal is a separate credential flow, not an extension of an expired access token.

  1. Client Resource: Expired token. The resource rejects an expired access token.
  2. Client Verifier: Refresh credential. The client presents its refresh credential to the authorization server.
  3. Verifier Client: New access token. Issue a new token only after the refresh policy succeeds.
  4. Client Resource: Retry with token. The resource validates the new token and requested permissions.

API key

An API key is a credential with scope, expiry and revocation policy—not necessarily a user identity.

  1. Client Verifier: API key. The client presents a secret credential over TLS.
  2. Verifier Credential store: Lookup policy. Check status, expiry and configured permissions.
  3. Verifier Resource: Scoped caller. Authorize this operation under the credential’s policy.

Authorization failure

Authentication can succeed while the requested object remains forbidden.

  1. Client Verifier: Valid credentials. The verifier establishes who the caller is.
  2. Verifier Resource: Other user’s object. The application checks the target owner and action.
  3. Resource Client: 403 · denied. Protected content is not returned.

Fictional teaching trace. One moving dot represents an exchange, not a measured network capture.

Open the detailed lesson walkthrough

Explore the system

Sign in

The server authenticates the user and creates session state.

1 / 4

Takeaway The cookie connects requests; authorization still applies.

Read every step without animation

Active session

  1. Sign in. The server authenticates the user and creates session state.
  2. Cookie. The browser receives an opaque session identifier.
  3. Next request. The browser sends the cookie to the matching service.
  4. Session lookup. The server finds active state and continues with permission checks.

The cookie connects requests; authorization still applies.

Revoked session

  1. Logout. The server invalidates the session state.
  2. Copied identifier. A previously copied identifier is presented again.
  3. Lookup fails. No active session is found.
  4. Reauthenticate. Protected access requires a new valid sign-in.

Server-side invalidation closes this replay path.

Attack view

A fictional stolen session identifier is replayed. The visual contrasts a still-active session with one the server has invalidated.

Defender view

  • Use Secure, HttpOnly and appropriate SameSite attributes.
  • Rotate and revoke sessions at relevant identity events.
  • Apply CSRF defenses and prevent script injection independently.

Common mistakes

  • Cookies and sessions are not synonyms.
  • HttpOnly does not make XSS harmless.

Check your understanding

What is the purpose of HttpOnly?
Active recall: explain this idea in 30 seconds

A cookie is a small piece of data a browser stores and sends with matching requests. A session is a way for a service to remember an interaction or signed-in identity. A common design stores the session on the server and puts only a random session identifier in a cookie.

Now give an example and name one limitation. Revisit the explanation if you get stuck.

Primary sources

Original explanations informed by these specifications and official resources. Source versions and lesson review are separate from product updates.

Content reviewed 2026-09-10. Read the editorial policy.

What comes next?

Technology fundamentals
Web and application security
From passwords to identity security

Back to topic