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.
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.
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.
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.
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.
you can just use a join on the server to issue one select to find the data from the session id.
thought of doing this, but this means I will end up writing my own session logic anyway, right?
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
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.
thought of doing this, but this means I will end up writing my own session logic anyway, right?
Exactly, which I would avoid.
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.
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.
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