7 ms·

I've read several articles along these lines now I tend to think the arguments are pretty weak. In this media rich age, the data size argument is a bit silly.

• kodablah 8y ago
  I concur with the author about session usage of JWT since it has little value (and if you did, just use it for it's signing feature and still have it just contain a random session identifier). The reasons for defending it in that use seem to be about what's not bad, but rarely about what's good. But JWTs have value for API tokens as they can embed an expiration date for the caller in a known format. But the idea of stateless JWTs with a bunch of valid data for use on successive calls by the server is a bit much. You should contact your auth store of record per invocation for various reasons. Like you said, be aware of the issues with chosen sig algorithms and be exact on what you choose and just leverage JWT as the format, not blindly following the generation libraries without investigation.
  • madeuptempacct 8y ago
    "about session usage of JWT since it has little value " Two weeks ago, I stood in front of a room full of senior developers and architects and asked them "How will we avoid making a leading 'Does the user have permissions?' call or wrapping the request in a try catch in case the user doesn't have access without JWT claims. They all got mad. Then they conceded that they don't have a solution. Do you have a solution? If not, you can't replace JWTs.
    • tyleraldrich 8y ago
      But... that's not really something you _have_ to avoid. Check permissions, if they fail the test -> http401 (for an API) or some user-friendly redirect. Something similar to this is how things work without JWT currently, so it's only a problem if you make it one.
      • madeuptempacct 8y ago
        You seriously think making a redundant call or wrapping every. single. controller into a try-catch is better than having claims pulled out in a request pipeline (before even touching the controller) and doing `if(hasAccess){do thing} else {unauthorized}`?
        • CiPHPerCoder 8y ago
          It sounds like you're arguing from a very specific mental model of an ACL workflow. In my CMS, I had support for granular permissions. So you could do this: if ($user->can('update')) { if ($postData) { $this->processUpdate($postData); } // display edit form } elseif ($user->can('read')) { // read-only } else { return error_403_condition(); } JWT wouldn't have helped much.
          • madeuptempacct 8y ago
            I will look into this more and come back with what I figure out later on. Thanks.
        • X-Istence 8y ago
          That looks similar to a try/catch... You just called it if/else. Also, why can't you make the database request in the request pipeline, right before that "if(hasAccess)" statement. You don't need JWT for this... You are already wrapping all of your controllers...
        • patates 8y ago
          If your controllers are asp.net mvc controllers you can decorate them with permission attributes (see the relevant docs for your version). Pretty sure most frameworks have a way to structure your code for permission checking.
• CiPHPerCoder 8y ago
  I've been fond of [1] and [2] for a more focused argument against JWT for sessions. The JOSE standards (of which JWT is a member) are error-prone and have had numerous critical security-affecting bugs due to how they were designed. [3] To remedy that, I proposed PASETO. [4] I still don't recommend PASETO for sessions, because of the arguments laid out in [1] and [2]. [1] http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/ http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-fo... [2] http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/ http://cryto.net/%7Ejoepie91/blog/2016/06/19/stop-using-jwt-... [3] https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-ba... [4] https://paseto.io https://paseto.io
  • rdegges 8y ago
    +1 There are so many arguments against JWTs as session tokens. It's just so long and so much work to describe all of it and respond to each argument against each one. Sven does the best possible job of summarizing it up. Also: PASETO is really fantastic, thanks for creating it! I've started mentioning it in my talks and using it for internal projects -- I really enjoy it so far =)
  • baybal2 8y ago
    "alg": "none" comes to mind. Azure had it unpatched for close to a year. God knows how many corporate mailboxes and contact directories flew through that hole that went largely underreported. All what attacker had to know was the id number of the app that got previously preapproved, a trivial thing, given that it was given out in oauth requests for user permissions. The industry will continue pay a dear price for mixing the rogue and unruly realm of web development, with what previously was a domain very conservative "enterprisey java development shops" where everybody dresses in a suit, and at least have some formal CS background above bootcamp course.
• sgslo 8y ago
  I have trouble understanding why session invalidation with JWT's is challenging. The JWT itself contains an IAT (issued at time) describing when the token was created. To invalidate all sessions, you can store (in your DB, or other persistence service) a 'invalidated at' date. Any request with a JWT that was issued before this 'invalidated at' date can be considered to be invalid.
  • CiPHPerCoder 8y ago
    > I have trouble understanding why session invalidation with JWT's is challenging. Imagine you're connecting to a service that uses JWT for sessions so they don't have to store anything server-side. Let's say you have a token with an IAT of yesterday and and EXP of, say, a month from now. Further, your browser gets infected with malware and the attacker steals your token. You rebuild your computer from a fresh install. How does the service invalidate the token while still being stateless? It has 30 days left. Your next move is: > _
    • jrs95 8y ago
      You should have tokens with short durations that are refreshed upon use. That greatly reduces the odds of a token being stolen or leaked and then used before it expires.
      • CiPHPerCoder 8y ago
        You're getting closer to the problem: JWTs were designed to be single-use (or very, very short lived) claims (with optional cryptography features). It was never meant to be "offload everything to the client and obviate the need for server-side storage". It was never meant to be the new hotness among the NoSQL Scalability crowd.
  • hobls 8y ago
    Sure, but then you’re calling your DB to validate the JWT every time anyway. You’ve just removed the whole “JWTs are cool because they’re stateless” benefit.
• xae342 8y ago
  For signout we use token and user revocation lists represented as bloomfilters that services can poll or query directly if they need more consistency. This actually does work well in practice at very large scales efficiently we found.
• deleted 8y ago
  [deleted]
• rawoke083600 8y ago
  "In this media rich age, the data size argument is a bit silly." I couldn't agree more !! Its just so much easier to do JWT specially if you got more than one server(api)
• lvh 8y ago
  > The "you're going to hit the database anyway" argument whilst probably accurate in most cases, doesn't invalidate that JWT allows for one or more fewer database hits on every request. Using random session cookies does not prevent you from using caches. > In this media rich age, the data size argument is a bit silly. JWTs aren't cached, and cookies are sent on every request, so there's a much bigger multiplier on JWT size cost than there is on media size cost.
• inlined 8y ago
  I think the most important part of that is "you're going to hit THE database". A single session token is more efficient but tightly couples all services. There's a single point of failure at whichever server does auth. Unlike JWTs, degradation or outages in token servers ripple through the whole system. So when would you use session tokens? When you have a small application that you confidently predict will never outgrow being a monolith.
• _asummers 8y ago
  For invalidating, you just need to store the JTI (id, as a UUID) of the token in the DB. On challenge, you just compare the JTI of provided token to the one stored, and if there's a mismatch you 401. For doing the actual revokation, you can just clear the active JTI and have app code that would reject that. It's certainly arguable if this is worse or better than session tokens, but it's not unsolvable.
  • CiPHPerCoder 8y ago
    It's not unsolvable, just incompatible with the premise of "use JWT for sessions" which is to avoid the database hit entirely.
  • deleted 8y ago
    [deleted]
  • Dirlewanger 8y ago
    Yup, I can't believe the author didn't go over something like this. It's the perfect use for the JTI. Put it as a column on your users table and all set. We use a Ruby authentication library that does exactly this.
• jondubois 8y ago
  >> IMHO the biggest argument against the use of JWT is that you can't easily invalidate JWT sessions That's true. JWT is great for WebSocket connections because you can make the expiry really short (you could even make it 1 minute) and you could re-issue a new token in real-time every 50 seconds just before the previous one expires. Then if the user goes completely offline for 1 minute, then they lose their session (the JWT becomes invalid).