21–30 of 304 posts
This post says "it's insecure if you do it wrong". Well.....
It's a pretty good plus, for me: no additional round-trips to the server to grab key user details, which can be put into claims, or check access levels (via roles, permissions, or other types of claim).
This doesn't discount the disadvantages, of course.. I think as with everything it's a case of the right tool for the job. "Depends on the use case".
JWT is bad, signed tokens are fine. Session cookies suck and don't scale. Just copy code of MessageVerifier from Rails, it's simple.
One advantage I think not mentioned by some of the linked articles is that the JWT's claims are readable on the client. It's a pretty good plus, for me: no additional round-trips to the server to grab key user details, which can be put into claims, or check access levels (via roles, permissions, or other types of claim). This doesn't discount the disadvantages, of course.. I think as with everything it's a case of th…
Earlier quoted context omitted.
> The only problems you highlighted are serious input validation issues and a naive, broken trust model. If these things are suggested in the standard and promptly followed by major implementations, then the standard isn't very good.
But they aren't. Nobody is suggesting to anybody to use NONE as the algorithm.
https://www.rfc-editor.org/rfc/rfc7518.txt
Still, my point about it missing from RFC7115 stands.
---- Original comment ---------
The standard says you should support NONE as the algorithm and that you should use the algorithm the client sends you, all the while completely failing to mention the issues with that, both in its Security Considerations section (which mentions even more "obvious" things like "use keys with high entropy") and in the description of the algorithm to decode a token (which initial implementers probably relied upon to get to a "correct" implementation). Sorry, that is a failure of the spec as well in my book.
If you spec something with risks, at least mark the critical parts clearly with "point away from foot".
A better standard IMHO would have suggested the API for the decode functions, making it clear that the algorithm used should be whiteli
One advantage I think not mentioned by some of the linked articles is that the JWT's claims are readable on the client. It's a pretty good plus, for me: no additional round-trips to the server to grab key user details, which can be put into claims, or check access levels (via roles, permissions, or other types of claim). This doesn't discount the disadvantages, of course.. I think as with everything it's a case of th…
Out of interest, do you check the authenticity and integrity of the JWT on the client side?
But, if you're just hiding an additional Delete button on a page based on claims, this comes in handy.
(Edit: in one case, we've used asymmetric keys, i.e. public key so everyone can check integrity. This was a very different use-case to most web apps, though. Overall I'd say if you're carefully checking integrity of something in client-side JS to do something, I think that's probably the wrong approach)
The "none" algorithm set in header is a well known problem and, for example, nodejs most used library automatically uses asymmetric keys when one is given, ignoring the header ( https://github.com/auth0/node-jsonwebtoken/blob/master/verif... ) As long as the problem is known to the developers and the key is specified, I think the biggest issue of JWT is the lack of session invalidation (that is, if you log out your a…
For me, the log out / cross device session management issue seems to force a pattern of short expiry with self refreshing tokens. Commonly used devices feel always logged in, whereas uncommonly used devices end up needing a fresh log in each time.
0: https://www.chosenplaintext.ca/2015/03/31/jwt-algorithm-conf...
The approach I use is to have a 'use once' refresh token (long timeout) and a security token (short time out) and JTIs to hold a list of logged out/invalid (refresh token used twice) security token IDs.
The "none" algorithm set in header is a well known problem and, for example, nodejs most used library automatically uses asymmetric keys when one is given, ignoring the header ( https://github.com/auth0/node-jsonwebtoken/blob/master/verif... ) As long as the problem is known to the developers and the key is specified, I think the biggest issue of JWT is the lack of session invalidation (that is, if you log out your a…
Session invalidation is possible though, by maintaining a (short) blacklist of tokens on the server. JSON Web Tokens can be given an ID (via the jti claim), and server-side these IDs can be matched against this blacklist. When you log out, you send a request to the service that your current token be blacklisted. Because JSON Web Tokens are short-lived, the blacklist need only contain tokens valid for validity period…