Session Vs JWT: The Differences You May Not Know!

Animation tools: Adobe Illustrator and After Effects.

Checkout our bestselling System Design Interview books:

ABOUT US:
Covering topics and trends in large-scale system design, from the authors of the best-selling System Design Interview series.

[rshicks]

Your videos are phenomenal. Short, insightful, and proper use of graphics/illustration. 🎉 keep up the great work!

[RakeshBitling]

I dont understand why this channel is so underrated.. one of the best ever channel for experience developers and the way he explaines is really hats off to him

[kewqie]

One drawback I don't see mentioned in a lot of places when talking about a cookie + JWT combo, is that if the JWT has a lot of claims, the size of the cookie will grow up pretty fast and you might end up with situations where a WAF/LB will block your requests due to large cookies/header size, and it will not always be easy or possible to alter those limitations.

[whimsicalkins]

This video was just right on time for me. Was very confused about differences between session and JWT before watching this video. Now, its all clear. Thank you soo much ❤✨✨

[kinoenjoyer]

so refresh tokens are just sessions that get hit less often, with the complexity of jwt + session

[couragic]

Combination of JWT with refresh/access tokens isn’t stateless - you have to have storage on server with valid or blacklist of revoked refresh tokens.

[Tony-dprl]

Most developers who think JWTs perform better have never tested that theory. Looking up a small 128-bit session id in a local memory cache for the 99% case of a valid session is often faster than the overhead of transferring and validating a large signed JWT. Always measure. Never assume.

[marcgentner]

Very solid. No better explanation on the internet! Keep it up

[andresausecha]

Where I work, we are storing the JWT tokens in redis db, the reason is some microservices were processing a heavy load, thousands of requests per minute so the authentication was becoming a bottleneck to access the services. I think it's a little bit against the pattern and idea of JWT but we had to take the tradeoffs

[Phenix_]

You can choose an hybrid approch :
use JWT with the user token and for the refresh token link it to a session you can invalidate. At best the user token is valid 15 minutes so you steill have an option if not as powerfull in terme of kill the session

[phamngocangkhoa]

I have followed you on LinkedIn and it helps me a lot of SD architecture knowledge. Thank you

[illiakailli]

Thank you, very helpful videos!
One thing to consider: animation showing asymmetric encryption around 3:12 might be confusing as clients have nothing to do with encryption/decryption of JWT data, especially using asymmetric encryption. Token is received by a client during authentication and is already signed, so client trusts what it got and just passes token to a server where it gets validated. So it might be better to update diagrams depicting actual 3-legged oauth scenario when you are talking about asymmetric encryption signing option.
Also label is wrong: it says "HMAC digital signing of JWT" while showing asymmetric.

[alexeystolpovskiy]

Thank you for such a useful info!! This is invaluable

[wesamadel]

sessions are better for client-server
jwt and better for server-server

[je_suis_onur]

Actually it is pretty easy to extend the system to invalidate JWTs. JWTs typically expire after a certain time period and this information is in the JWT as well. Let's say that's 15 minutes. You can make sure that the time is actually 15 minute aligned, e.g 16:00, 16:15, etc. Then the moment JWT needs to be invalidated, you can calculate the invalidated JWTs (for the current and next 15 minute window) and add them to a redis cluster key with TTL set to next 30 minutes. Next time you check JWT validity you can check if it is revoked by checking redis. This means you gotta have a redis cluster as well but the size of the data would be drastically smaller (assuming you only need a small portion of all the issued JWTs to be invalidated). Syncing between nodes of the redis cluster should be fast too due to small data size.

[michael_loc]

For JWT, I have been wondering about the well-proven approach for access token rotation in the context of request concurrency. I look forward to your sharing on this.

[danyel]

5:05 the video shows refresh token being sent with every request but it;s the access token that gets sent.


Also similarly to how access token can be stolen and used until it expires, isn't it the case that also refresh tokens can be stolen ? What are the best practices when it comes to storing refresh tokens?

[alimihakeem]

Thanks for the explanation. I found it helpful

[djoleezcool]

Additional:
In new apps first JWT is not created on way you explained (implicit flow), usually we should use OAuth2.0 flow (authorization code for token flow).
Also it is not good practice to store JWT on client side, so also one layer of security will be required if you don't want to expose users info form token which is nothing than base64 encoded string.
So instead of returning JWT to client, you can save it in some cache like Redis, and just have dedicated cookie for it, then all magic will happened under the hood and you app will be more secured.

[wenyangwei]

5:06 wrong text in the diagram, it should be access token