Session vs Token Authentication in 100 Seconds
ฝัง
- เผยแพร่เมื่อ 4 มิ.ย. 2024
- Learn the difference between session and token-based authentication on the web. Master Web Security in 12 weeks 👉 websecurity-academy.com/?aff=... Enroll before the deadline on 31st Oct (Saturday).
#web #security #100SecondsOfCode - วิทยาศาสตร์และเทคโนโลยี
![[UNCUT]"เศรษฐา" โดนบีบให้ลาออก เผยดีลลับ "ทักษิณ" ต้องต่อโปร ไม่งั้นเจอจุดจบ! I คนดังนั่งเคลียร์](http://i.ytimg.com/vi/XlH3k81dxmE/mqdefault.jpg)
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.
I didn't even searched for something like this, just thought of it...
TH-cam algorithm at its finest
Universe at work.
Real
You mean this channel uploaded the video right after you were searching for it in google?
Fireship is on fire with regular uploads.
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.
I became addicted to this channel, I feel it is like my daily injection that I can't live without.
Knowledge is a hell of a drug
yes you're goddamn right
Absolutely true. It's the same for me too🔥
Me too
SQL injection
You make the highest quality programming videos on youtube, great job!
I 100% agree with this
This guy doesn’t know shit.
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!
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.
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?
@@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
@@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).
@@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👍
@@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...
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?
Thank you. Good idea, I want to cover more DBs in this format.
@@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.
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.
@@Fireship hello there, do make
RUST in 100 seconds and
React state management in 100 seconds
@@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"?
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!
Your juniors can get the info here. Give them a bit more than 2 minutes. They will appreciate it.
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!
By far the clearest explanation I've seen. Well done!
I don't know how I could live so long without this channel
Man you are simply gifted in getting ur idea to the audience.
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.
th-cam.com/video/4KHiSt0oLJ0/w-d-xo.html
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.
I love these 100s videos. You are on fire, literally
Your timing is perfect. I was studying this.
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
I don't think JWTs are that complicated. It's all handled with standardized libraries that make it quick and pain-free
@Jack Lusher Sessions for the win!
can you provide more details ?
@@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.
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.
Yesterday I was crying myself to bed because of this, perfect timing :)
Finally an authentication video that pronounces JWT correctly
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
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
just love all your high quality and super informative videos 🤩
Thank you! I was needing this
I'm literally thinking thinking about Token, Thanks for this Video 👍
Addiction to small video with effective understanding!!!!!
The best explanation on these stuff.
I actually love this channel
omg thank u for the simple and easy to understand way to explain things
Absolutely wonderful explanation! Thank you for this video :)
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, TH-cam, and thanks, Fireship!
i love your 100 seconds series. want more videos
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
Love your vids, super clear super fast hehe
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.
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
@@LilmeMusic Ideally it would fall on the user but users are fucking stupid lmao
@@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
@ 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.
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)
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.
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.
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.
Thank you for making this video!
Your videos are great. Thanks dude.
Dang this channel is _really_ good.
this was ao perfectly timed for.me...i actually came for a video like this
Your videos are superb!!
Bro I need a “Whatever the heck i needed to know in order to understand this” in 100 seconds
The best channel !
We store both JWT and the refresh token in cookies. It seems to be the most balanced solution between security and scalability.
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).
@@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.
@@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
@@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...
@@theraven.4 has anyone asked for a life advise here though?.. don't think so
)
underrated topic but very important
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?
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
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?
Cookies are not vulnerable to CSRF attack if you set the sameSite with a value of lax, mark it as http only and secure.
I was just wondering this today omg!
I think your audio would benefit from a de-esser plugin. Great video as usual, though 👍
Hooray new video!
Needed longer version for this
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.
Oh yeah, thanks Jeff!
Nice content as always :D!
Please can you do a longer video on JWTs
Please, create a video about OAuth authorization. Thanks in advance !
What's a better form of authentication and authorization? Preferably one that can be implemented in Java or Spring Framework
Would love to see content on DPoP and mTLS
Would be nice to include web authn to the comparisons. As it kinda mixes both.
What vscode for js does Fireship use in their tutorials?
Wow finally i understand jwt
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
Amazing video sir!
Im storing the JWT token on cookies with some user info (an user ID basically) on the service im developing, do you think that's secure enough?
Typescript in 100 seconds.
Anyways, Your content is really useful.
100s of OAuth would be a great follow up
On point!
Do a recursive function in 100 seconds video. If you are wild enough!
As I got from the video; Sessions are recommended for web applications, and tokens are better for mobile applications, right?
At 1:40, what does it mean that web tokens "can't be used to authenticate a user in the background on the server"?
production content in 100 seconds!!
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 ?
Can I get a link to the playlist of your background tracks?
what about refresh token and access token. can we solve the token based problem this way.
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.
@@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?
@@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.
@@daheck81 nice, thanks :)
simple and fast :)
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?
I think the server only has one private key, but honestly I have no fucking clue.
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.
I have created custom email password login system in django. The problem is when I type url '/home', it reached homepage and not login page whenever I put '@login_required' decorater. Should I need that session or token.Or should I use auth0.
Please make a video on SOLID Design Principles If Possible.
aamazing channel
That's a great video. Could you share the source of the awesome background music?
advanced level tutorial
thanks!
Thanks
Wow, TH-cam has a different description setup on the app.
An the icons are more "hd"
Are you internet explorer or what
And much better
This is getting very weird
Woah, how does this have 41 likes?!?
which one is more safer to use??
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!
so here is the question both session and token are stored on client side - then browser will send both of them as header, can someone explain how session is manipulated server side ? cause i don't get the last part of this video
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.
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
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.
what about storing some info in the JWT claims section? Is it a good idea?
@@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.
is there a coupon for the websecurity academy?
You forgot to say "... and see you in the next one" at the end
Which software is used to make this animation?
Can you do Yarn/NPM in 100 seconds?
LOVE
Video idea (that i would love) : LDAP in 100 seconds
if ssl is not implement then jwt token is vulnerable right?
sessions are just far safer,especially that tokens can be simply stolen
It is possible deal with load balance with cookies? How to load a page with images where url of images are protected? How get images in protected api with jwt?
Amazing