4 ms·

>> A lot of developers try to use JWT to avoid server-side storage for sessions. This is based on what? Sounds like he just made it up. His other claims does n

>> A lot of developers try to use JWT to avoid server-side storage for sessions. This is based on what? Sounds like he just made it up. His other claims does not look sound to much more either. I would like to see a more in-depth analysis on the subject, this all looks very hand-wavy to me.

jondubois 10y ago
Agreed, the author of the article shouldn't point out a few flaws/bugs that some JWT libraries had in the past and then deduce that the whole standard is broken at a fundamental level. JWT is not designed to hold sensitive data, it's designed to hold non-sensitive authentication information like usernames, access groups, privilege levels, and other similar non-sensitive identifying information. It's useful because it loosens your reliance on back-end memory stores like Redis to track session data and makes your architecture much cleaner/simpler.
stephenr 10y ago
> This is based on what? Based on the entire reason JWT is even a thing? Developers love to believe every app they build is going to run at the scale of Facebook to the power of Google times Twitter, and thus needs to run on 10,000 Docker instances spread across 15 data centres around the globe (and soon, one on the moon!). Relying on server-side sessions is "terrible" because you have to talk to the backend, and you need to keep the data synchronised in a manner that all 10,000 Docker instances can read/write to it instantly. So instead, a new concept was devised, whereby you use these stateless tokens that don't rely on the same server after issuing. Of course, it's impossible to invalidate them individually, and they're either insecure (available to JS) or stored in a cookie, and thus sent with every request, which means, due to their larger size than regular session cookies, more data on each request. So.. that. That is what it's based on. Edit: added missed word "same".
- robertlagrant 10y ago
  I wouldn't say it's impossible to invalidate them individually. It's certainly more effort, and it's probably better to have short-lived session tokens and refreshing, but I think it can be done. E.g. what about a message bus that publishes an invalid token message that is subscribed to by the API-providing systems, so they can maintain a prematurely-expired tokens list? On the keeping info in Javascript vs keeping it in a cookie issue, I don't understand that so well. If you made the token a private member of an object that was responsible for the calls, would that help? Then no code could access it?
  - stephenr 10y ago
    > I wouldn't say it's impossible to invalidate them individually It's impossible to invalidate individual "stateless" JWT's. If you have a server-side "blacklist", guess what: you're not stateless any more, because you still need to keep data in sync, and now you're tempted to allow some otherwise unacceptable delay for sync, giving a potential attacker more time with a stolen JWT. Plus, you know, defeating the whole purpose of using JWTs (being stateless). > On the keeping info in Javascript vs keeping it in a cookie issue, I don't understand that so well. Cookies can be set HTTP only. They're sent to the browser, and it will send them back when making requests as per usual, but they're not exposed to JavaScript, at all. There is 0 way for malicious (or non malicious) client side code to see these cookies, thus 0 way for malicious javascript to steal one used as a session cookie. > If you made the token a private member of an object If the data can be read from the network by your JavaScript, it can be read from the network by their JavaScript.
    - robertlagrant 10y ago
      (Feel free to bail on this at any time if my questions/suggestions become tiresome :)) > If you have a server-side "blacklist", guess what: you're not stateless any more, because you still need to keep data in sync, and now you're tempted to allow some otherwise unacceptable delay for sync, giving a potential attacker more time with a stolen JWT. Plus, you know, defeating the whole purpose of using JWTs (being stateless). While I agree that it's no longer stateless, JWT's still really useful in terms of not needing a centralised auth/auth provider that everyone has to hit to see if I am who I say I am and whether I'm allowed to call an API. And a message bus is a pretty good compromise between the extremes of big wide systems that share state and microservices that don't talk to anything else. > Cookies can be set HTTP only ... session cookie. Thanks - I get what you're saying. > If the data can be read from the network by your JavaScript, it can be read from the network by their JavaScript. Yeah. I think I see what you mean. Assuming you don't mean literally "reading data from the network", as I assume the problem isn't the network access but the access to the security info, are you saying that hostile Javascript on the page can read everything and call everything that legitimate Javascript can? If so, I can't tell the difference between that and - say - a CSRF token, which presumably can also be read by "their" Javascript? How does anything work if you have that mentality?

jondubois 10y ago

Agreed, the author of the article shouldn't point out a few flaws/bugs that some JWT libraries had in the past and then deduce that the whole standard is broken at a fundamental level. JWT is not designed to hold sensitive data, it's designed to hold non-sensitive authentication information like usernames, access groups, privilege levels, and other similar non-sensitive identifying information. It's useful because it loosens your reliance on back-end memory stores like Redis to track session data and makes your architecture much cleaner/simpler.

stephenr 10y ago

> This is based on what? Based on the entire reason JWT is even a thing? Developers love to believe every app they build is going to run at the scale of Facebook to the power of Google times Twitter, and thus needs to run on 10,000 Docker instances spread across 15 data centres around the globe (and soon, one on the moon!). Relying on server-side sessions is "terrible" because you have to talk to the backend, and you need to keep the data synchronised in a manner that all 10,000 Docker instances can read/write to it instantly. So instead, a new concept was devised, whereby you use these stateless tokens that don't rely on the same server after issuing. Of course, it's impossible to invalidate them individually, and they're either insecure (available to JS) or stored in a cookie, and thus sent with every request, which means, due to their larger size than regular session cookies, more data on each request. So.. that. That is what it's based on. Edit: added missed word "same".

robertlagrant 10y ago
I wouldn't say it's impossible to invalidate them individually. It's certainly more effort, and it's probably better to have short-lived session tokens and refreshing, but I think it can be done. E.g. what about a message bus that publishes an invalid token message that is subscribed to by the API-providing systems, so they can maintain a prematurely-expired tokens list? On the keeping info in Javascript vs keeping it in a cookie issue, I don't understand that so well. If you made the token a private member of an object that was responsible for the calls, would that help? Then no code could access it?
- stephenr 10y ago
  > I wouldn't say it's impossible to invalidate them individually It's impossible to invalidate individual "stateless" JWT's. If you have a server-side "blacklist", guess what: you're not stateless any more, because you still need to keep data in sync, and now you're tempted to allow some otherwise unacceptable delay for sync, giving a potential attacker more time with a stolen JWT. Plus, you know, defeating the whole purpose of using JWTs (being stateless). > On the keeping info in Javascript vs keeping it in a cookie issue, I don't understand that so well. Cookies can be set HTTP only. They're sent to the browser, and it will send them back when making requests as per usual, but they're not exposed to JavaScript, at all. There is 0 way for malicious (or non malicious) client side code to see these cookies, thus 0 way for malicious javascript to steal one used as a session cookie. > If you made the token a private member of an object If the data can be read from the network by your JavaScript, it can be read from the network by their JavaScript.
  - robertlagrant 10y ago
    (Feel free to bail on this at any time if my questions/suggestions become tiresome :)) > If you have a server-side "blacklist", guess what: you're not stateless any more, because you still need to keep data in sync, and now you're tempted to allow some otherwise unacceptable delay for sync, giving a potential attacker more time with a stolen JWT. Plus, you know, defeating the whole purpose of using JWTs (being stateless). While I agree that it's no longer stateless, JWT's still really useful in terms of not needing a centralised auth/auth provider that everyone has to hit to see if I am who I say I am and whether I'm allowed to call an API. And a message bus is a pretty good compromise between the extremes of big wide systems that share state and microservices that don't talk to anything else. > Cookies can be set HTTP only ... session cookie. Thanks - I get what you're saying. > If the data can be read from the network by your JavaScript, it can be read from the network by their JavaScript. Yeah. I think I see what you mean. Assuming you don't mean literally "reading data from the network", as I assume the problem isn't the network access but the access to the security info, are you saying that hostile Javascript on the page can read everything and call everything that legitimate Javascript can? If so, I can't tell the difference between that and - say - a CSRF token, which presumably can also be read by "their" Javascript? How does anything work if you have that mentality?