Add session mgt guide

[wbamberg]

Here's a page on session management.

Terminology

I've talked mostly about two different models, one where the state is stored in the server and the client gets a session ID, and the other where the state is stored as a signed object (JWT) in the client. I've called these "centralized" and "decentralized" but people don't use these terms.

People sometimes use terms like "cookie-based" for the first and the second "JWT-based", but I don't like these, because ISTM that:

1. how you store session information in the client and communicate it to the server is orthogonal to these architectural choices - that is, you don't have to do the first using cookies, and you could do the second using cookies

2. (this is a much weaker objection) although in practice everyone does use JWTs for the second, that's an implementation choice not an architectural one.

I have asked about this and got feedback that my choice here is reasonable, but just flagging it here. We could call them "server-maintained state" and "client-maintained state" which is more descriptive but a real mouthful.

Frameworks and libraries

Regarding the section on "Frameworks and libraries", I do think we need to say this but went back and forth on whether to say it at the start or at the end, and how much detail to go into. FWIW although it might seem to negate the point of all this if we just tell people to use a framework, I really don't think it does - it is important to understand the principles and good practices, even if your framework is looking after a lot of the details for you.

[github-actions]

[mdn-linter] _{reported by reviewdog 🐶}

Suggested change

	1. When the client attempts some high-risk operation, such as attempting to change, or actually changing, the user's credentials on the site, or triggering the account recovery (e.g. password reset) process.
	1. When the client attempts some high-risk operation, such as attempting to change, or actually changing, the user's credentials on the site, or triggering the account recovery (e.g., password reset) process.

[github-actions]

Preview URLs (1 page)

• /en-US/docs/Web/Security/Authentication/Session_management

Flaws (1)

Found an unexpected or unresolvable flaw? Please report it here.

URL: /en-US/docs/Web/Security/Authentication/Session_management
Title: Session management
Flaw count: 1

• macros:
  • Macro ? produces link /en-US/docs/Web/Security/Firefox_Security_Guidelines which is a redirect

External URLs (3)

URL: /en-US/docs/Web/Security/Authentication/Session_management
Title: Session management

• https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/ (1 time) (Note! This may be a new URL 👀)
• https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html (3 times) (Note! This may be a new URL 👀)
• https://www.jwt.io/ (1 time) (Note! This may be a new URL 👀)

(comment last updated: 2026-02-10 01:00:44)

[hamishwillee]

This just feels a little awkward. I don't love my words, but have a think about it.

Suggested change

	Once a website has authenticated a user, it typically needs to remember that user's identity across the subsequent requests that the user makes to the site. That's the function of a session management system.
	HTTP is a stateless protocol, which means that each request and response pair beween the browser and the website does not depend on previous interactions.
	Session management systems provide a mechanism for remembering a user's identity across multiple requests to a site.

[wbamberg]

hm, I wanted to start by tying session management into authentication, since that's the context here ("you're reading about authentication, and part of that is knowing about session mgt". I don't particularly mind starting with the generic "HTTP is stateless" approach but it would need some additional rework in the intro, or things get incoherent.

In particular, the "Session management systems provide a mechanism for remembering a user's identity..." doesn't follow well from a general statement about statelessness. Why are suddenly talking about identity here?

I think it could work to say something like:

1. HTTP is stateless
2. session management (in general) is a way to add state (in general)
3. a major application for this is remembering that a particular client has been authenticated as a particular user, which is where it's relevant to authentication.

[hamishwillee]

Yes, I saw the intended approach. I do prefer your "could work something like" structure, but you could ignore me as this does do what you want.

[wbamberg]

does this -> 63570e4 make more sense?

[hamishwillee]

Below you say

In targeting session management, an attacker's goal is to be able to impersonate a legitimate user, without having to compromise the website's authentication system itself. In this section we'll describe the two main ways in which an attacker can do this: session hijacking and session fixation.

As I understand it now, and what I think you are trying to show here, is that authentication is (can be?) separate to session. The authentication follows some process that confirms identity. The representation of identity is then a session cookie (in this first case). The authentication process might use some credential to identify the user, but the session becomes the credential that is used for subsequently identifying the user

So in that sentence you're saying that once the session is what represents the user credential, you can attack that rather than the authentication mechanism.

It might be worth spelling out in a sentence after this bullet point something along the lines of "Therefore after authentication the session id is the credential used to identify the user, and that defines their accesses".

FWIW thanks! One of my big problems with sessions and authentication is that I never really understood how they interacted. We talk about cookies and authentication and credentials, and we separately talk about all sorts of authentication mechanisms that don't use cookies and it wasn't clear how they all fit together (at least for me)

[wbamberg]

Below you say

In targeting session management, an attacker's goal is to be able to impersonate a legitimate user, without having to compromise the website's authentication system itself. In this section we'll describe the two main ways in which an attacker can do this: session hijacking and session fixation.

As I understand it now, and what I think you are trying to show here, is that authentication is (can be?) separate to session. The authentication follows some process that confirms identity. The representation of identity is then a session cookie (in this first case). The authentication process might use some credential to identify the user, but the session becomes the credential that is used for subsequently identifying the user

So in that sentence you're saying that once the session is what represents the user credential, you can attack that rather than the authentication mechanism.

Yes, this is how I understand things.

It might be worth spelling out in a sentence after this bullet point something along the lines of "Therefore after authentication the session id is the credential used to identify the user, and that defines their accesses".

I will think about this.

FWIW thanks! One of my big problems with sessions and authentication is that I never really understood how they interacted. We talk about cookies and authentication and credentials, and we separately talk about all sorts of authentication mechanisms that don't use cookies and it wasn't clear how they all fit together (at least for me)

Thanks! It's nice to hear that this is helpful (and I hope it is also correct!)