Hi all! designing sessions is very essential for all modern webapps, however there is very little discussion about it. Let's assume that a webapp uses HTTPS by default (i.e. no worries about eavesdropping or modifying cookies).
Let's say I just want to design a session that stores only user id, what's the best method to design sessions? from what I know:
Web based sessions:
clearly the main disadvantage is I have to go to the database every http request and check the session ID. Sure I can use Redis to cache session ids, but also I have to implement a write through logic if I happen to update the session content so that Redis and the DB are synchronized
Django's approach
just generate a random session id (long enough let's say more than 20 ascii chars) and store it in a cookie.
Express session's approach
same as Django but also adds HMAC to the session id cookie (isn't this redundant for a HTTPS connection?)
Client based sessions:
JWT
lots of hate and critic about it even though it sounds pretty secure and more performant, and I am not sure how many respectable websites that actually implement it
What do you recommend? what's the current recommended method for designing session logic for a website (hopefully that could be extended to a mobile app) in 2018?
Top comments (6)
Don't you still need the server side if you only store the user id? If you store a single token / user id / session id you still need to look that up on the server.
If you need to keep a user session, what's wrong with just using sessions :D ?
I'm not sure with which technology you're programming but basically every major framework has the session management logic for free and, for example with Rails, you can handle cache and db more or less transparently.
Yes, but if I use server based sessions, I have to lookup the session id from the session table first, then get the user id from the session content, then lookup the user by its id in the users table. I have to do an additional lookup in the database for each request. But with JWT, I already have the user id inside it.
It depends on what you want to do.
If on the client there's only the user id and no other information you don't need JWT, you can just use a join on the server to issue one select to find the data from the session id.
If you "trust" the JWT token containing a user id and that's your only entry point to validate the user session then you have a security issue because if the JWT is stolen first you won't know it and second the attacker can impersonate the other person.
This is my favorite post on the topic of JWT: cryto.net/%7Ejoepie91/blog/2016/06...
Anyhow in general I wouldn't recommend creating your own authentication framework, at least for security reasons is more like that battle tested frameworks have more eyes on that issue.
What framework are you using?
thought of doing this, but this means I will end up writing my own session logic anyway, right?
Doesn't this apply exactly the same to server based sessions? If the session id or the cookie containing the session id was stolen, the attacker can very easily impersonate the victim just by adding it to his cookies.
I am using Express 4/Node.js
Exactly, which I would avoid.
Yes, exactly. So why not just use an existing implementation? JWT are not secure by default, you need to put them in a secure httponly cookie which is basically what you're going to accomplish by using sessions anyway.
JWT is just a token, it's not magically secure.
For Node.js maybe Express Session will do?
A tutorial: medium.com/of-all-things-tech-prog...
ps. I'm not trying to say "never use JWT" it's just that I don't see the benefits in this particular case
those people reacting to the post without any discussion are really weird, do you think this is an article or something?