15 ms·
JWT is Awesome
- owaislone 7y agoJWT is great for some use cases but if you need auth to be very centralized, just use one of the existing auth mechanism instead of bolting it on top of JWT. I don't see what would be the point of using JWT if you need highly centralized auth. Where JWT shines is when the auth service does not need to know the clients that might want to authenticate using it. A system where it can issue tokens to any other service on behalf of a user and say, "here you go, you can use this for the next N minutes". This is very useful when it's not practical for every service/client to "register" itself with the auth service before hand like oauth.
- 0x445442 7y agoThe 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.
- icebraining 7y agoLike 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.
- TOGoS 7y agoThen at least link the first instance to the Wikipedia page or something. After reading the first couple of paragraphs I had no idea what this article was about.
- cjf4 7y agoI agree for JSON, not JWT.
- Sharlin 7y agoI had never heard of JWT and I definitely know what JSON is. I don’t think they’re anywhere near each other in ubiquity.
- hombre_fatal 7y agoI'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.
- icebraining 7y agoRight, linking to the wiki makes sense. I just don't think expanding the name gives you anything.
- onionisafruit 7y agoI expected this to be about Java Web Toolkit until I saw it was implemented in many languages.
- tshannon 7y agoIt was obviously about the James Webb Telescope.
- Rebelgecko 7y agoFWIW I've only seen that abbreviated as JWST
- abhgh 7y agoThats what I thought too.
- user5994461 7y agoFair point. I added it at the beginning. JWT will be as ubiquitous as JSON eventually but it's not quite there yet.
- 725686 7y agoI highly recommend watching "Deconstructing REST Security" by David Blevins: https://www.youtube.com/watch?v=9CJ_BAeOmW0 https://www.youtube.com/watch?v=9CJ_BAeOmW0
- neovive 7y agoI would be interested in opinions on the approach taken by Laravel Airlock. It seems to be a hybrid approach between stateless auth and session. https://laravel.com/docs/master/airlock https://laravel.com/docs/master/airlock
- skohan 7y agoJWT always felt a bit strange to me. The fact that we pass user attributes back and fourth from the client feels more like evidence of flaws in the web as a platform than it seems like a real solution.
- devy 7y agoNitpick: on point 10) cause issues down the lime. "lime" is a typo, should be "line"
- user5994461 7y agoGood catch! fixed.
- ccleve 7y agoJWT 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.
- mmazing 7y agoAn organization I was at in the past attempted to use them as a replacement for sessions, which turned out to be a terrible idea as I suspected it would. 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.
- user5994461 7y agoAuthor. I wouldn't recommend to do less than 2-5 minutes. Some OpenID Connect providers actually ignore token expiry time silently when it's below a couple minutes. Consider that host clocks are not always in sync (even NTP could leave 10 seconds of difference) and the many authentication redirections can take quite a bit of time for slow clients. Limiting tokens to 30 or even 60 seconds is asking for troubles. But then again, I have to work with thousands of hosts, applications and datacenters, so I feel every edge cases. A single application on a single host would not.
- Richicoder 7y agoYou may only need 10 bytes of info, but that JWT is a lot more than just a data blob. It's a signed set of user info. If you don't need that extra layer, sure, then drop to an opaque token. Complaining that a signed header is large, however, seems a little silly. It's also worth mentioning that HTTP/2 also does header compression which helps with this.
- miguelmota 7y agoReasons why JWTs are not awesome: - 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.
- s_y_n_t_a_x 7y ago> 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. The blacklist is smaller than storing every token and not needed if you use a short expiration and refresh often. > JWT are to prevent database calls but a regular request will still hit the database anyway. It's one less query per request plus not all requests need the database immediately. > JWT are very large payloads passed around in every request taking up more bandwidth. They are 100~ bytes instead of 10~, not "very large". > If user is banned or becomes restricted then it still requires database calls to check the state of user. This is the blacklist you mentioned as the first reason. > JWT spends CPU cycles verifying signature on every request Pretty sure this is neglible. Similar to SSL requests. > JWTs just aren't good for authentication which is how a lot of web developers try to use them as. Use a session ID instead. Opinion. I weighed the pros and cons and JWTs are still worth it for my authentication use cases.
- miguelmota 7y agoMore power to you. I prefer to use the best tool for the job which in this case are session IDs since they are simpler, have been battle tested, and proven to work for over the last two decades.
- ascotan 7y agoJWT - because you were told sessions and cookies aren't cool anymore. Then you come to realize that JWT is basically pointless except for doing MFA (which you could probably have done with a random token).
- nijave 7y agoA couple more points * Why wrote your own format when JWT already has predefined keys. If you write your own encoding format instead of crappy JWT interoperability you have none and have to write everything from scratch * If you're following API first using cookies for machine to machine API interactions is ridiculous (cookies are for browsers and humans) * JWT being fairly standard plays nice with load balancer a/auth proxies/API gateways which can off load auth or even route it before hitting the application (database calls are expensive compared to in memory cached auth and you probably have an LB anyway)
- reiichiroh 7y agoWhat’s a JWT?
- johann8384 7y agoJWT is for when you really really need to re-invent certificates.
- CiPHPerCoder 7y agoCounterpoint: 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...
- cryptica 7y agoThat article doesn't contain a single logical argument. >> JSON Web Tokens are Often Misused So is everything else. Name one programming concept which isn't often misused. >> There were two ways to attack a standards-compliant JWS library to achieve trivial token forgery The keyword here is "were" - Just like how people in Europe "were" dying from the Bubonic plague - It doesn't mean that Europe is unsafe today. The up-to-date reality is that JWT today has been battle-tested to an extent that few other web standards have. In a way, all the negative attention due to past issues has made it stronger. >> JSON Web Encryption is a Foot-Gun... this is somewhat like pointing a gun with 5 out of 6 loaded chambers directly at your foot ...And using session IDs inside a cookie is like eating a cookie laced with cyanide.
- enumjorge 7y agoCan you elaborate why session IDs inside cookies is dangerous?
- Supermancho 7y agoI can manipulate my cookies. I can forge my servserside session id for session hijacking. This is what I understood.
- CiPHPerCoder 7y ago> I can forge my servserside session id for session hijacking. This is what I understood. Forge this. For each session: session_id = bin2hex(random_bytes(32)) Yes, you can change what you send to the server. But you can't hijack another user's session in this probability space (2^-256) by blind guessing. Instead, you need another way to leak their credentials to hijack the session.
- thdrdt 7y ago"Pro: JWT is secure" Yes, but I see a lot of implementations where the token is sent to JavaScript and is stored there. It's best to store it as secure cookie (HttpOnly) so JavaScript cannot access it.
- tmikaeld 7y agoWas 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 https://www.youtube.com/watch?v=JdGOb7AxUo0 1 sec takeaway (More in the video): https://i.imgur.com/vUYTYfS.png 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 was built for.
- twic 7y agoJWT is just a particular format for cookies.
- zaiste 7y agoI'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-jwt/ https://zaiste.net/creating-secure-rest-api-nodejs-without-j...
- codezero 7y agoI don’t see any mention of cookies in that post except about an upcoming post. Does your framework provide the persistence on the client side for authentication, or does it rely on the client to maintain that token?
- Scarblac 7y agoThat's nice, and how it was done for decades. But I'm looking at JWT in a context where we have an application with a REST API, third parties paying us for licenses want to write frontends running on their own domains using to that API, and authentication servers are run by end user organizations that manage their own users. Our API knows that that organization's auth server is allowed to sign tokens, the third party frontends can obtain those tokens and send them to our API, and it works (or so I hope, I'm in the reading up on all this stuff phase). Sessions using regular cookies just don't.
- 7y ago
- tpetry 7y ago„9) Myth: JWT doesn’t support logout or invalidation. (It can with OpenID Connect)“ Iterating on how invalidation work with OpenID Connect when in a point before the author said an authentication service which can go down is a single point of failure you should avoid. So he added a spof by using openid connect...
- user5994461 7y agoIt's all about trade offs. If you want full session management, not everything can be decentralized. People often say that JWT can't handle sessions at all so I am merely explaining that it actually can out-of-the-box and how to make it work. Anyway, there is always a single point of failure somewhere. There's got to be something that authenticates users and creates tokens in the first place.
- eandre 7y agoThis article is conflating the benefits of a particular way of doing implementation, and JWT as an implementation of that approach to authentication. That's dangerous because it n discourages people from thinking carefully about the semantics involved. Authentication is a topic where the trade-offs should be carefully evaluated for your particular situation. I do agree that if you need the particular way of doing authentication that JWT is designed for, JWT is indeed a great implementation and can save you a lot of time.
- gfggggggg 7y agoJWT can be used as cross server auth sign in on www.example.com -> click visit www.example2.com while being logged onto accout based on example
- abetusk 7y agoJSON Web Token [1] [1] https://en.wikipedia.org/wiki/JSON_Web_Token https://en.wikipedia.org/wiki/JSON_Web_Token
- fuzzy2 7y agoI’m always amused that with JWT, there never appears to be any separation between JWT-the-storage-format and JWT-what-I-do-with-it. JWT as a storage format is great indeed. If you pin the signing/encryption algorithm. Otherwise you shot yourself in the foot, which is bad, yes. Everything else isn’t JWT. Sure you can use it with OpenID/OAuth/whatever. Sure you can store them in cookies. Sure you can use them with or without sessions. But how is any of that related to JWT specifically? One of the articles says with JWT I have to re-implement session management. Just use a different framework then. Sessions with cookies are also not magic. Another article basically says you don’t need OAuth 2.0 with access tokens and refresh tokens. Very true. Also not about JWT.
- tracker1 7y agoI tend to just implement minimal JWT myself... auth server issues token, all services expect an authentication-bearer header with one. Also, pinning the algorithm and allowed keys is absolutely important. I'm also not a fan of "sessions" other than at the client, they tend to fail at scale.
- ben-schaaf 7y ago> If you pin the signing/encryption algorithm. Otherwise you shot yourself in the foot, which is bad, yes. I recon if the library you're using doesn't force you to pin the algorithm (or opt out of pinning), your foot is probably already full of bullet holes.
- jmkni 7y agoNoob question, what is pinning in the context of JWT?
- fuzzy2 7y agoIt means to allow only expected algorithms. Because as critics rightfully point out, without any whitelisting, you can just specify that your JWT does not have a signature and then it’s a valid token, whatever the contents.
- 7y ago
- raxxorrax 7y agoWhile HN is full of Javascript enthusiasts who would never dare mentioning anything negative about the language making praise of JWT probably redudant, even if the token mechanism and the language are complete separate issues, I have to state that I also think JWTs to be helpful. I mostly use them in IOT voice enabled devices that get their time limited authorization to access popular voice services through such a token. Voice enabled devices suck, but that is not the fault of JWT. I think without JWT being that common already, we wouldn't have a situation where a devices need to sign requests against voice services and we would have additional security concerns. It is a given that you can use a complete different token or other cookie mechanisms that work just as well. But I like them to provide at least some common ground. Even if there is valid criticism about the implementation. Authentication != authorization should always be mentioned on the topic of JWT. And yes, they are often abused to do things beyond their intended scope. I would think this to be a user error.
- esseti 7y agowould you secure api via JWT? Session token are not an option, basic auth can be an alternative.
- abathur 7y agoI wouldn't call it a best-practice, but I've done this. I guess my basic heuristic is that it's decent for an API that you expect to have very few consumers (internal, partnerships), but I would hesitate to recommend them for an API aiming for wide adoption.
- user5994461 7y agoJWT works well. Securing API is one of its main use cases. That being said. Please do NOT use basic auth for anything in 2020. This is the worst anti-pattern one could do for authentication. Basic auth simply transmits the username and passwords in clear text with every request. No application should be receiving username and password in clear text besides a single auth service. The passwords will get leaked all over the place between developers debugging, verbose logs, exceptions, etc... And unlike tokens that are meaningless and expire, textual passwords last forever and are extensively re-used by user across websites.
- praveenweb 7y agoJWTs 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 do a silent refresh. 4. Blacklisting of tokens adds complexity and defeats the purpose of decentralising the auth workflow. 5. There's technically no logout. It's all done via very short expiration times. With multiple tabs open, logging out on one tab needs to be synced with rest of the tabs via some event listeners. 6. SSR rendered pages need to send along the latest refresh token cookie so that the browser can use it. 7. The refresh token is sent by the auth server to the client as an HttpOnly cookie to prevent XSS/CSRF. My colleagues wrote a detailed guide which goes through these considerations - https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/ https://hasura.io/blog/best-practices-of-using-jwt-with-grap...
- pier25 7y ago> Yes! If a JWT is stolen, then the thief can can keep using the JWT. Unless you have some form of fingerprinting the client who authenticated and received the JWT.
- jayd16 7y agoSessions could be stolen too. The rest are essentially trade offs with the expiration mechanism. If your use case can't handle that, don't use JWT.
- ascotan 7y agoergo: if it's ok to have an un-revocable insecure session - use JWT tokens.
- user5994461 7y agoOr use JWT + OpenID Connect in a centralized mode, as the article explains toward the end.
- webhamster 7y agoCan we finally stop conflating an encoding/signature/encryption method with a transport/storage mechanism?!
- threatofrain 7y agoIt's never quite clear what the best framing or boundaries are for these concepts.
- humbleMouse 7y agoScrolled too long to find this comment!
- nijave 7y agoApparently not
- skywhopper 7y agoI agree JWT can be very useful, but its implementations are unfortunately all over the place in terms of what algorithms they support, especially lacking in the asymmetric space. Also the docs are pretty bad—spread out over multiple documents, with no explanation of the basic concepts, and they assume a lot of pre-existing domain knowledge. And then you still have to use JWTs correctly which is very easy to screw up. OIDC has improved this situation somewhat, at the cost of another layer of even more complexity that’s easy to screw up.
- mgreenleaf 7y agoEverytime I see a headline with "JWT" in it, I get excited hoping that it is for "JWt" [1], the "Java Webtoolkit", which I love. It happens when I search for it as well, I look for "Jwt ..." and instead of the beloved toolkit, it comes up with all these json web tokens and HMACs. Aaah, well, I'll keep looking for that wonderful day when it really is the toolkit. I guess it goes without saying that, I recommend it highly. [1] https://www.webtoolkit.eu/jwt https://www.webtoolkit.eu/jwt
- Drdrdrq 7y agoThank you, looks interesting. GPLv2, if anyone is curious.
- naranha 7y agoAnother Pro is that they can be read client-side, so the server and the client have an agreement on who the user is and what their attributes are (if they are defined in the JWT payload).
- teyc 7y agohttps://news.ycombinator.com/item?id=21785888 https://news.ycombinator.com/item?id=21785888 tptacek Credential attenuation in Macaroons is cryptographic; it's in how the tokens are constructed. I don't see the opportunity for a DoS (that didn't exist without attenuation already). Macaroons are a really lovely, tight, purpose-built design that happens to capture a lot of things you want out of an API token, including some things that JWTs don't express naturally despite their kitchen-sink design. JWT is more popular because there are libraries for it in every language, and people don't think of tokens as a cryptographic design (or nobody would be using JWT!), they think of them as a library ecosystem. JWT is definitely the stronger library ecosystem! This is also why I probably wouldn't ever bother recommending PASETO. If you're sophisticated enough to evaluate token formats based on their intrinsic design, then you should implement Macaroons if possible (it's almost always possible). If you're not, then you're going to use JWT.
- twic 7y agoI'd never heard of macaroons. Here is a website: http://macaroons.io/ http://macaroons.io/ I note that the logo depicts macarons [1], rather than macaroons [2]. A parent comment also mentions PASETO: https://paseto.io/ https://paseto.io/ Sadly, a paseto does not appear to be any kind of biscuit. The PASETO site links to this searing indictment of JWTs and related things: 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... I am far from qualified to evaluate any of these! [1] https://en.wikipedia.org/wiki/Macaron https://en.wikipedia.org/wiki/Macaron [2] https://en.wikipedia.org/wiki/Macaroon https://en.wikipedia.org/wiki/Macaroon
- chrisseaton 7y agoSome locales do call the things in the icons macaroons.
- saagarjha 7y agoOff topic: it gives me undue vexation that there are two dessert items with names so similar to each other that everyone keeps confusing them. Can we just all agree to come up with a new name for one of them?