
Understand JWT in 3 Minutes - tahazsh
https://tahazsh.com/understand-jwt-in-3-minutes
======
stedaniels
Why not to use JWT in 3 Minutes:
[http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-
fo...](http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-
part-2-why-your-solution-doesnt-work/)

~~~
NicoJuicy
Off-topic

Joepie91 once did a small nodejs project for me, that's why I recognized your
link.

I'm kinda worried as "not an acquaintance" about his post about depression and
that he didn't post anything since 2016.

Anyone know what happened?

~~~
joepie91_
Hi, no worries, I'm still alive :)

I just haven't updated my blog for quite some time, due to a combination of
circumstances. I'll probably start blogging again at some point in the near
future.

~~~
masonic
"Reports of my death have been exaggerated." \- Churchill

------
brimtown
> Q: If I have to include this token with every request, where should I store
> it?

> A: Typically, you would store it in the localStorage, after the user logs in
> and gets the token.

This seems to contradict Auth0's guidance to not store tokens in localStorage
since it's vulnerable to XSS: [https://auth0.com/docs/security/store-
tokens#don-t-store-tok...](https://auth0.com/docs/security/store-tokens#don-t-
store-tokens-in-local-storage)

~~~
rumanator
Thanks for the insight! If anyone cares to provide any clue about best
practices and how to handle token storage, you are more than welcomed to
provide any insight.

~~~
KukicAdnan
Here you go: [https://auth0.com/docs/security/store-
tokens](https://auth0.com/docs/security/store-tokens)

Gives various suggestions depending on your use case.

~~~
moogly
I've been looking at this for months without getting a clear, noncontroversial
answer. Even with this documentation, it is still unclear what to do if you
have a SPA on another host than your backend (so you can't use cookies), and
you do not want to use server sessions. Using `oidc-client` from the frontend
could work, but that bundle size[0] is absolutely insane.

[0]: [https://bundlephobia.com/result?p=oidc-
client@1.9.1](https://bundlephobia.com/result?p=oidc-client@1.9.1)

------
rvz
> Q: If I tried to use this token after 10 years, would it still work?

> A: Yes, it will be valid forever unless the server specifies an expiration
> time when generating it.

The implications of this is beyond calamitous. This is why Disney+ and
Fortnite logins were hijacked in the first place. I can harvest all these JWT
logins with a good chance of people forgetting to ever logout. Hence this,
with one push of a button I can abuse an API endpoint to mass delete everybody
or what not. Best part about JWTs? They are unencrypted by default.

For that reason, Just do not use JWTs.

~~~
api
What else should we use that is not over-engineered?

~~~
moltar
Cookies have been battle tested and are very secure. Enable http only mode and
you can’t even access them from JS thus eliminate possibility of take over /
token theft.

~~~
shantly
You can store & pass JWTs in cookies, provided they're not huge.

~~~
thdrdt
But the server must send them.

~~~
shantly
Where else are JWTs coming from? You can't pass the signing key to the client,
that defeats the point.

~~~
thdrdt
It has to come as cookie from the server if you don't want to save it with
Javascript.

~~~
shantly
Is there a problem with that? So long as your CORS headers aren't screwed up
for your use case, passing JWTs around via cookie headers should be fine,
right?

------
moltar
I’m still not understanding the advantages of JWT over cookies for user facing
auth.

I do see use cases for JWT for machine-to-machine auth though.

~~~
matthoiland
A server can issue a JWT and forget about it. Most cookie auth strategies
requires the server to persist the token to confirm validity. Also, a JWT can
work across a microservice architecture easily for the same reasons.

~~~
latortuga
The biggest problem with JWT is there is no revocation mechanism which IMHO is
a non-starter. Introducing revocation mechanisms generally means introducing
central state and now you're back to why not just use a session token? Not to
mention the numerous issues JWT has had over the years.

------
mettamage
And yet he didn't explain how JWT differs from session cookies.

I suppose I'll never learn.

(looks hopefully at the HN crowd)

~~~
shantly
JWT is just some arbitrary JSON data, with a few customary fields,
cryptographically signed by whichever system issued it. You send it to the
client, which may be a browser or mobile app or whatever, and they send it
with each request to any related systems. A system receiving a JWT can verify
that the stuff in it was certified as true or accurate by the issuing system,
given only the correct keys to check the signature and no further info about
the user. One might, for example, put user identity info & user roles (for
permissions) in a JWT.

This can be useful for e.g. checking login status at proxy or cache servers
without having them connect to a database or ask other systems (so, works very
fast), for microservice bullshit, or for systems with lots of access points
and unified login (think Google, with Youtube, Gmail, Docs, and so on—I don't
think they use them, but that's the sort of situation in which one might)

The main downside is that you can do stupid crap with them like not set an
expiration, and you can't really expire tokens prematurely (say, on user role
changes or on user deletion) without re-introducing some centralization.
Neither are crippling but they do make it less the magic bullet than one might
hope.

------
falcolas
One thing missing: the "cryptographic signature" isn't required to be a
cryptographic signature by the standard. You need to ensure, by configuration
or by library defaults, that the algorithm of 'none' is not allowed, otherwise
someone could freely modify and replay the JWT for all time.

[https://tools.ietf.org/html/rfc7519#section-6.1](https://tools.ietf.org/html/rfc7519#section-6.1)

------
ajbeach22
I've seen lots of tutorials for single page apps/api architectures that
specifically store JWT in localstorage, it's endemic.

What I haven't seen though, is guidance on how to deploy SPA web apps using
cookies properly (with either jwt or session token in http only cookies)

From what I have found, there are only a few options:

1\. host api at 'api.mydomain.com' and frontend from 'mydomain.com'. You will
have to deal with CORS and options requests which can add significant latency
for non-simple CORS requests. Not to mention extra configuration with CORS
headers.

2\. Serve assets/frontend from the API (ie, rails static assets, Django
collect static, etc). Downside is that you have to deploy everything together.

3\. Reverse proxy so that api/frontend are on the same domain, and you can use
cookies without CORS. Api lives at 'mydomain.com/api' and frontend at
'mydomain.com`

I am currently doing 3, which if you are using AWS, you can use CloudFront as
the reverse proxy by using a separate dristriburion for your api and your
Frontend and using behaviors to route traffic by path. In fact, that is what
AWS recommends: [https://aws.amazon.com/blogs/networking-and-content-
delivery...](https://aws.amazon.com/blogs/networking-and-content-
delivery/dynamic-whole-site-delivery-with-amazon-cloudfront/)

So for 3, for example:

You have CloudFront -> Loadbalancer -> EC2 for your api with a path of /api in
CloudFront, you can set CloudFront to never cache. You don't pay for bandwidth
between EC2 -> CloudFront, you only pay for bandwidth out of CloudFront:

>Outbound data transfer charges from AWS services to CloudFront is $0/GB. The
cost coming out of CloudFront is typically half a cent less per GB than data
transfer for the same tier and Region

For your frontend, you can host in s3 -> CloudFront with a catch all path for
non-api paths (allows client side push state to work in SPA).

CloudFront in this case also is where SSL termination happens. You can also to
full end to end ssl if you enable that in the CloudFront and your API can also
terminate ssl at the LoadBalancer.

The other benefits to this approach is that you can usually just use the
default auth systems for your web apps. You can also create a CNAME for your
API loadbalancer to be api.mydomain.com and use that for non-web clients. In
the case of Django Rest Framework, there is both cookie and token auth enabled
by default.

------
dantheman
I can't believe it doesn't even define what JWT means... JSON Web Tokens

~~~
matthoiland
I can't believe it doesn't even define what JSON means... JavaScript Object
Notation

------
azhenley
The post never tells you what JWT even stands for. I thought it was the Java
Web Toolkit...

