Session vs Token Authentication in 100 Seconds

[@lolllolol5416]

I am actually suspicious if you are creeping on my search history, 3 times in a row you gave me what I wanted to understand the next day.

[@luxunited5449]

I didn't even searched for something like this, just thought of it...

[@sarcasm1015]

KZbin algorithm at its finest

[@naniy143]

Universe at work.

[@jimhalpert9803]

Real

[@ansadahmad1958]

You mean this channel uploaded the video right after you were searching for it in google?

[@princesharzeel8237]

Fireship is on fire with regular uploads.

[@AreyHawUstad]

This one looked sponsored. But who cares, Jeff explained me JWT in 100 seconds which I had been struggling to understand since a few months now.

[@michalurban8536]

You make the highest quality programming videos on youtube, great job!

[@mwimb6716]

I 100% agree with this

[@fieryscorpion]

This guy doesn’t know shit.

[@CodingWithLewis]

I love that in the video you never gave a reason as to why one was better than the other. Cyber Security is a field that is just constantly being evolved and I loved the explanation of both. JWT has been an incredible tool I've used for a while now and I will not go back. Always love the videos Fireship!

[@786ranabasharat]

45 likes and no replies in 3 years? I'll fix that

[@aladdinovich]

I became addicted to this channel, I feel it is like my daily injection that I can't live without.

[@hampuswestman8722]

Knowledge is a hell of a drug

[@fadilrahadiansyah4223]

yes you're goddamn right

[@soumyajitdey5720]

Absolutely true. It's the same for me too🔥

[@graf_tec]

Me too

[@Evoleo]

SQL injection

[@mikemartin6748]

You can also do token-based authentication with cookies. You just store the user id, expiry, and signature in 3 cookies or in 1 cookie with a separator and roll your own standard for concatenating the user id and expiry and hashing it to check the signature. In reality, JWTs are just a standard for doing exactly that.

[@zedshockblade7157]

This i what i’m trying to figure out. If you store the jwt in a cookie/http only cookie. Is it still considered as token based auth? Or it is now cookie based auth?, Also if you indeed store the jwt in the cookie, how can you attach the jwt on the header as bearer token in your request?

[@DarkWaffle56]

@@zedshockblade7157 cookies are sent automagically to any requests made to the specific server in which they were created, so you don’t need to include them in the headers manually

[@igor9silva]

​@@zedshockblade7157 those are 2 separate things. Manually adding the SECRET (let's call it that, for now) to the Authorization header on every request versus storing it and as a cookie (and letting the browser automatically add the cookie header on every request) will achieve the very same goal. Now, there's the SECRET type. A "session" is a token you generate and store in memory or disk storage. You have to check the user sent SECRET through a list of valid sessions every request. The "token" is signed using a hashing algorithm, so you can mathematically prove you are the one who created the token (and not someone else). That way, you don't have to go through a list, you just trust it. One con of the that last approach is that you can't revoke a token (by removing it from the valid tokens list). That feature can be important in some systems (e.g. revoke every user session when he changes the password).

[@TheFeljoy]

@@igor9silvaThis is the correct answer. How you transfer the data (cookie or header) is not really important for how the validation works. Also really good tip about revoking access control👍

[@Vichion]

​@@igor9silvacouldn't you just use a UUID for every device for this method? So you concat and hash user id, username and the device uuid, if that token doesn't match one stored on the server then access denied...

[@KanagawaMarcos]

Man, you way of teaching "something in 100 seconds" is awesome. I'll try to do the same in my work with juniors, you're in inspiration!

[@davedurkee8853]

Your juniors can get the info here. Give them a bit more than 2 minutes. They will appreciate it.

[@estym_]

That's a really quick yet good introduction to Session and Token Authentification, that no joke helped me have a better understanding of these authentification methods x) What about Redis in 100 Seconds for a future video?

[@Fireship]

Thank you. Good idea, I want to cover more DBs in this format.

[@daheck81]

@@edwardsmale3977 Redis is just a key value store which makes it extemely fast. Adding/reading/removing data works basically like the local/session storage in a browser. It’s mostly used for storing session or caching data.

[@gaoalexander73]

With serverside sessions, its common to shove that data it into some external memory storage like redis. It frees up load on your database, plus that data doesn't need to be persistent anyways. And it keeps your api servers or w.e stateless, makes it easier to autoscale stuff while it sits behind a load balancer.

[@yt-sh]

​@@Fireship hello there, do make RUST in 100 seconds and React state management in 100 seconds

[@Spreadlove5683]

@@Fireship At 1:40, what does it mean that web tokens "can't be used to authenticate a user in the background on the server"?

[@ZyncInteractive]

Every-time I see one of these new 100 seconds of something video show up in my playlist, brightens my day a little more. Thank you for producing great content!

[@JosephLuklukkyjoe]

please make a video on CORS please! I think it's one such topic where others watch 10 videos on it and still don't get it but you knock it out the park with one 100 sec video.

[@felixdeiters7518]

kzbin.info/www/bejne/anyrmoaqZdR_gJI

[@Yaxqb]

A hot recommendation, don't use JWT if you don't have scaling issues. It just complicates things and you'll likely to reimplement things that sessions solve for you

[@mikemartin6748]

I don't think JWTs are that complicated. It's all handled with standardized libraries that make it quick and pain-free

[@hk.32]

@Jack Lusher Sessions for the win!

[@bossgd100]

can you provide more details ?

[@codinginflow]

​@@mikemartin6748What library handles the refresh process in a pain-free way? Except for full-blown backend services like Supabase. And then you still have the problem that you can't invalidate a token instantly when your account was hacked and you need to change your password.

[@dandayne]

Unless you develop your server in Assembly or have a compulsory need to reinvent the wheel by writing your own code for everything, this isn't true.

[@brucewayne2480]

I use both at the same time : tokens to make front end independent from backend logic and sessions to store refresh tokens for each issued token and tracking sessions' number

[@JordanPlayz158]

Interesting, I permit both so I don't need to make a frontend and backend api, feels like it just needlessly complicates things, couldn't find any articles about pros and cons of doing this? Is there any benefit, if so I'd be greatful if someone can let me know

[@miQize]

By far the clearest explanation I've seen. Well done!

[@Joerje]

Yesterday I was crying myself to bed because of this, perfect timing :)

[@KBoB5arc]

I don't know how I could live so long without this channel

[@osamaa.h.altameemi5592]

Man you are simply gifted in getting ur idea to the audience.

[@lwinklly]

Finally an authentication video that pronounces JWT correctly

[@MrWesopl]

If this is ur only problem 😂

[@Klayperson]

To help prevent stolen authorization tokens from being too dangerous, make them expire very quickly and implement a refresh token so that properly authenticated users can automatically receive fresh auth tokens before expiration so they don't have to keep relogging in.

[@LilmeMusic]

No. If you make the token expire quickly, then the user has to log in way more frequently. A token is created when a user logs in with lets say a username and password. If that token is set to last for 30 mins, then during that 30 mins, if the user logs out, he doesn't have to enter his username and password to log in, he would enter the website automatically. But once 30 mins has passed and the user closes the website, the token will expire and he would have to put the username and password again to enter the website and create another token that would last another 30mins. The longer the token time, the less frequently the user has to log in with his username and password. And there is actually no need to fear hackers lmao(I can explain why if you want to know but JWT's are virtually impossible to hack). The only way is if the hacker steals the device of the user and the jwt has not expired yet, the hacker can just login freely, which just makes him a thief, lol. The responsibility of keeping the device safe falls on the user, not the web server(your server) but yeah you could make the jwt expiry time very short but I dont think its worth it

[@niccpolitic6129]

@@LilmeMusic Ideally it would fall on the user but users are fucking stupid lmao

[@buddh4r]

@@LilmeMusic That's why he mentioned the refresh token. If the auth token expires, the refresh token is used to get a new one. The refresh token will be valid for way longer than the auth token.

@@buddh4r isnt that just passing the problem to refresh token? Someone can hijack refresh token and keep making auth tokens

[@buddh4r]

@ The refresh token should only be sent when required so e.g. when using cookies, set a path in order to only include the cookie in the refresh request, you can also invalidate refresh tokens once they are used and create a new one (this may requires some server state). But yes generally if the refresh cookie is stolen its bad, but its the same (or less) risk as using session cookies which are not invalidated (at least not very often when using long sessions) and send with every request.

[@tylerdurden2832]

Your timing is perfect. I was studying this.

[@DontBeMadBro]

I love these 100s videos. You are on fire, literally

[@raniathemri949]

i am addicted to your content it is understandable simple and gives a general overview in few minutes so when i intend to learn something i come here first lots of thanks.

[@smakosh]

Cookies are not vulnerable to CSRF attack if you set the sameSite with a value of lax, mark it as http only and secure.

[@MiladCale]

We store both JWT and the refresh token in cookies. It seems to be the most balanced solution between security and scalability.

[@Mankepanke]

Sounds very bloated more like. You'd get the negative parts of both without the positive parts of either (not that JWT has any positive parts in the first place, though).

[@uwirl4338]

@@Mankepanke "Not that JWT has any positive parts in the first place" then why oh why are people using it enough for it to be one out of the two standards for web authentication? Why, Magnus Bergmark, why? People will really fanboy over the tiniest things.

[@samplebriefmint4204]

@@uwirl4338 Mostly because of it's simplicity. I'd concur that security wise, well implemented sessions are most likely more secure than well implemented JWT, but JWTs are easier to quickly add to any codebase, especially with the popularity of "serverless" nowadays, I think

[@LuminousWhispers11]

@@uwirl4338 .... When you are in a argument never ever attempt to bring up that just because people uses a technology means that is good... Also, the amount of people using it doesn't relate to why it is a standard...

[@yehor_ivanov]

@@LuminousWhispers11 has anyone asked for a life advise here though?.. don't think so )

[@johnhopkins4752]

Bro I need a “Whatever the heck i needed to know in order to understand this” in 100 seconds

[@igor9silva]

I do sessions so I can revoke them (kept on Redis cache, purged on revoke), but I do encapsulate it into JWT tokens so they can contain more (and signed, verifiable) data. As the transfer protocol, I do cookies 😅 best of both worlds.

[@jackdavenport5011]

To me, using http only cookies is the better option. Not only are they automatically attached to every request, but they can’t be stolen with an XSS attack unlike using localstorage.

[@NNNedlog]

While watching this, I got a notification of your video "C++ in 100 seconds". Do immediately I finish this, I'll head over to the new video

[@SharkForG]

With an SPA JWT is a good solution but with its downsides. I am trying some workarounds to make it stateful ( I know, I know…) but easily manageable and light without refreshing the token all the time or hitting the database. So, when user’s logging in, I generate a private key with a passphrase ( the hashed user’s email + ID) and saving the key to a file. The filename of the key is a hash of the hashed user’s email + ID + user agent. In the database I just track the generated filename, user id, agent and timestamps. When a request is made this public information from the payload is combined so the private key file can be fetched. If the user agent is different or the key file is deleted, then the file can’t be found so the JWT can’t be validated. If everything is ok the public key is extracted from private key, validating the JWT. Thoughts?

[@LilmeMusic]

JWT's dont hit the database, no need to waste your time. We store nothing on our servers and database, if we did there would be no point, we would just go back to sessions. JWT's are secure enough, dont worry

[@pranavbakare8922]

Addiction to small video with effective understanding!!!!!

[@mohamadrezamotaghi7427]

The best explanation on these stuff.

[@kamiyabasamadi4166]

what about refresh token and access token. can we solve the token based problem this way.

[@daheck81]

It’s not solving the problem in general but it makes it harder to exploit. So definitely a way to go. The safest approach using JWTs is to store/send them as httpOnly + SameSite cookies while using the accesss/refresh token approach.

[@rumble1925]

@@daheck81 Hmm I'm sending the jwt as a response and save it to localstorage but use httpOnly + SameSite cookies for the refreshToken. Is that an ok approach?

[@daheck81]

@@rumble1925 Yes, that’s actually how I'm using it most of the time as well. As long as you keep the expiry time of your access token low (< 15 mins) this is safe enough.

[@rumble1925]

@@daheck81 nice, thanks :)

[@TheScoobysteve]

So I've been working in my first programmer job for about two months now. Anytime I have a 'Hello, World! ' moment the very first place I look is always these 100s explanations.

[@saiddope2241]

omg thank u for the simple and easy to understand way to explain things

[@DrJimmyBob]

I actually love this channel

[@ytsharmahandle]

just love all your high quality and super informative videos 🤩

[@Daniel__y3i2]

Your Bitcoin transfer has sailed through without a glitch-congratulations!

[@matteomartellini20]

Maybe this is one of those topics where the "... 100 seconds" format doesn't work, the limitation of time doesn't expose all of the important facts about both authentication You make look like tokens are more secure and practical than sessions while there is much more to be said on pros and cons of both to let the developer really understand which one it's better for the job, I still think both methods can be used for different types of authentication.

[@CodingUnited]

Wow, KZbin has a different description setup on the app.

[@_jn0298]

An the icons are more "hd"

[@SirusStarTV]

Are you internet explorer or what

[@sarvagya-sharma]

And much better

[@iyxan23]

This is getting very weird

[@CodingUnited]

Woah, how does this have 41 likes?!?

[@LimitedWard]

I still don't understand how tokens solve the storage issue. What aspect of the JWT uniquely identifies the user? Edit: I get it now. JWTs are cryptographically signed. So the server just decrypts and validates the token data

[@benamato2880]

you can also store whatever user data you want inside the JWT, which is handy and saves on traffic

[@ShilohFox]

Absolutely wonderful explanation! Thank you for this video :)

[@S3Kglitches]

You should talk about that tokens and cookies stored privately from other websites etc. this would explain how an attacker can hijack the JWT - basically only copy it from the machine physically (except man in the middle attack where he can read HTTPS traffic)

[@Jordan-er9bx]

Please can you do a longer video on JWTs

[@whonayem01]

i love your 100 seconds series. want more videos

[@huh_wtf]

this was ao perfectly timed for.me...i actually came for a video like this

[@zugdsbtngizudsgbnudsdsoiu]

Its basically the same because the session is also a token and the cookie is sent as an http header so who cares if its cookies or authorization. You can also use JWT tokens and implement your own session handler to achieve stateless sessions. They dont contradict each other. Also stateless with JWT works in theory but if you have to revoke a token before it expires you have to store it. To my understanding if you have a 1 hour access token and ban a user in the worst case at minute 1 he has 59 minutes left to do harm.

[@DarkWaffle56]

That’s why I am storing my JWTIDs such that if the user changes password or if I want to revoke his session(s), then I can. Without storing the JWTIDs I wouldn’t be able to manually revoke his tokens without waiting for the expiry time of each of his tokens. The con is that I have to query the database for every API request. Oh well, nothing is perfect lol, but this works for my company’s app

[@onionware1]

Don't forget to save a timestamp, when the user changes its password. Then check if the JWT was issued AFTER that timestamp. Otherwise, a hacker can steal the JWT and can still login, even when the user changed his password after he recognised that his account got hacked!

[@nothingnoone8752]

Dang this channel is _really_ good.

[@NicolaiWeitkemper]

1:06 Would have liked to hear what some of these challenges are.

[@MF-ty2xn]

If someone is able to steal the token, they would be able to do as many requests they wanted pretending to be that person, that's why it's important put a short expiration time the tokens and use refresh to keep them logged for longer time

[@shashikanthp3145]

@@MF-ty2xn how can access token be easily stolen but not refresh tokens ?

[@MF-ty2xn]

@@shashikanthp3145 Tokens are sent everytime to the server on the moment to get resources to verify user identity, refresh tokens however would just be exchanged with the auth server to refresh the token when necessary this make it less risky for the refresh token to persist for long time

[@metallicadead]

Ha, funnily enough i’m currently in the middle of creating a mock shopping site coded with javaEE as a group project for school using JsessionId and running the Jdbc to access an SSMS database, and I was just wondering if there was another way to do identification to allow the management of a large amount of traffic. Perfect timing, KZbin, and thanks, Fireship!

[@danielbrambila7018]

Love your vids, super clear super fast hehe

[@tyc00n]

underrated topic but very important

[@sitri2727]

sessions are just far safer,especially that tokens can be simply stolen

[@jamesfoo8999]

Unfortunately if you want to use JWT with some level of control over invalidating tokens and logins, you have to store them in DB with an expiry and/or disabled column, and then you app needs to lookup the DB row to check the token is still valid/enabled.

[@ggar493]

what about storing some info in the JWT claims section? Is it a good idea?

[@jamesfoo8999]

​@@ggar493 You could, such as the hashed password and when a token is reported to be stolen etc change the users password and then hashed password in token wont match hashed password when you check it. However, whatever you put in the token you have to check on every request, the same as storing it in the DB with a "valid" column. The DB approach is simple and more likely for devs to understand. Also, the info in a token would have to be sensitive to the user somehow, then you're sending sensitive info around the net, encrypted or not it should be avoided, as this is a primary reason for tokens - authenticate with sensitive data once then use the token.

[@yt-sh]

Thank you for making this video!

[@sagnikpradhan3594]

Needed longer version for this

[@googleuser9422]

Thank you! I was needing this

[@ITheAvengersI]

What firebase uses for authentication ?

[@Fireship]

You can do both with Firebase, but it defaults to token-based

[@andrewding746]

@@Fireship How would we know if it's token or session?

[@macoshev9774]

The best channel !

[@craft5875]

Typescript in 100 seconds. Anyways, Your content is really useful.

[@jbraat]

Your videos are great. Thanks dude.

[@Flynn1411]

Your videos are superb!!

[@ztest2975]

Please, create a video about OAuth authorization. Thanks in advance !

[@brawnie3969]

Good video, I liked the explanation

[@danko95bgd]

Can you make a video on casbin (authorization policy) lib. It's available in many languages and it would be nice if you could explain it, maybe even create few routes for demonstration.

[@nodidog]

I think your audio would benefit from a de-esser plugin. Great video as usual, though 👍

[@NIKHILVERMA-xr7lc]

production content in 100 seconds!!

[@connorallen162]

I didn't realize client-managed state was the point of tokens. I've been generating tokens and saving them in the database. I guess just using the token like a cookie? It's worked fine for small stuff though

[@Penguinz-fr1mu]

I was just wondering this today omg!

[@nabiisakhanov3522]

Hooray new video!

[@JanasV]

What's a better form of authentication and authorization? Preferably one that can be implemented in Java or Spring Framework

[@02orochi]

Wow finally i understand jwt

[@patrickmullot73]

Thumbs up from Bartosz for his great work!!

[@DevAcademyCom]

Thank you :D

[@teamgartz-motorsports6881]

Would be nice to include web authn to the comparisons. As it kinda mixes both.

[@nathanjbro]

You forgot to say "... and see you in the next one" at the end

[@Spreadlove5683]

At 1:40, what does it mean that web tokens "can't be used to authenticate a user in the background on the server"?

[@videomakville]

What's the "vice versa" for "use the right tool for the job"? "Use the right job for the tool"?

[@santokhan_]

advanced level tutorial

[@pancho3322]

As I got from the video; Sessions are recommended for web applications, and tokens are better for mobile applications, right?

[@nicetomeetugaming7024]

Amazing video sir!

[@SamarthCat]

Even though I *should* use the Authorization header, I don't. I just slap on a ?token= to my request and boom, job done!

[@cm3462]

aamazing channel

[@JhoseinProductions]

100s of OAuth would be a great follow up

[@GaneshGfx]

I'm literally thinking thinking about Token, Thanks for this Video 👍

[@kodiak9664]

So do tokens typically use symmetric or asymmetric key pairs to validate the signatures? And either way, the server still has to generate unique key pairings for each token and then store the private key doesn't it? But that's still more efficient that storing sessions IDs?

[@AdroSlice]

I think the server only has one private key, but honestly I have no fucking clue.

[@ben.pueschel]

The idea is that you have one key pair for all of your tokens that you might want to swap relatively frequently. Anyone could then validate the generated tokens but only the server could generate them. With purely stateless tokens the server would only need to check if the signature matches (but you might want to store revoked tokens in a database to handle revoking access) and then authenticate whatever user is specified in the token itself. The server doesn't need to keep track of all the sessions and only has to validate if the signature is valid or not. You should never use symmetric encryption in that use case.

[@FalseDev]

Oh yeah, thanks Jeff!

[@Alex-uf2ie]

What vscode for js does Fireship use in their tutorials?

[@mohammadtanweerahmed3636]

I didn't het the part "it just have to verify the signature" so nothing stored on database. The token is sent with prefix Bearer what does token consists of ?

[@buka.a]

which one is more safer to use??

[@oitan]

why not store jwt in cookie instead of local storage. Isn't it safer?

[@fred.flintstone4099]

Sure, but if you're going to use cookies, then you don't really need JWT tokens.

[@juliusgrybauskas7643]

@@fred.flintstone4099 well if you want stateless auth you still need some sort of token, since we need to somehow verify that token is valid

[@ayushpratap4726]

Please make a video on SOLID Design Principles If Possible.

[@gabrielpfgm]

Would love to see content on DPoP and mTLS

[@marcinkarbowniczyn9226]

One question, can we say that using JWT is more stateless than using regular Tokens (like Django Tokens)? What I mean is, when we use regular Tokens we store them in the database. Every time there is a request with a Token in the header, we seek for it in the database and return a user connected to the Token. On the other hand, JWT may only store an ID of the user, so when the JWT is being sent, we decode it in our code and query for the User to the database. Do I undarstand the processes correctly? I also don't fully get it how JWT would be more efficient in larger apps, even though in both approaches we make queries to the database.

[@gustavoshigueo]

Imagine a logged in user wants to save a post. They send you the post's text and the authentication data, for a session, that'd be a session ID. To save the post you need the user's ID, so you query the DB for "Which user does this seesion belong to?" and then you are able to create the post with the ID. With a JWT, you just verify the signature and decode it. The JWT already contains the user's ID, so you can immediately use it to save the post. You only need to hit the database for user info when their id isn't enough, e.g. getting the username. But it's still slightly faster than a session, because that'd envolve a JOIN

[@ctfries1049]

Can you do Yarn/NPM in 100 seconds?

[@collimarco]

Sorry, but this time your explanation is **COMPLETELY WRONG**. You can use session / cookies without storing a session id server side. Session are perfectly scalable and are not bound to a specific server (each request can be sent to a different server). Also the session content can be signed and a proper implementation is not vulnerable to CSRF. See how Rails implements sessions for example.

[@carlotadias9335]

Hello, what do you mean that token are managed on the client ? Are they not produced in the server ? I didn't understand this last part. Thank you for the video, 0.75 speed to be able to follow.

[@AAA79797]

they are created on the server and and sent to the client, then the client stores them in local storage and the server in db etc.

[@carlotadias9335]

Thank you !

[@XoLucyna]

It was really great and quick video but i've got some questions, when the server creates the session in the database does few or some services creates an expire time? like can the session be expired or invalid after 1 hour or after the defined amount of time? or sessions don't have any expire rate?

[@aviet90]

I felt you spoke slow for the first time :)

[@Wakkyguy]

Can I get a link to the playlist of your background tracks?

[@ahmedraed8645]

awesome as always but the music is too loud

[@YosepRA]

So.... JWT is just a fancy way of implementing login system similar to something like passport-local's session cookie. And we want to use JWT for an increase in performance because we don't have to access DB for each request to deserialize cookie data and only do it when the token needs to be refreshed? Damn it...

[@ДмитроПрищепа-д3я]

lso, passport-local is just a local strategy that uses username and password(or generally any two fields you wish, really), you can implement it in any way you wish, like using JWT instead of sessions for example.

[@gabimoncha]

So what's the best way of authentification then?