Session Vs JWT: The Differences You May Not Know!

[@youngl9566]

Commenting because after watching all your videos I decided to buy your book. As a DevOps with 20 years of experience you've made learning fun again. Thank you for all you do.

[@rshicks256]

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

[@shay2559]

because most devs are newbies

[@moredeno]

underrated? lol

[@witchmorrow]

he has almost 1million followers which is crazy high for a software channel... how is it underrated

[@letung6189]

this channel is not underrated. I followed this channel when the total sub is just around 50k. It had reached 1m subs in only 1 year after.

[@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.

[@manju4ever222]

That's really well pointed out.

[@MaulikParmar210]

RBAC is there to compensate for that or simply use full oAuth impmementation instead of JWTs. The videos are pretty basic and do not talk about real-world problems.

[@kewqie]

A lot of OAuth implementations use JWTs.

[@MaulikParmar210]

@kewqie oAuth token doesn't have to be JWT, spec doesn't enforce it, just libraries do that. It can be any unique string as long as it is identifiable by auth layer and gives back response based on token and passed scope. Logic resides in impmementation details. This is why learning core concepts are essential.

[@a-xm4um]

you can compress you claims with a lib and/or algorithm, can use symetric key instead of RSA

[@LightGreen5013]

Thank you for making this video! People are so often on one side of this (usually JWT) and don't even realize there's another option. Great video!!

[@Tony-dp1rl]

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.

[@TheEdCurly]

Have you tried to measure?

[@OverG88]

On one of projects I worked on, we had stateful sessions in Postgres. The web service could handle 2k reqs/s. That’s pretty darn a lot. So yeah, you can scale very very far with sessions.

[@kodedart2311]

@@OverG88 Spot on. It's even better with a Redis cluster (if you want to scale up Redis eventually) which is not a distributed db, but good enough for this. We don't have "consistent" requests and metrics but it can handle 30-40k (in occasional peaks) like there is no tomorrow.

[@whimsicalkins5585]

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 ❤✨✨

[@Phenix246_]

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

[@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.

[@kewqie]

The authentication JWT itself is stateless, you are not forced to use refresh tokens.

[@furycorp]

@@kewqie True but if your requirements include a level of security you probably want very short lived JWT tokens... or go back to good ol fashion sessions.

[@kewqie]

@@furycorp You might not need refresh tokens in that case either and just force the user to login again.

[@TheEdCurly]

refresh/access tokens can be stateless if you don't need to revoke them(forcing logout or block user in shorter time than the expiration of refresh token.)

[@a-xm4um]

yeah I agree, to invalidate the token you need a storage. if you delete/block/logout the user they can still copy their cookies, unless it is in server side

[@Ivan-wm6gm]

I think it depends what architecture you plan to go for either monolith or microservice, if monolith then use session but invalidates your REST API being stateless, but if you plan to go microservice in the future then access&refresh token + redis for storing blacklisted tokens and put them in a Auth service separated from other REST API services and use the access token for auth to other backend services. The problem of using session auth if your user grows lets say 10M then each user request will hit the db/cache to validate user auth then you'll have problems with scaling your service. Meanwhile with using JWT Auth you will only use the access token to get verified without hitting the db/cache for each user request you will only hit the db/cache if you revoke refresh tokens, and you can still scale your auth service either vertically or horizontally

[@kinoenjoyer6733]

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

[@pablofernandezruiz8024]

That's exactly what it means, I usually store the refresh token in a db and check if it's still there when the user asks for a new access token. The benefit is that you can delete (invalidate) the refresh token by removing it from the db, so when the user asks for a new access token they can be logged out if I can't find the refresh token id in my db

[@jitxhere]

@@pablofernandezruiz8024 do you store the refresh token in user device i.e cookies?

[@normalvideos999]

@@pablofernandezruiz8024this sounds interesting, but I’m a little confused on the implementation of it when a user asks for a new token how do you confirm the user identity? Is there a name for this approach that I can look up more information on?

[@howetdone]

@@pablofernandezruiz8024 well that defeats the whole purpose of JWT, it is meant to be stateless.

[@moxy-bison]

At this stage, it doesn't make sense to use jwt if we are maintaining the state in the backend for sessions. Just use a session token.

[@deshtechno]

For security reasons refresh token should not be reusable, so, every time it is used a new refresh token should be issued and a previous refresh token should be revoked. This means that immediate revokation mechanism is still recommended for refresh tokens. Also, it is better to store refresh token in a secure http-only cookie with a path that points to refresh endpoint.

[@phamngocangkhoa1394]

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

[@OmnispectiveHub]

This channel is honestly amazing

[@BTC4444]

Good job! Waiting for passkeys 🙏

[@markos8971]

The content and how you explained it is great. It's short and well picked with great examples.

[@marcgentner1322]

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

[@JohnJustus]

Awesome explanation ... Thanks....keep up the great work!

[@artemcodes]

Very concise and informative explanation. 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.

[@venkatrohit5993]

Woow your teaching style is very nice ...

[@uzair004]

How does refresh token secure us from reuse of token, thief can call refresh token to update their token every time it expires ? Which strategy among session & JWT should be used if we want to track user interaction i.e user journey when using the application ?

[@carlotadias9335]

Use matomo or ContentSquare.

[@wasimrajamiddya7560]

Thank you for demonstrating this useful topic

[@soomjeetsahoo8710]

I once worked with one of the largest banks in India. We have implemented integration between web app and middle ware, we used jwt with rsa (2min exp token) and not HMAC.

[@michael_loc009]

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.

[@wesamadel3612]

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

[@nerd2544]

lol that hk/canto accent and intonation, recognizable from a mile away. great to see representation and at this level too

[@dot.4069]

Thats a great video, that covers all questions I was interested in

[@andresausecha9553]

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

[@anonymologist7946]

In this case, I suggest using Redis as a block list since it is more efficient than storing sessions for all users, and it will require less storage space.

[@bbrother92]

What are yhou doing in redis with token?

[@sedatyilmaz6907]

Amazing video, very good animations. Thank you

[@alimihakeem841]

Thanks for the explanation. I found it helpful

[@alexeystolpovskiy7862]

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

[@everythingisfine9988]

Invalidating JWT sessions is easy. Just need to a redis instance to store the jwt as a key when blacklisted. Give it an expiration time to match the refresh token. When it matches the blacklist, throw an error and remove from redis. Bonus, once it expires in redis, it will remove itself. Something like this would only occur if the user needs to log out of all devices, roles/permissions/relationships are updated for the user account, or they're deleted from the system. These are occasional actions. Most likely the redis instance will have nothing in it. This is a real low-cost solution and can be reused in multiple projects

[@shubhamagarwal1434]

About to reach 1 M subscriber...phenomenal.

[@xanzut]

Thank you for very good explanation! I have problem to understand one thing, if there's a potential security issue if JWT was stolen, then what makes its not a security issue if refresh token was stolen? because from my understanding (CMIIW), both of them are stored in the client side

[@RishabhSingh-eq4jf]

Same doubt

[@kossboss]

jwts contain an expiry date which is manually set during jwt creation.

[@PadurariuDragosh]

Great video! Thank you!

[@ns_the_one]

good content. thanks mate

[@vsakaria]

Absolutely fantastic

[@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.

[@twitchizle]

What is the point of jwt if you still need to query db for every request

[@je_suis_onur]

⁠@@twitchizleWell you can use a redis bloom filter for invalidated tokens. So it wouldn’t be a costly check. But yes that’s the cost of immediate invalidation while continuing to use JWTs and that’s the point you’re seeking.

[@twitchizle]

@@je_suis_onur but one can still use session token instead of jwt if they are willing to query db for invalidation. Jwt loses its purpose if you query db for auth.

[@je_suis_onur]

​@@twitchizle Difference is you have to cache every active session in Redis if you're using sessions, instead of a handful invalidated ones and just for a while (like 30m or so). Also session IDs don't give you the user information, that needs to be queried or cached separately while JWTs generally do. So the cost of total memory needed in Redis is much much much lower.

[@dealloc]

@@je_suis_onur Nothing stops you from putting information in a session ID. It's just generally not needed since majority of the data needed from that request is stored externally anyway. Constant sized session IDs are used exactly because they are fast to lookup. Chances are that the overhead of reading, de/serializing and verifying the token is greater than lookup a session ID. With something like redis or memcached you get expiration for free with no additional information or validation attached to the ID, since each entry can store its own TTL. Any form of trying to implement revalidation mechanisms for JWT is only adding more overhead and complexity that is not proportional with the proposed problems that it aims to solve.

[@sridamodara]

very well explained! i'm curious what tool he uses to create very nice graphics in his presentations? any pointers, from anyone?!

[@danyel8]

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?

[@iajaydandge]

Refresh token are stored on server and when logout action is performed corresponding refresh token is deleted, so that new access token cannot be created.

[@bisw4sh]

@@iajaydandge this widely varies. if you''re going to the db anyway, this reduces the stateless nature of jwt. idk if this is wrong or right, i myself have done this and have been questioned a few. some suggest having blacklist instead of active refresh token which again concerns a db/redis. this just varies according to the required security level.

[@iajaydandge]

@@bisw4sh Right. I forgot to mention the blacklist part. Still we will need a db/redis for blacklisted token. But db access is less as compared to session based auth.

[@petherpettersson6152]

We store our refresh tokens in the same column our old services saved their session id's, when someone requests a refresh we are able to check for whom it belongs to, and regenerate a jwt for that account. Can easily just remove the saved token to prevent further refreshes. Though this doesn't solve that the token will be valid until it expires. The best way of handling this, and keeping the contents of the tokens secure is the phantom or split token way, where you have some reverse proxy or middleware that keeps the proper token in cache and the client gets an id which is used to get the jwt. This makes it a session id approach for the client, but the backend can still get the benefits of jwt.

[@Ondraasha]

@@bisw4sh storing identifiers of refresh tokens after generating and issuing them is not a big problem with JWTs. Because, as mentioned in the video, the frequency of usage of refresh tokens is fairly limited - units of requests to refresh a token within an hour vs hundreds/thousands of requests per issued access token within its lifespan. Thanks to this, the storage service for refresh tokens requires much less scaling, because the amount of requests to it is marginal.

[@BeeBeeEight]

For me, it's sessions especially for very sensitive data like personal info, money, etc. Only use JWTs if your app is such that if hacked, the hacker can't do serious damage beyond knowing your first girlfriend's name.

[@vishaldindalkop294]

Thank you for the video

[@carlotadias9335]

Thank you. Isn't it an equally risky procedure to have a refresh token that lives during a long period of time? thank you in advance (and is the refresh token always the same?) shouldn't the authentication server return a new refresh token ?

[@tioModz-w6i]

Сразу лайк. Очень крутой пошаговый разбор, я в кайфе

[@wenyangwei9631]

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

[@elalemanpaisa]

Just cache the session id on the server instead of redis if it's a smaller scale

[@mhfereydouni]

Amazing content. How do you create the illustrations? Is there a easy to use application?

[@charlescoult]

Great visual aids 😊

[@ЯрославЯрмошик]

I don't understand the benefit of a refresh token if it, like the short-lived access token, is stored on the client side. What if the refresh token is stolen along with the access token? What is the advantage then?

[@pudgebooster]

you store refresh tokens on the server, that means you can revoke them

[@twitchizle]

​@@pudgebooster wrong.

[@twitchizle]

Actually you need 2 tokens. Because, access token holds the updated user info, refresh token is needed to update the user info. If you had no refresh token, user would need to log out and log in again to update the user info.

[@serdar_1978]

Hello, in classic database session validation Every time I receive a request from the client, I compare the session in the cookie with the session in the database. But if the user doesn't say remember me, even if I don't create a cookie, I still need to save the temporary session in the database, right? thank you

[@frankelma]

05:06 some error? 'refresh token' wrong and 'access token' right?

[@jafeta.7553]

Great videos!

[@AbhishekMadhu_online]

Thank you. What happens if the refresh token is stolen? How is that different from an access token being stolen (other than the fact that the server can invalidate it)? What if the server didn't know that the refresh token has been stolen? This way, the thief can keep generating access tokens, right?

[@mikkun_]

Oh, I thought when signing, we are using the public key, and for verifying, we are using the private key.

[@YoshiToshi2]

Thanks God this video has a subtitles. I can at least read what the author says.

[@iyadzac]

what about the use case when the user need to log out, isn't this hard in jwt compared to session? can we implement logging out feature with ease with jwt?

[@svorskemattias]

Just throw away the jwt!

[@WangAndrew]

Is there the scenario, the client application UI, for example, blazor wasm maybe updated suddenly due to the refresh token happened

[@AbhishekMadhu_online]

Also, one multi-billion dollar organisation that I integrated with uses single-use access toke - the access token expires after one use, and the response contains a new refresh token, which can be sent in the next request "like" an access token. Is there any benefit of using this quirky method (which made my life harder managing the tokens)?

[@Senshiii99]

Can't I store the refresh token server side? Exposing the refresh token client side could also potentially lead to theft, right? And that would be worse than access token theft. So can't it be stored server side and when a request hits the server and the server sees that the access token has expired, the server validates that token is not tampered with and if all looks good, the server automatically refreshes the access token, executes the request, and sends back the response. Also wouldn't this lead to one less round trip between the server and the client?

[@omartahboub2900]

In the case of Session based Auth, sensitive data fields in Session Object should be encrypted and securely persisted according to the hosting organization Security Compliance standards.

[@furycorp]

You put sensitive data in session objects?

[@omartahboub2900]

@@furycorp If the session object contains related user account fields they are deemed sensitive and should be encrypted. As I mentioned "In case", since organizations have liberty to define what Auth session would look like.

[@Baby-Programmer]

great job.

[@PabloGaraguso]

Excellent

[@haghighi251]

Very useful, as always.

[@stevebuonincontri6853]

hello - you have great videos. Do u have any formal training ?- I will check your website

[@MurthyGorty]

at 4:37, small typo: Auth Server returns a new access token, isnt it

[@imarchuang]

what if the JWT token is too large to be carried in the Cookie?

[@jacklevins9416]

If a JWT can be robbed, so can a refresh token, no? Does using same-site secure cookies prevent that?

[@kanways8]

Grate explanation

[@abhijitsarkar482]

In JWT, how is the token/secret key is persisted on the server side?

[@harishhari1310]

Thanks for the video. But In JWT based authorization, if user logged out, how can we invalidate the session

[@JoepKockelkorn]

By invalidating the refresh token. But typically there is no session so what logging out mean?

[@AtonC-h7k]

what the software you used to draw those flowchats?

[@raj_kundalia]

Thank you!

[@SandipChitale]

If the client is a single page app running in the browser, where to store the access token and refresh token. And how does short lived token help if refresh token flow is enabled. If the access token leaks then the malicious actor can keep extending the access token. And if there is a facility to revoke the access token, then we need to keep track of yet unexpired access token and that introduces state. IMO JWT is to some extent a false advertisement as a stateless solution. Also is JWT contains all the authorization info - which could mean a lot of groups then it may not fit in a cookie (HTTP only/Secure). How to deal with that? Also as JWT sent on every request, and is big because it contains a lot of claims then it is waste of network bandwidth right? All in all JWTs do not sound like a good choice. What do you think?

[@erilee84]

This video fails to explain some key questions 1) how are refresh tokens created and stored 2) if someone steals an access token, isn’t the refresh token equally likely to be compromised?

[@s8x.]

was just reviewing this and this dropped😂

[@zikkrype]

How to revoke access token, when i want logout from all devices?

[@ikhlasulkamal5245]

But what if the Refresh Token got compromised?

[@krivdaa9627]

server DOES store state - for refresh tokens

[@howyuyang4504]

As a backend, never trust client. Also, latency of using session is not significant at all. Bottle neck is always somewhere else.

[@ayushjindal4981]

Content is good, but speed was a bit fast and speech needs a bit more clarity. Thanks.

[@TheSemenFarada]

so we verify the jwt token with the private key ? What if the jwt token is issued by a single authentication server? Then the private key for validation should be distributed to every microservice? Is it secure?

[@svorskemattias]

You can use asymmetrical encryption instead

[@hahachannel7323]

thank you so muchhhh

[@Djgotskillz3x3]

Hi all, Im trying to decide whether JWT is the better option than sessions when trying to build an enterprise level django/react web application that is intended to serve 1000+ users. Goal of the descision is to chosse the application authenicaton method that I wont have to change down the line due to it not being secure/appropriate/feasible/scalable. I was under the impression that session authentica is easier to implement but not as secure / reliable / scalable as JWT. and that most enterprise/commercial level applications now have leaned towards JWT. any tips / thoughts would be helpful

[@tempura8390]

1. Session auth is actually more secure than jwt because it exists only on the server and can be revoked. 2. JWT is quicker and easier to implement since it works by trusting that the token was issued by the server. If you store all the necessary data in the token's payload, then you don't need to make a database search everytime you ask access to the API. 3. Scaling in what sense? Are you planing on doing microservices? If so, then you should use jwt if you want an eash solution. You could have a centralized cache db for sessions too though, although that's more money. Normally, apps start as a monolithic layered app, a frontend, a backend and a database since that is easier to make and can be deployed in a shorter time. This means you can actually just start with a simple session auth and call it for a day. If you REALLY expect millions of request tou your server in short periods of time, then you should start with microservices and JWT.

[@kamalhm-dev]

Just make sure you dont get the worst of both worlds, using JWT while also storing that JWT for validation in a centralized auth service

[@elixirfun]

Wait a sec... In the cookie-based session, the session data may also fit in the cookie itself, right? Then there's no need to store the session data it in Redis/DB, no?

[@JoepKockelkorn]

Yes, but space is limited.

[@rishiraj2548]

Thanks

[@notDacian]

Just building a small side project with JWT auth, i am using GO for the backend server and Vue for the client. Since i dont intend the app to be scaled horizontally i created a in-memory cache for all JWT's associated with every user, so that if you disable/delete a user all the JWT's associated with that user are deleted from the cache. If a new request comes in using a "stale" (as in not cache) JWT, i check the DB for the user. This is a hybrid approach since you can "revoke" all JWT's after a password change or if you disable/delete a user and so you can force authentication, but it probably wont scale on a big application, at least not with a in-memory cache.

[@iajaydandge]

@@notDacian This approach kind of mimic the session based auth but using jwt. The jwt based auth meant to be stateless so that you don't have to store user associated tokens on server.

[@notDacian]

@@iajaydandge Well i said its a hybrid approach, witch has its advantages and disadvantages. For modern JS webapps JWT's are kind of the default way of doing auth.

[@narkotikov]

so a refresh token cannot be hacked also?

[@JoepKockelkorn]

Computers can be hacked, what do you mean a refresh token can be hacked?

[@MaironCuello]

excelent

[@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.

[@brunogoismateus]

Do you know any resource where I can look it to understand well this approach that you've mentioned? Thanks in advance.

[@tempura8390]

So... I store the token on redis and i return the session id to the client, so each requests goes to that specific redis entry, get the token and validate it as a normal jwt? That actually sounds like a pretty interesting approach. No unnecesary db reads and the security provided by a session approach

[@erilee84]

1) you do not store sensitive info in a jwt. This is advised in its spec 2) you just swapped the jwt storage on the client side with an extra cookie? How is this different in terms of being compromised?

[@simple-stack-by-ed]

Nice ❤

[@marekvospel]

Do not teach people to use JWT for user authentication. It doesn't make sense from multiple points of view. 1) its less complex is absolute lie, you will probably still be checks like user isnt banned / deleted, so round trip to db it is 2) data in jwt isnt guaranteed to be latest, so to the db we go 3) any change to jwt data means setting a new token 4) there is no way to invalidate a token except storing a db of all revoked tokens... pretty shitty, if at some point a user is hacked, he can just watch and cant do anything about it

[@PhilipAnsel-p2b]

Dedric Springs

[@MalthusMill-l9r]

Lindgren Prairie

[@MuhamadAzizPrasetyo]

New achievements: JOTS

[@mehditaibi5193]

Arrows for step 6 and 8 on the thumbnail should be flipped

[@piyushaggarwal5207]

I never knew JWT is pronounced as Jot

[@sibusisoshongwe]

And here I was thinking of the James Web Telescope