JWT Explained In Under 10 Minutes (JSON Web Tokens)

JWT (JSON Web Tokens) explained in under 10 minutes! Authentication, authorization, refresh tokens, statelessness, and more.
Four years ago, I published my first-ever article on Medium, titled "JSON Web Tokens - The only explanation you'll ever need". Tens of thousands of developers have read it, so I decided to make a video version. Enjoy!
🔗 Socials:
X - x.com/arielweinberger
LinkedIn - / arielweinberger
Timestamps:
00:00 Intro
00:21 Authentication VS Authorization
01:34 The Structure of a JWT
02:42 Signature
04:05 JWTs Are Encoded, NOT Encrypted!
04:45 JWTs Are Stateless
05:49 Short Lived Tokens
07:32 Refresh Token Rotation
08:13 Recap
📚 Resources
1. Medium.com - JSON Web Tokens (JWT) - the only explanation you will ever need by Ariel Weinberger
/ json-web-token-jwt-the...
2. jwt.io

[@bawer_my]

thanks, good explanation!

[@sangamshrestha143]

That was an awesome video. Thanks.

[@codinglyio]

Glad you liked it!

[@fabianhafliger4050]

Subscribed!

[@2pacgamer]

super clear, thx ! :)

[@mhm13dev]

Thanks for the super clear explanation. I have question related to Refresh Tokens being stolen: 08:13 "The first time legit user uses the refresh token, that refresh token is not valid anymore." But here is a catch, WHAT IF the malicious user uses the refresh token to get a new pair of tokens before the legit user? That means, after some time when legit user tries to use refresh token, he will not be allowed to do so, BUT malicious user will have all the access. What do you think about that?

[@CarlosAmegos]

A refresh token should never be used twice if you are rotating. Knowing this, your system can invalidate all the tokens for the user if a refresh token is used twice. Additionally, it wasn't mentioned, but you should return the JWT's as Secure HttpOnly cookies whenever possible. Secure means it's only sent with HTTPS, and HttpOnly prevents scripts from accessing it. Also SameSite strict/lax can help against CSRF.

[@Pareshbpatel]

A very thorough, yet succint explaination of JWT. Thanks, Ariel. {2024-04-21}

[@Diego_Cabrera]

Amazing production quality. May I ask how did you create the animated portions of the video like the text and everything?

[@codinglyio]

Blood, sweat and tears, using Adobe AfterEffects. My first time using it and it was hard 😅

[@thewaver8]

Security reasons behind token expiration and rotation are clear, but not their mitigation. If, has an attacker, I have access to both tokens, then I am on equal footing with the legit user who also has both tokens. I could be the one getting the new refresh token / auth token as part of my requests even, UNLESS there's something else that you've neglected to mention, like a tie-in to the user's IP / Mac Address / etc. Also, you keep saying that the token is stateless but don't explain WHAT IT MEANS. Stateless is an incredibly loaded term in IT. I understood what you meant through the given example, but you should definitely pay more attention to such details.

[@ricko13]

I'm kinda lost with the refresh token thing, the refresh token lives in the database right? so it defeats the purpose of JWT which is being Stateless (not need to query the db for authorization) *in the scenario where you can't have cookies e.g. mobile or desktop apps

[@codinglyio]

Yes the Refresh Token lives in a DB. The idea is that you use your JWT for most interactions, as it contains claims about the user. This way, the server does not need to interact with the database for every request. This helps deal with scale and prevent bottlenecks from an auth server. For mobile apps, no problem not to use cookies, but local storage. The reason we use cookies (same-site, HTTP secure) to store JWTs on browsers is due to CSRF attacks and malicious extensions. That's not the case with mobile apps where you own the app.

[@AjayKumar-cq7mz]

I have watched the video multiple times and Istill don't understand it completely How is the JWT stateless Please make a detailed video showing how the token is generated on server and how it goes to cleint and how does the whole process work

[@CarlosAmegos]

It's considered stateless because it carries all the information within itself. There's no need for a session store. Maybe a simpler term is self-sufficient.

[@jitx2797]

Do I need to store Refresh token in user's cookies??

[@codinglyio]

Secure HTTP only cookie + SameSite, to protect against CSRF attacks

[@Unknown-op8et]

@@codinglyio for clarification, We basically have 2 tokens of which access token (short-lived and store within memory maybe using state manager on front end) refresh token(stored in cookie, only sent when refresh token) right?

[@andrelapiana3610]

👊 "Promo sm"