81–90 of 170 posts
This is absurd -- the total amount of data I needed to store in the JWT was about 10 bytes.
This inefficiency bloats requests. At a time when we're migrating to http/2, which which deliberately reduces headers to speed things up, JWT is going in the other direction.
Earlier quoted context omitted.
Like JSON? I think for some acronyms, JSON and JWT included, those are their "proper" names, with the expanded name being just a curious historical note.
I'd say it's good writing to link to the wiki entry for a less common concept like JWT in the first paragraph, right next to where they first mention it. It's definitely not ubiquitous like JSON, SQL, or FBI.
Earlier quoted context omitted.
depends on if need to call other apis like microservices, you can use the JWT on behalf of the user to request the contents from other services. JWT also introduces `scope` which determine services user consented and allowed your backend to call. These things are not supported by a simple session cookie.
I mean they're not supported OOB but you're just describing a session cookie with some signed metadata. If "the ecosystem" and interoperability with existing services is the goal then has the advantage. If you're talking about something bespoke then it probably doesn't.
Isn't that JWT?
Can we finally stop conflating an encoding/signature/encryption method with a transport/storage mechanism?!
JWT is not awesome. I spent yesterday implementing it. The smallest usable JWT I could create was 137 bytes, not including the Authorization header. This is absurd -- the total amount of data I needed to store in the JWT was about 10 bytes. This inefficiency bloats requests. At a time when we're migrating to http/2, which which deliberately reduces headers to speed things up, JWT is going in the other direction.
I've found that arbitrarily re-inventing the wheel because a new thing becomes popular should be done deliberately and with great caution. More generally - I think it's important to look for solutions to fit a specific problem, not problems to fit a specific solution.
However, back to JWTs - I'm currently using them for authorization in an EXTREMELY high traffic websocket server implementation. It's really nice because it's short duration (the ones I am issuing have a expiration of 60 seconds), and allows the service to operate entirely within memory except for interacting with a Kafka cluster.
- to revoke a JWT you have to blacklist it in the database so it still requires a database call to check if it's valid.
- JWT are to prevent database calls but a regular request will still hit the database anyway.
- JWT are very large payloads passed around in every request taking up more bandwidth.
- If user is banned or becomes restricted then it still requires database calls to check the state of user.
- JWT spends CPU cycles verifying signature on every request.
- JWTs just aren't good as session tokens which is how a lot of web developers try to use them as. Use a session ID instead.
Where JWT works best:
- when a client can interact with multiple services and each service doesn't need to do a network request to verify (ie federated protocols like OpenID). The client verifies the user's identity via the 3rd party.
- as a 1 time use token that's short lived, such as for downloading files where user gets a token requested from auth server and then sends it to the download server.
The string 'JSON Web Token' doesn't appear anywhere on the web page. If you're going to use an acronym expand it out the first time you use it.
I expected this to be about Java Web Toolkit until I saw it was implemented in many languages.
JWTs have made client side auth integrations look better. But the problem is that common security considerations and implementation details are generally overlooked. 1. Tokens are typically stored in localStorage. (app becomes vulnerable to CSRF & XSS attacks). 2. Tokens can be stolen. Now this is generally controlled by having a very short expiration time. 3. Short expiration times mean persisting refresh tokens to…
Earlier quoted context omitted.
That video is ridiculous. The whole time is spent talking about how cookies are superior to local storage which has little to do with JWT. You can use JWT and store it in a cookie. Session cookies are most certainly not automatically signed. Signing a session ID provides absolutely no value (signing claims, however, does). Revocation is exactly the same for both of them. JWT has a standard jti field for the session I…
If you cryptographically sign the session cookie, as suggested in the video, then you accomplish the exact same thing as a JWT token - so, then why use JWT at all, if you going to look up the session data from the database in any case. JWT was meant to be stateless, if it's not, then it's just a layer of unnecessary complexity with potential security and implementation flaws.
It's possible to add additional information in a JWT. And of course it's complexity that adds additional attack surface, but at least there is some kind of standardization around it.
Was about to write a rant that it's still not better than cookies & sessions, something that has been standard waay longer than JWT. But this video says all I have to say (2018): https://www.youtube.com/watch?v=JdGOb7AxUo0 1 sec takeaway (More in the video): https://i.imgur.com/vUYTYfS.png That said, JWT's are great for stuff like 2-Factor via email link or redirecting from one domain to another. Single use, which it…
I've written such a rant almost a year ago. [1] The article shows how to build a « RESTful » API secured with sessions implemented using regular cookies: simpler & without unnecessary complexity. [1]: https://zaiste.net/creating-secure-rest-api-nodejs-without-j...