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...
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!
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!
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.
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
@@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.
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?
@@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.
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
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 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.
ปีที่แล้ว +8
@@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.
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...
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 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.
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.
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’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.
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.
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 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
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)
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
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!
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 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
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 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.
Well he did mention session have issues when an application is scaled horizontaly and that tokens solve that problem. So he could have said more explicitely, but it eas said.
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
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.
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.
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?
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.
This is terrible. JWT should NOT be stored in local storage. That's extremely vulnerable to XSS and local storage should not be considered secure at all. Session cookies are absolutely vulnerable to CSRF, using "modern frameworks" doesn't do anything. You need to at least mark your cookie as samesite=lax (or strict), and any api endpoint that changes data needs to be POST.
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?
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.
You make the highest quality programming videos on youtube, great job!
I 100% agree with this
This guy doesn’t know shit.
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...
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!
45 likes and no replies in 3 years? I'll fix that
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
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!
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.
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
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.
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"?
I don't know how I could live so long without this channel
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
Yesterday I was crying myself to bed because of this, perfect timing :)
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.
Man you are simply gifted in getting ur idea to the audience.
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...
@@LuminousWhispers11 has anyone asked for a life advise here though?.. don't think so
)
Finally an authentication video that pronounces JWT correctly
If this is ur only problem 😂
Bro I need a “Whatever the heck i needed to know in order to understand this” in 100 seconds
By far the clearest explanation I've seen. Well done!
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
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 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.
Your timing is perfect. I was studying this.
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?!?
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.
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 love these 100s videos. You are on fire, literally
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
Your Bitcoin transfer has sailed through without a glitch-congratulations!
Addiction to small video with effective understanding!!!!!
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 :)
Please can you do a longer video on JWTs
Needed longer version for this
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.
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!
omg thank u for the simple and easy to understand way to explain things
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
you can also store whatever user data you want inside the JWT, which is handy and saves on traffic
i love your 100 seconds series. want more videos
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)
The best explanation on these stuff.
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
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!
sessions are just far safer,especially that tokens can be simply stolen
just love all your high quality and super informative videos 🤩
Typescript in 100 seconds.
Anyways, Your content is really useful.
I actually love this channel
What firebase uses for authentication ?
You can do both with Firebase, but it defaults to token-based
@@Fireship How would we know if it's token or session?
Absolutely wonderful explanation! Thank you for this video :)
I think your audio would benefit from a de-esser plugin. Great video as usual, though 👍
You forgot to say "... and see you in the next one" at the end
1:06 Would have liked to hear what some of these challenges are.
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
@@MF-ty2xn how can access token be easily stolen but not refresh tokens ?
@@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
underrated topic but very important
Dang this channel is _really_ good.
I felt you spoke slow for the first time :)
What's a better form of authentication and authorization? Preferably one that can be implemented in Java or Spring Framework
100s of OAuth would be a great follow up
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.
Please, create a video about OAuth authorization. Thanks in advance !
As I got from the video; Sessions are recommended for web applications, and tokens are better for mobile applications, right?
production content in 100 seconds!!
You forgot to mention one of the most important pros of Tokens: Tokens issued by any server can be verified without server-to-server communication.
Well he did mention session have issues when an application is scaled horizontaly and that tokens solve that problem. So he could have said more explicitely, but it eas said.
Love your vids, super clear super fast hehe
this was ao perfectly timed for.me...i actually came for a video like this
Would love to see content on DPoP and mTLS
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
awesome as always but the music is too loud
Do a recursive function in 100 seconds video. If you are wild enough!
Even though I *should* use the Authorization header, I don't.
I just slap on a ?token= to my request and boom, job done!
The best channel !
Is TH-cam built with SPF?
SPF in 100 seconds? 😏🚀
Thank you for making this video!
Good video, I liked the explanation
Would be nice to include web authn to the comparisons. As it kinda mixes both.
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.
Thank you! I was needing this
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.
why not store jwt in cookie instead of local storage. Isn't it safer?
Sure, but if you're going to use cookies, then you don't really need JWT tokens.
@@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
Thumbs up from Bartosz for his great work!!
Thank you :D
which one is more safer to use??
is there a coupon for the websecurity academy?
Your videos are superb!!
Your videos are great. Thanks dude.
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'm literally thinking thinking about Token, Thanks for this Video 👍
At 1:40, what does it mean that web tokens "can't be used to authenticate a user in the background on the server"?
I was just wondering this today omg!
i am watching a 2:17 min ad ..
Hooray new video!
This is terrible. JWT should NOT be stored in local storage. That's extremely vulnerable to XSS and local storage should not be considered secure at all. Session cookies are absolutely vulnerable to CSRF, using "modern frameworks" doesn't do anything. You need to at least mark your cookie as samesite=lax (or strict), and any api endpoint that changes data needs to be POST.
Great discover
Can we get a beyond 100 seconds on this topic
Please make a 100 sec video on NestJS
What's the "vice versa" for "use the right tool for the job"? "Use the right job for the tool"?
Please make a video on SOLID Design Principles If Possible.
What vscode for js does Fireship use in their tutorials?
Stupid question, can't the server also sign cookies?
How does discord's token authentication work?
discord uses authentication tokens that dont change or expire,and they can be stolen,they change only when password is changed.
Amazing video sir!
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?
Can you do Yarn/NPM in 100 seconds?