
JWT is Awesome - hieudang9
https://thehftguy.com/2020/02/18/jwt-is-awesome-heres-why/
======
miguelmota
Reasons 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.

~~~
tracker1
Don't blacklist, use shorter lived tokens and have the client refresh as
needed. A 10-15m token is plenty long life and not so long as it's a huge risk
window, more than even a shorter window,.

~~~
jteppinette
Stakeholder: “so you are saying that after a user is denied access they can
still access the resources?” Dev: “yes, but only for 15 minutes. Also, it
makes our system more simple and decreases database calls, increase
performance, ...” Stakeholder: “nope”

~~~
bearjaws
Meanwhile on sales call with Microsoft:

"Authentication takes a few minutes to replicate throughout our systems so a
SLO request should be resolved within a few minutes". Stakeholder: Ok sounds
good

~~~
tracker1
+1 on this... it can be up to a 30 minute lag in some orgs... oh, you have
access to those systems for a while until things sync up... similar for
LDAP/AD sync with Nix/windows.

~~~
to11mtm
Which makes sense when I think about how some of the more trigger happy orgs
made a point of shutting peoples accounts of as they were being walked into a
room...

------
tmikaeld
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](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.

~~~
nijave
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 ID. I'm also not sure why you'd store all
of a user's information in a JWT. You can just put in the minimal information
to accomplish what you need.

~~~
tmikaeld
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.

~~~
foray1010
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.

~~~
Spivak
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.

~~~
dwild
> you're just describing a session cookie with some signed metadata.

Isn't that JWT?

------
fuzzy2
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/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.

~~~
ben-schaaf
> 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
Noob question, what is _pinning_ in the context of JWT?

~~~
sk5t
Your question is a good one, and "pinning" is not a very appropriate term
here. Whitelist acceptable algorithms by issuer, ok fine--you have to have a
library of acceptable public keys or shared secrets to go along with each of
the allowed algorithms anyway. The JWT consuming infrastructure here on top of
jose4j uses a registry of keyinfo metadata to allow for provision of multiple
expirable keys and supported algorithms for each authorized issuer, and I'm
not sure why anyone would do it other than that way, really.

Disallowing the "none" algorithm is an important implementation detail, like,
maybe your JWT library demands an environment value
"JWT_ALLOW_UNSAFE_SIGNING_I_KNOW_WHAT_I_AM_DOING=1" or just doesn't support it
in the first place. Maybe it was foolish to ever make any allowance for this
in the first place.

~~~
dwaite
> Maybe it was foolish to ever make any allowance for this in the first place.

Since JWT is used as a wrapper around data, it is possible that your needs
will vary based on deployment scenario. In some cases, that data may need to
be encrypted, in other cases only signed.

In some cases I may not need integrity protection/repudiation and am already
sending over a mutually authenticated/encrypted channel. The implementations
may not want signing to be forced on them, impacting their compute/data
budgets - but they still want to write their standards to depend on a single
data format.

In general there should not be a whitelist, but a precisely known strategy
going into evaluation. This is because: \- unlike TLS, you likely have a
relationship with the issuers \- unlike browsers, the different components are
being validated against the domain

For JWKS-based distribution, that usually means that a key identifier maps to
a specific issuer and to a specific validation strategy. If you supported CA-
based trust models, that specific validation strategy should come from the
certificates.

You shouldn't look at the public key data and decide based on the algorithm
inside the JWT how to interpret it.

------
teyc
[https://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
I'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-
ba...](https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-
that-everyone-should-avoid)

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)

~~~
saagarjha
Off 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?

~~~
twic
To be fair, there is a similar situation with "cookie", which means any kind
of small, flat, compact, unleavened flour-based sweet baked item in the USA,
but more specifically a particular soft kind in the UK.

And conversely, "biscuit", which has the former meaning in the UK and means
some sort of weird scone in the USA.

------
praveenweb
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 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-
grap...](https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/)

~~~
aPoCoMiLogin
> With multiple tabs open, logging out on one tab needs to be synced with rest
> of the tabs via some event listeners.

that's a problem with every site in general, which doesn't use any kind of
event listeners.

~~~
couchand
Well, yes, but it's not exactly the same. Session-based logout (or JWTs with
blacklisting) automatically protect resources that haven't been fetched yet,
but leave open the possibility of lingering previously-fetched resources. JWTs
without a blacklist even leave open the possibility of fetching additional
resources with a supposedly logged-out credential. That seems like a much
bigger hole.

~~~
aPoCoMiLogin
For me blacklisting is bad idea in general. It can be achieved without
blacklisting downsides by using asymmetric keys per user. Where you could
rotate keys after things like logout or password change. Keys might be stored
in replicated storage, same as session, and deleted/rotated as needed.

Don't get me wrong, JWT it's not silver bullet nor it was meant to be one in
first place. It's not session replacement, but there are places where right
implementation makes lot of sense.

------
CiPHPerCoder
Counterpoint:

[https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-
ba...](https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-
that-everyone-should-avoid)

~~~
skrebbel
I'm impressed that you put your money where your mouth is and built & marketed
an alternative: [https://paseto.io/](https://paseto.io/)

Anyone here got experience using Paseto in anger? (besides CiPHPerCoder who
made it)

I would love a JWT-like thing that's equally common yet better designed. But
especially when using it in public APIs and the likes, acceptance has to be
pretty broad. Anyone got insights as to how mainstream Paseto is getting?

~~~
jillesvangurp
Judging from the number of stars of the various git repositories for different
languages, there are a few people using it but not a whole lot. The most
popular implementation seems to be php based. That suggest to me it's still
early days for this. E.g. the Java implementation only has 13 stars, which is
not a lot. Also it has a native dependency, which is not ideal. E.g. JWT has a
pure Java implementation from oauth0.

JWT has been out there for a few years and there are many uses of it that are
fine. I've used it in the past and it was easy set up and get started with.
The main criticism seems to be that users have too much wiggle room to do
silly things like using alg=noneor that certain widely used algorithm
combinations have some weaknesses. I guess that's valid but not a huge concern
if you know what you are doing.

Paseto looks like it improves by narrowing down the choices to some sane
choices, which is a valid approach. Of course IETF could update the relevant
RFCs to use the same algorithms for JWT at some point.

~~~
anonsivalley652
Popularity != value. Get over false signals.

~~~
Aeolun
As soon as AWS supports PASETO we can talk, until that time popularity equals
value.

~~~
CiPHPerCoder
Give me a few months, then. :P

If they agree it's a good idea, it should pick up quickly.

~~~
anonsivalley652
Don't count on it. As it happens, I used to be a AWS consultant w/ a third-
party preferred vendor. Their product direction involves more politics, job
security and creating a labyrinthian platform that's difficult to emulate
precisely.

------
webhamster
Can we finally stop conflating an encoding/signature/encryption method with a
transport/storage mechanism?!

~~~
nijave
Apparently not

------
abetusk
JSON Web Token [1]

[1]
[https://en.wikipedia.org/wiki/JSON_Web_Token](https://en.wikipedia.org/wiki/JSON_Web_Token)

------
mgreenleaf
Everytime 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
Thank you, looks interesting. GPLv2, if anyone is curious.

------
nijave
A 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)

------
eandre
This 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.

------
tpetry
„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
It'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.

------
0x445442
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.

~~~
icebraining
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.

~~~
hombre_fatal
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.

~~~
icebraining
Right, linking to the wiki makes sense. I just don't think expanding the name
gives you anything.

------
owaislone
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'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.

------
725686
I 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)

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

~~~
mmazing
An 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
Author. 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.

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

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.

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

[https://laravel.com/docs/master/airlock](https://laravel.com/docs/master/airlock)

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

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

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.

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

------
devy
Nitpick: on point 10)

    
    
      cause issues down the lime.
    

"lime" is a typo, should be "line"

~~~
user5994461
Good catch! fixed.

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

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

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

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

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

------
thdrdt
"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.

------
reiichiroh
What’s a JWT?

