JWT is Awesome

Reasons why JWTs are not awesome:<p>- to revoke a JWT you have to blacklist it in the database so it still requires a database call to check if it&#x27;s valid.<p>- JWT are to prevent database calls but a regular request will still hit the database anyway.<p>- JWT are very large payloads passed around in every request taking up more bandwidth.<p>- If user is banned or becomes restricted then it still requires database calls to check the state of user.<p>- JWT spends CPU cycles verifying signature on every request.<p>- JWTs just aren&#x27;t good as session tokens which is how a lot of web developers try to use them as. Use a session ID instead.<p>Where JWT works best:<p>- when a client can interact with multiple services and each service doesn&#x27;t need to do a network request to verify (ie federated protocols like OpenID). The client verifies the user&#x27;s identity via the 3rd party.<p>- as a 1 time use token that&#x27;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.

Was about to write a rant that it&#x27;s still not better than cookies &amp; sessions, something that has been standard waay longer than JWT.<p>But this video says all I have to say (2018):<p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=JdGOb7AxUo0" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=JdGOb7AxUo0</a><p>1 sec takeaway (More in the video):<p><a href="https:&#x2F;&#x2F;i.imgur.com&#x2F;vUYTYfS.png" rel="nofollow">https:&#x2F;&#x2F;i.imgur.com&#x2F;vUYTYfS.png</a><p>That said, JWT&#x27;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.

I’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&#x2F;encryption algorithm. Otherwise you shot yourself in the foot, which is bad, yes.<p>Everything else isn’t JWT. Sure you can use it with OpenID&#x2F;OAuth&#x2F;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?<p>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.<p>Another article basically says you don’t need OAuth 2.0 with access tokens and refresh tokens. Very true. Also not about JWT.

<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21785888" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=21785888</a><p><pre><code> tptacek Credential attenuation in Macaroons is cryptographic; it&#x27;s in how the tokens are constructed. I don&#x27;t see the opportunity for a DoS (that didn&#x27;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&#x27;t express naturally despite their kitchen-sink design. JWT is more popular because there are libraries for it in every language, and people don&#x27;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&#x27;t ever bother recommending PASETO. If you&#x27;re sophisticated enough to evaluate token formats based on their intrinsic design, then you should implement Macaroons if possible (it&#x27;s almost always possible). If you&#x27;re not, then you&#x27;re going to use JWT.</code></pre>

JWTs have made client side auth integrations look better. But the problem is that common security considerations and implementation details are generally overlooked.<p>1. Tokens are typically stored in localStorage. (app becomes vulnerable to CSRF &amp; XSS attacks).<p>2. Tokens can be stolen. Now this is generally controlled by having a very short expiration time.<p>3. Short expiration times mean persisting refresh tokens to do a silent refresh.<p>4. Blacklisting of tokens adds complexity and defeats the purpose of decentralising the auth workflow.<p>5. There&#x27;s technically no logout. It&#x27;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.<p>6. SSR rendered pages need to send along the latest refresh token cookie so that the browser can use it.<p>7. The refresh token is sent by the auth server to the client as an HttpOnly cookie to prevent XSS&#x2F;CSRF.<p>My colleagues wrote a detailed guide which goes through these considerations - <a href="https:&#x2F;&#x2F;hasura.io&#x2F;blog&#x2F;best-practices-of-using-jwt-with-graphql&#x2F;" rel="nofollow">https:&#x2F;&#x2F;hasura.io&#x2F;blog&#x2F;best-practices-of-using-jwt-with-grap...</a>

Counterpoint:<p><a href="https:&#x2F;&#x2F;paragonie.com&#x2F;blog&#x2F;2017&#x2F;03&#x2F;jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid" rel="nofollow">https:&#x2F;&#x2F;paragonie.com&#x2F;blog&#x2F;2017&#x2F;03&#x2F;jwt-json-web-tokens-is-ba...</a>

Can we finally stop conflating an encoding&#x2F;signature&#x2F;encryption method with a transport&#x2F;storage mechanism?!

JSON Web Token [1]<p>[1] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;JSON_Web_Token" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;JSON_Web_Token</a>

Everytime I see a headline with &quot;JWT&quot; in it, I get excited hoping that it is for &quot;JWt&quot; [1], the &quot;Java Webtoolkit&quot;, which I love. It happens when I search for it as well, I look for &quot;Jwt ...&quot; and instead of the beloved toolkit, it comes up with all these json web tokens and HMACs. Aaah, well, I&#x27;ll keep looking for that wonderful day when it really is the toolkit. I guess it goes without saying that, I recommend it highly.<p>[1] <a href="https:&#x2F;&#x2F;www.webtoolkit.eu&#x2F;jwt" rel="nofollow">https:&#x2F;&#x2F;www.webtoolkit.eu&#x2F;jwt</a>

A couple more points<p>* 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<p>* If you&#x27;re following API first using cookies for machine to machine API interactions is ridiculous (cookies are for browsers and humans)<p>* JWT being fairly standard plays nice with load balancer a&#x2F;auth proxies&#x2F;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)

This article is conflating the benefits of a particular way of doing implementation, and JWT as an implementation of that approach to authentication. That&#x27;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.<p>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.

„9) Myth: JWT doesn’t support logout or invalidation. (It can with OpenID Connect)“<p>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...

The string &#x27;JSON Web Token&#x27; doesn&#x27;t appear anywhere on the web page. If you&#x27;re going to use an acronym expand it out the first time you use it.

JWT 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&#x27;t see what would be the point of using JWT if you need highly centralized auth.<p>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, &quot;here you go, you can use this for the next N minutes&quot;. This is very useful when it&#x27;s not practical for every service&#x2F;client to &quot;register&quot; itself with the auth service before hand like oauth.

I highly recommend watching &quot;Deconstructing REST Security&quot; by David Blevins: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=9CJ_BAeOmW0" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=9CJ_BAeOmW0</a>

JWT is not awesome. I spent yesterday implementing it. The smallest usable JWT I could create was 137 bytes, not including the Authorization header.<p>This is absurd -- the total amount of data I needed to store in the JWT was about 10 bytes.<p>This inefficiency bloats requests. At a time when we&#x27;re migrating to http&#x2F;2, which which deliberately reduces headers to speed things up, JWT is going in the other direction.

While 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.<p>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&#x27;t have a situation where a devices need to sign requests against voice services and we would have additional security concerns.<p>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.<p>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.

I would be interested in opinions on the approach taken by Laravel Airlock. It seems to be a hybrid approach between stateless auth and session.<p><a href="https:&#x2F;&#x2F;laravel.com&#x2F;docs&#x2F;master&#x2F;airlock" rel="nofollow">https:&#x2F;&#x2F;laravel.com&#x2F;docs&#x2F;master&#x2F;airlock</a>

JWT 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.

I 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.<p>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.

JWT - because you were told sessions and cookies aren&#x27;t cool anymore.<p>Then you come to realize that JWT is basically pointless except for doing MFA (which you could probably have done with a random token).

Nitpick: on point 10)<p><pre><code> cause issues down the lime. </code></pre> &quot;lime&quot; is a typo, should be &quot;line&quot;

Another 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).

JWT can be used as cross server auth<p>sign in on www.example.com -&gt; click visit www.example2.com while being logged onto accout based on example

would you secure api via JWT? Session token are not an option, basic auth can be an alternative.

JWT is for when you really really need to re-invent certificates.

&quot;Pro: JWT is secure&quot;<p>Yes, but I see a lot of implementations where the token is sent to JavaScript and is stored there.<p>It&#x27;s best to store it as secure cookie (HttpOnly) so JavaScript cannot access it.

What’s a JWT?