This article describes using JWT in a web-server environment where session cookies are likely a better solution.
JWT and Stored Sessions have their place.
If you are running a single web server and your client is connecting via a webpage (or possibly an app), then storing session data in a key-value store is probably a better solution.
If you've got multiple (micro) services being accessed via an API, I say JWT all the way.
JWT's can be expired (which the author does not address), expiring does not mean the user needs to login again. The app logic can request a new JWT based on some internal logic, maybe the user needs to login, or maybe they just get issued a new JWT.
If your JWT key is compromised, you've likely compromised something else on your system as well. You are no longer secure and need to do something about it. JWT is the least of your worries at this point.
The "cannot push messages" doesn't make any sense to me. If you're polling the server, you poll with the JWT, the server unpacks it and sees which user made the query. You can put anything you want into a JWT. Which leads to the next point.
Data overhead... really? I just checked our JWT, which has some data about user, expiration, permissions and it's 200 bytes. You can add much more data and you still won't likely hit the 1kb data. Even if you did. 1kb it's 1kb, I'd suggest that is if you are being irresponsible and putting way too much into the JWT itself.
I'm not saying JWT is perfect, as I said, a simple website, use sessions, but the way Rahul has picked apart JWT is like a chef trying to cut a cake with a spatula. It works, but you're better off using a knife.
1 comment
[ 4.2 ms ] story [ 9.3 ms ] threadJWT and Stored Sessions have their place.
If you are running a single web server and your client is connecting via a webpage (or possibly an app), then storing session data in a key-value store is probably a better solution.
If you've got multiple (micro) services being accessed via an API, I say JWT all the way.
JWT's can be expired (which the author does not address), expiring does not mean the user needs to login again. The app logic can request a new JWT based on some internal logic, maybe the user needs to login, or maybe they just get issued a new JWT.
If your JWT key is compromised, you've likely compromised something else on your system as well. You are no longer secure and need to do something about it. JWT is the least of your worries at this point.
The "cannot push messages" doesn't make any sense to me. If you're polling the server, you poll with the JWT, the server unpacks it and sees which user made the query. You can put anything you want into a JWT. Which leads to the next point.
Data overhead... really? I just checked our JWT, which has some data about user, expiration, permissions and it's 200 bytes. You can add much more data and you still won't likely hit the 1kb data. Even if you did. 1kb it's 1kb, I'd suggest that is if you are being irresponsible and putting way too much into the JWT itself.
I'm not saying JWT is perfect, as I said, a simple website, use sessions, but the way Rahul has picked apart JWT is like a chef trying to cut a cake with a spatula. It works, but you're better off using a knife.