The session is not stored in a cookie. The session's ID is. Information about sessions is usually stored in the DB and that session ID is used to retrieve that info. Invalidating a session then is just removing that info from the right table.

Thank you, turns out my knowledge about how user sessions are handled is really bad

Fortunately, there's really nothing special to it. :) As long as you stick to the tried-and-true method (assuming your app is compatible with it) and avoid touching JWT with a ten-foot pole or querying third-party services.

@U2FRKM4TW What's wrong with JWT?

wait, what? storing sessions in the browser cookie is totally fine and the default in a bunch of frameworks. the trouble is that it's harder to get right (you need to hmac sign the contents, deal with expiration and invalidation, etc, keep the size down, etc) and so if you're new to things it's often easier to store the session server-side.

One article about JWT: http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/ Thomas Ptacek (a professional security researcher) has written a lot on the topic, especially if you include HN comments. Plenty of things that are wrong with JWT or with using cookies for storing stateful sensitive data instead of a pointer to that data. Some cannot be mitigated by design, some can be but are often not, because regular software engineers aren't that deep into the security rabbit hole.

i have both good and bad experiences with jwt based sessions. but the good ones are mostly in cases where session tokens are issued and verified by different applications which simply don't have access to each other's data stores (hence can't pop the hood of the storage to check if the provided data is true).

i would agree with @U2FRKM4TW - unless you have a very specific use case, do not use jwt for sessions. it makes sense for handovers or certain authentication schemes. it's a bad choice in a scenario in where a simple cookie storing session id would do.

for good cookie security you need more than a session id, though. it needs to be hmac signed and have a (relatively) short expiration within that signed payload in order to prevent a bunch of different attacks. your overall max session time can be longer you want to be deliberate about how long you let a cookie live (and never trust the client to expire it)

A session ID doesn't have to be signed. It just has to be random enough. An appropriate comment by tptacek: > In our practice, password reset tokens and encrypted session cookies continue to be the top source of exploitable crypto vulnerabilities in web applications. You don't need encryption to build either of these features; send 128 bit random numbers that key a database row instead.

yeah that part i must admit i don't quite follow. if i can steal the cookie i can pretty sure steal the added signature too.

the signature prevents tampering and validates that you signed it (meaning no guessing at session ids and the cookie came from you). you have the expiration as part of the payload that is signed so it, too, cannot be tampered with. db sessions are just complicated in other ways that cookies don't have to deal with

also, to be clear, I wasn't advocating for JWT. both methods, client and server side, take care to manage appropriately. the only things I can think of that are more difficult in cookies are forcing logouts for specific clients (for cookies you'd need essentially need to also have server sessions in order to achieve this) and getting visibility into everyone with active sessions. on the flip side it's nice not to have to manage a session store

guessing a 128bit or even longer cookie id is just as hard 🙂

just to be clear - what i had in mind was a cookie id similar to a long hash or uuid v4, not the sequential value of numbers from someone's database

the signature and expiry timestamp might make sense if you want to avoid the trip to an expensive or slow storage (adding a bit survivability in the case of an attack) ... but if someone was convinced to ddos you they would then pick an existing cookie and hammer you with that instead.