91–100 of 135 posts
There are other ways to pass claims -- like using bearer tokens in the HTTP header, or using OAuth 2. (All with TLS, of course)
JWT is just a standard for bearer tokens (including those used by OAuth 2).
Earlier quoted context omitted.
Saying "all security software has flaws" advantages the software with the most flaws and disadvantages the software with the fewest number of flaws. There are many, many better solutions for the problem JWT solves, there are not many better solutions for X509, which is why people keep using X509. It is significantly more difficult to misuse e.g. golang.org/x/crypto/nacl/secretbox than JWT.
I never said "all security software has flaws," since that has a substantially different meaning than my comment. While I'm not arguing with your statement regarding ease of misuse, you should also consider the trade-offs. It's also significantly easier to misuse a pocket knife than a butter knife for the same reason. Butter knives are designed for a small set of problems and deliberately have duller edges to avoid s…
I have seen JWT implementations at five or six different companies now, tokens have never been used for more than one use case. For each specific use case you'd actually want to use it with there is a better solution that doesn't involve JWT, like secretbox or HMAC-SHA256.
Found this amusing. Are node devs so used to async that disclaimers like this are necessary?
Earlier quoted context omitted.
Why would you arbitrarily reject a token refresh? The question here is which token to reject. That's where the state comes in. If a token is compromised, you have to know which one. Hence, stateful.
> Why would you arbitrarily reject a token refresh? You've misread what I've said. The server can trigger token refreshes by rejecting the request. According to the JWT workflow, that triggers the client to request a new token and retry the request. > The question here is which token to reject. That isn't much of a question, because servers are free to reject any token arbitrarily. They can, however, ignore specific…
1) A token gets compromised.
2) You know which token. You need to revoke access.
3) You introduce state by storing said token on disk / in memory somewhere.
Key takeaways:
1) The authentication system (not the token) is now stateful. 2) You now have to check this data store to properly allow authentication. 3) A core benefit of JWT (stateless auth) is gone.
Earlier quoted context omitted.
not sure if that was the point or not, but it's wrong. even if you did sign/encrypt, that's not a benefit over a standard cookie. you can easily sign or encrypt a 'standard cookie' as well. the benefit is the portability that comes from a standardized and widely used data structure.
You say that as if cookies haven't been a standardized and widely used data structure (key-value store) for decades.
> Note: Yes, both these methods are synchronous. But, given that neither of these methods require any I/O orNetwork requests, its pretty safe to compute them synchronously. Found this amusing. Are node devs so used to async that disclaimers like this are necessary?
Earlier quoted context omitted.
There are a number of easy-to-make mistakes with all security software. That doesn't mean it's not worth using; it just means that we should build the tooling we need in the open as shared software, so that the wisdom of crowds prevails. Almost exactly the same set of problems exists with signed x509 certificates, but I doubt anybody would tell you not to use them. They'd just say "make sure you don't implement your…
Saying "all security software has flaws" advantages the software with the most flaws and disadvantages the software with the fewest number of flaws. There are many, many better solutions for the problem JWT solves, there are not many better solutions for X509, which is why people keep using X509. It is significantly more difficult to misuse e.g. golang.org/x/crypto/nacl/secretbox than JWT.
There is definitely a UX issue though, and—without intending to be disrespectful—junior devs coming into programming through Javascript, or building basic microservices, are going to see a lot written about JWT and how easy it can be to work with, and suddenly JWT is the solution.
The API for JWT in most cases is encode/decode, and you provide the payload, the options, and the key. The API for libraries linked with OpenSSL is typically a lot more verbose, so you have to understand what you need to work with, or how you might need to extract a fingerprint, convert to DER, or whatever.
Beyond that, a lot of us in the web world might associate X509 with SOAP and XML, and plenty of people will avoid XML at all costs by virtue of it being XML. There's no reason why you couldn't use X509 in a JSON payload.
JWTs are useful, but there are a few things that are not immediately obvious. 1) They are signed not encrypted. Anything you put in there is public readable, unless you encrypt your token after you generate it 2) you can accept a range of encryption types, don't. Stick to one type and disallow any token that doesn't conform (this protects against people making their own tokens with 'None' as the signing algorithm) I…
> 1) They are signed not encrypted. Anything you put in there is public readable, unless you encrypt your token after you generate it Not a JWT expert but isn't this the point of a JWT or am I missing something. Sharing data between servers & clients while being able to make sure the data wasn't changed. > 2) you can accept a range of encryption types, don't. Stick to one type and disallow any token that doesn't conf…
Re 2), JWT libraries often make it easy to ask "is this token valid?" And I don't think it's unreasonable to think that "validity" means "signed by the shared secret I set in this library's configuration". But it usually doesn't. It usually means "this token is internally consistent". And since alg=None is a an option most people would probably assume would not exist, much less be counted as "valid", then it's not surprising that this happens.
Basically, JWT's rendered format ensures it will be misunderstood and misused, so long as the available libraries don't enforce reasonable expectations. And from what I've seen, the library situation for JWT is pretty ugly, making a confusing standard even more confusing, instead of less so.
Earlier quoted context omitted.
I recently started using JWT and had the same problem, I ended up keep the expiration very low and having the client constantly refresh when they need it, and just forget it when they don't
This is a very popular conclusion when considering AuthN and invalidation. Keep the state at the provider and just prevent issuance of new tokens (whether signed certs, JWTs, etc) if/when the user requests access be revoked. What you're really doing is externalizing your state to one already universally shared, and which we already have a lot of tools to manage: the current time.
Having tokens with an expiry of e.g 10 minutes, but with no ability to revoke, is a totally reasonable trade-off in these circumstances.
Earlier quoted context omitted.
There are also a number of easy-to-make mistakes or gaps which can be introduced with the use of JWTs. https://twitter.com/ejcx_/status/1063846166029197312 provides a great list of test cases covering the commonly reoccurring flaws. The number and seriousness of these errors and how easy it is to make them does raise questions about how sensible it is to use JWT, unless you're really sure about what you're doing.
There are a number of easy-to-make mistakes with all security software. That doesn't mean it's not worth using; it just means that we should build the tooling we need in the open as shared software, so that the wisdom of crowds prevails. Almost exactly the same set of problems exists with signed x509 certificates, but I doubt anybody would tell you not to use them. They'd just say "make sure you don't implement your…
As a telling example, compare JWT to Macaroons, a standard built effectively on one extraordinarily simple cryptographic primitive that is simultaneously safer and does more than JWT.
From the vantage point of cryptographic security engineering, JWT is a cargo cult. Most projects would be better off avoiding it entirely.