I was fully prepared for sarcasm and snark. Instead I got the most useful short intro on web-authentication there is.
@snowballeffect78125 ай бұрын
We were taught how to roll our own auth at my boot camp just so we could have a deeper understanding on how it works and what can go wrong. Super valuable skill to have! to clarify, we did this from scratch, including hashing and salting passwords and using session tokens.
@vaishnavejp92475 ай бұрын
that all of ben's videos
@petleveler83665 ай бұрын
@@snowballeffect7812 that is the basics everyone should know that
@snowballeffect78125 ай бұрын
@@petleveler8366 you'd be surprised, apparently. maybe they do know that, but it seemed rare for anyone to implement working auth from scratch.
@snowballeffect78125 ай бұрын
@@petleveler8366 not sure why my response was deleted lol. but I'll try again and say that I don't think most devs have implemented auth from scratch on their own.
@msilence20095 ай бұрын
I PERSIST MY TOKENS ON MY ARMS USING TATTOOS.
@victor_aiyeola5 ай бұрын
Most secure! ☠
@ifeanyinneji77044 ай бұрын
😂
@goober91055 ай бұрын
No way hes back
@2breezy8665 ай бұрын
We are so back
@yaaaayeet7455 ай бұрын
hostinger bro :)
@zweitekonto96545 ай бұрын
guess what, he is
@emptytank6045 ай бұрын
This was quite possibly the best and most concise explanation of how to implement auth I have seen. Thank you!
@AndrewScofield5 ай бұрын
Great high level tutorial for a very confusing topic! There are so many tutorials out there that make it seem like you have to start out at enterprise level complication, when in reality a setup like this is going to work great for most people.
@zb27475 ай бұрын
Very concise explanation of JWT vs Sessions. Interesting to see how your take on the two has developed over the years. I find your videos super helpful when it comes to doing auth without 3rd party Lastly, it’s great seeing you Ben. Much peace and success brother
@vinceerkadoo455 ай бұрын
Literally popped on my suggestion seconds before i was going to search for this!
@ghdshds18995 ай бұрын
damn google really has your personal data dead to rights
@MaxPicAxe5 ай бұрын
I can't believe you just explained so much about auth I had no idea about in this short video, so well. Thank you.
@mikealejandro39385 ай бұрын
Ben, you're mi inspiration for becoming a web dev, it's been like 3 years since I started this journey seriously (at 17), now I have a decent job, thanks for existing brother, love your vids, we miss you homie !
@cryptophil853 ай бұрын
I've just watched several videos on this topic whilst deciding on how to proceed and this is by far the best one. I love fireship vids but this extra depth into pros and cons gives Jeff a run for his money. Keep it up! I'd love to see a collab between you two.
@schism155 ай бұрын
Perfect timing for this. I had just decided to try rolling my own auth on my latest side project since its not critical, will be low traffic and I'm tired of auth feeling like such a black box.
@buzz1ebee5 ай бұрын
He's back! Great overview. I've rolled my own auth quite a few times and this is a great guide. Recently I've been using a self hosted zitadel instance for the user management and I have a reusable nestjs module for handling all the zitadel oauth stuff and session management etc. Super easy to add additional auth providers or implement 2fa via settings on zitadel without changing anything at all on my backend which is just basic session cookies storing access and refresh tokens for zitadel.
@rohithk64665 ай бұрын
Hi Ben this video was pretty useful, kindly keep coming back with these
@rutvikpatel76405 ай бұрын
You uploaded this video right when I needed it! You answered so many questions of mine in just 15 mins than I found answers online for last 2 days. Thank you so much. And please make a next video on how you setup username and password auth.
@PedroPedruzzi5 ай бұрын
Very nice. I've used this design with two JWT, but never seen it explained anywhere. Cool!
@ygvanz5 ай бұрын
From all of the authentication videos I have seen, you explained everything very well.
@mtnrabi8 күн бұрын
A note regarding your cookie configuration - same-site lax can still lead to csrf attacks… (it allows for cross site requests via links but not via images, and only GET - but still it’s possible) Only same-site strict would totally prevent csrf attacks (setting CORS to the origin site only would also work) Love your content btw and hope you keep creating !
@user-zo2ky4mz7d5 ай бұрын
I was just researching this for a side project. Thanks Ben for reading my mind.
@kevinroleke27695 ай бұрын
You don’t need to buy a service for email. It’s a bit annoying but you can setup postfix on a VPS and point MX, SPF, DMARC records.
@Andres-Estrella5 ай бұрын
Thanks! Auth is one of those things you have to implement 2 or 3 times to fully understand.
@devxsadik4 ай бұрын
i missed this type of content bro pls keep doin it
@bojidaryovchev99953 ай бұрын
that's why we love you Ben, what an amazing video, mad props yo, tight, tight tight tight!
@SeanCassiere5 ай бұрын
A wild Ben has appeared!
@gabrielbiacchi61695 ай бұрын
Hell yeah you're back homie
@Smurfis2 ай бұрын
I absolutely love this, was asking for it and he provided thanks Ben
@KevinNaughtonJr5 ай бұрын
great vid super informative benjamin
@nigelyong90604 ай бұрын
⏱ CHAPTERS ⏱(By TimeSkip AI) 00:00:00 - Introduction to Authentication Setup 00:01:30 - Setting Up Your VPS with Hostinger 00:02:51 - User Account Verification and Security 00:04:30 - Session Storage vs JWTs Explained 00:05:36 - Implementing JWTs for Authentication 00:06:52 - Managing User Sessions and Tokens 00:09:40 - Best Practices for Token Storage 00:11:35 - Front-End User Authentication Checks 00:12:41 - Conclusion and Resources
@maneeshparihar5 ай бұрын
Thanks a ton ... nobody explained it better and all in one video.. I will need to dig a bit more in CSRF and XSS bits.. but still crisp and yet adequately detailed. Kudos
@pt_trainer92444 ай бұрын
Summarized months of learning all of this in a short video, good stuff
@ayushgupta00105 ай бұрын
My go-to method is to use JWT with a refresh token and token version, make the access token short-lived, like 15 min, and store it in the memory on the frontend.
@TechTube-225 ай бұрын
Auth with cookies makes you're API only callable via browser, so if you want to use them in a mobile app, you have to change maaaany things
@regularyt-pz4ki5 ай бұрын
bro just back like he never left
@Sindoku5 ай бұрын
Oooohhh crap, our boy Ben Awad is finally back. Welcome back baby, we missed you.
@V0LAT1LE_5 ай бұрын
The 2 doors in the back are hitting some weird parts in my brain. Its like they are saying red pill or blue pill
@SalimOfShadow5 ай бұрын
I always really really liked how you explained everything!!! Really enjoyed this quick rundown
@toTheMuh4 ай бұрын
5:30 - in a microservice environment you are most likely going to have a token AND a session cache, especially if you are working on a complex business SaaS (software like Salesforce, AWS, SAP, etc.) with RBAC/ACL/etc. The API Gateway will validate the token and then look up the users permissions in the cache. You could store the permissions within the token, yes. BUT that is very complicated. Imagine you have a user and that user has a role with a bunch of permissions. What if the permissions of the role change or the role of the user changes while the user is logged in?
@alessiotucci05 ай бұрын
Great intro to authentication, Thanks a lot Ben
@erickshaffer66155 ай бұрын
PLEASE KEEP THIS GOING, VERY EDUCATIONAL
@gbbelloponce5 ай бұрын
Amazing video man!!! It's literally what I've been looking for lately. I would personally love a video talking about the username/password login approach. Greetings!
@KazSadeghi5 ай бұрын
This is insane, best auth video / resource I've seen
@w.e.b_b5 ай бұрын
I am stoked for this. You’re such an incredible engineer and I owe much of my success as a programmer to your teachings! Thank you my friend
@monsieurLDN4 ай бұрын
What did you learn from him? I see mostly reaction videos
@w.e.b_b4 ай бұрын
@@monsieurLDN you’ll have to go back to his content from 2018-2019ish when he was making more long form content
@Yaxqb5 ай бұрын
here I have walked literal years wondering why we have refresh tokens. Your explanation is so clear
@theo_ludwig2 ай бұрын
Well explained, straight to the point with pros and cons of each method. Thank you!
@krishnabirla165 ай бұрын
Best web-dev video I saw this week.
@pingxtratech3 ай бұрын
This is so good. Nice one. With regards to Cookies vs LocalStorage, I always have my reservations and would usually choose LocalStorage as it'll only keep the user logged in on the Frontend. If it is tempered with, the user is kicked of out the system. I realized one thing that even with cookies, when I copied the cookies with their values on a certain browser and put it on a different browser, all I had to do was reload the page and I was logged in. Great insight though.
@amagicpotato55115 ай бұрын
Had to figure all this out myself a year ago. This video will serve well for anyone else that finds themselves in the same position. Thanks Benji!
@CardinalHijack5 ай бұрын
step by step tutorial on doing this, like the old style videos this channel did, would be super cool
@yasharma23015 ай бұрын
One benefit of cookie I think is SSR? JWTs stored in local storage cant be read on SSR since you won't be able to send it in the first document call, while if you use cookies you can fetch user data on the frontend server. Correct me if I am wrong
@_solstice5 ай бұрын
very good video, everything was super clear, maybe this is a bit niche or too specific to be useful but a video about how you'd go about rolling your own oauth provider would be very interesting imo
@i-am-artur5 ай бұрын
Thanks for the video a lot! I am currently working on a project with JWT, and was about to read on xss
@AlexCrocker4 ай бұрын
Thanks! 🐊🐊🐊
@Alphfirm5 ай бұрын
Sweet, thanks! For my situation, a tutorial on expo react native app with using secure storage as you mentioned and session storage would be great!
@jonacempelule98764 ай бұрын
For the logic to invalidate the JWTs for ‘Signing out all devices’ why not have a Redis Cache/DB to keep track of blacklisted tokens, and set the expiration of that cached token to 15mins(or however your access token take long to expire). Now in your middleware, to validate the JWT you first check if the access token is blacklisted. Now when a user signs out of all devices, just have the other tokens in the blacklist cache. Your thought?
@prabaleshp13593 ай бұрын
You can use it but in the end it'll become the same as sessions
@eedoan5 ай бұрын
The true token is the friends we made along the way
@Kayzewolf16 күн бұрын
It’s appealing and tempting to do the JWT flow but just feels like a session lookup is the best match since you probably want data that you wouldnt want to expose in a JWT payload, or perhaps would want to revoke faster. Say, if you ban a user, they still got access for as long as the JWT is valid. Even with a small expiration via refresh token flow, it’s still a window of opportunity you gotta then trade off to where you’ll probably start refreshing every other request anyways. I mainly use JWT for expiring temp tokens like email verification or even password resets (hash value to check db, inside an expiring token). If I’m doing a microservices approach, JWT benefits where you have the auth service do the lookup and then send a potentially sensitive JWT via internal network to that microservice, decoupling auth from services. JWTs are fine for auth but I just prefer more control and safety of sessions (via redis) for access changes (banning, access permissions, etc).
@Kayzewolf16 күн бұрын
For a point in JWT auth’s favor, I suppose checking permissions via query might reduce these concerns, though the potential performance/coding complexity might still be a reason not to? I dunno
@danielsharp24024 ай бұрын
For me refresh token is usually not a JWT since accessing the database is happening there anyway. And that gives you the best of both worlds with revoking as well. Usually stored in redis with EX. Also for early MVP services I like to do a Frankenstein approach of letting an access token close to expiry refresh itself (works quite well, but obviously isn't as good as refresh tokens).
@dumbfailurekms5 ай бұрын
Is lucia analogous to passport.js or is it a higher level of abstraction
@marcgentner13225 ай бұрын
Love it. Practical and simple. I have build the db setup in php but I like your methods on the jwt way
@eleah26655 ай бұрын
He back! But the room, mic and cuts make it look like he's been kidnapped.
@lynxcat4life5 ай бұрын
the ThioJoe effect has hit Ben
@antivist51834 ай бұрын
Yo how do you set up your oauth? what packages/libraries do you use/recommend? i try to avoid using as many packages as possible cause im stubborn so im curious what the pros/cons are or if they're literally needed.
@DanTheMan-rr3yg5 ай бұрын
great video, you should do a video on the username + password, but do the whole shebang too! Reset password, forgot username, two factor authentication, magic link too, etc.
@comproprasad64385 ай бұрын
you can sign the session token as well and store in a cookie
@TestFirstTestLast-m7u3 ай бұрын
You can literally send the tokens through server cookies and if they sign out just remove the cookies and token itself from the db
@amzabdrahim33505 ай бұрын
amazing video, please do more. this popped on my suggestions, clicked on it immediately. had to do jwt for a client, i didn't know how to set up the refresh token.
@alexjmohr5 ай бұрын
Personally I still don't buy into using JWTs for auth in the front-end. I think they're more applicable to server to server contexts. The argument that you don't have to make a database call to validate the user's session isn't that strong, since in most requests you're going to hit the database anyway in order to do anything useful. The extra database call isn't that big of a deal. Refresh tokens add unneeded complexity for most projects. It's a LOT simpler to just store a cryptographically unique session ID (like a UUIDv4) in a cookie and use that to look up the session in the DB/Redis. Not hating on the video, I just think people jump to JWTs, refresh tokens, etc because they're fancy and trendy, but they're often misused.
@0xA5 ай бұрын
You are absolutely correct. JWTs irrevocability make them a great target in security assessments. If there is restricted data being hosted by the application (PII), I would never allow JWTs to be used for authentication from a security architecture perspective. Learn it, use it on non-sensitive apps, but don't rely on them to be a truly secure means of authentication. Not to mention the common misconfigurations that often allow them to be altered or bypassed altogether.
@adithyagowda46425 ай бұрын
It would be easier to use sessions to authorize a user if you already use sessions for other things, like tracking user behaviour, storing useful information like user's wishlist (in e-commerce websites) etc.,. You just need to add one more parameter of userId in the database and you have a working authorization mechanism. But creating a whole new database server (assuming sessions are mostly stored in a separate Redis DB), just for authorizing would seem to be a overkill as compared to using something like JWTs which are much easire to integrate with no added work of managing another database. But again, it largely depends on the use-case of your application.
@adamfarmer76654 ай бұрын
If you are not using jwts on high concurrent users you are going to get pegged by lots of db requests on each request because you needed database for validation, and your application will suck. Of course If you are developing an in-house app that will be used by less than 10000 users, you can get by using beefier servers, since you are not paying for the servers anyways.
@wchorski4 ай бұрын
I see the benefit and control of rolling your own auth, but the convince of Next-Auth / Auth.js has kept me hooked with being able to do both email/password and OAuth options together. wondering if you have any advice on a hybrid method?
@SoreBrain5 ай бұрын
I would have paid for this video more than I paid my auth provider 3 years ago.
@akashdeb98235 ай бұрын
babe wake up ben's new video just dropped
@knwanze5 ай бұрын
Good stuff Ben. Looking at your database queries in your screenshots, is that some ORM you're using or your own custom functions wrapped around SQL queries?
@trimpta4 ай бұрын
Where was this video when i had to go and do all this research myself
@ryank97195 ай бұрын
A simpler way to invalidate tokens would be to create a table/collection for all your tokens. Then, when a user logouts, you search the table/collection for all tokens associated with that user and delete them.
@Sylvoo014 ай бұрын
Congrats you have just reinvented regular sessions
@WillDelish5 ай бұрын
Yep, oath + jwt + cookies be my fav flow right now. I have to use this at work.
@petaflop36065 ай бұрын
the first auth I self-rolled was an OIDC IdP server to connect a third party to our existing session-based auth (not SaaS it was just for one particular partner). It was fiddly at first but once you get it, like most things, it doesn't feel so bad and I'd be much more confident doing it again if I had to
@gavilansalcedo24225 ай бұрын
THE KING IS BACK
@ashrafuzzamankhalid34655 ай бұрын
Hey Ben, will you please make a video about career choices and their difficulties and how to make sure to learn it...
@timkunze6035 ай бұрын
Fun fact: saying "JWT" takes longer than just saying "JSON Web Token"
@SimonPaul-u7x4 ай бұрын
Fun Fact: everyone pronounced these two words now
@houssemchr15394 ай бұрын
Thank you for explication Ben, but how about using OAuth 2.0 ? I think it's the most secure one
@JOJO_THE_PROGRAMMER5 ай бұрын
he is back with tutorials!!!
@PyraptorАй бұрын
You didn’t explain clearly that you only send the access token for api calls, only when that returns a “valid but expired” error (or before its gonna expire to prevent this error) you use the refresh token, and you use it on a “special” endpoint to get a new access token, and if it’s a cookie it must be configured to only be sent to that endpoint
@tanglesites5 ай бұрын
Ben where you been? Good to see you back.
@jakeave5 ай бұрын
Good job! I like the explanation of the log out of all devices. Next let's do authorization 😂
@alimahdi10125 ай бұрын
Throwback to a very similar video you made 4 years ago.
@SogMosee15 күн бұрын
Do you think the react compiler in react 19 will help with performance automatically going forward?
@RyanLynch14 ай бұрын
welcome back king
@h45e32u4f5 ай бұрын
This section looks great. And going deep into passwords, how to get credentials, why is not ok to send the token in cookies and get it in headers... Can be good. And in the future, I see you doing a video like this but " Exploring Coolify", host your own "vercel". It would be awesome to see that. Thank you for the information!
@richayy5 ай бұрын
Hey Ben this was super helpful! I was wondering what's your strategy for refreshing tokens? Do you have a /refresh endpoint to handle this? But then how do you know when to call it? For example, say the expiry on your access token was 15 minutes. How does the client know "oh my 15 minutes is up, better go call the /refresh endpoint"? Do you use a timeout or do you poll in the background?
@armaan-ci3nv4 ай бұрын
can you make a more in depth version really focusing on best security practices that owasp has laid out?
@joshuasingh8545 ай бұрын
Bro thanks so much for this!! This was very useful and cleared a bunch of stuff for me!! Yes please do the next video if how you set up username/email and password
@blancartembl5 ай бұрын
One way to do it without relying on a sass product its to use Lucia Auth... full fine grained control of the flow without magic like others
@Zayetzo4 ай бұрын
This was a very good explanation thank you!
@MedKani5 ай бұрын
Welcome back I guess, thanks for the video
@gj9ekdjekray2 күн бұрын
I don't understand the following 1. We opt to choose JWT over session because session would require checking who the user is from DB for every request 2. To prevent CRSF from attacking for JWT while we still want to know the user's identity, we check who the user is from DB for every request Isn't this contradictory? Can someone explain please
@schoolofbillt26565 ай бұрын
This is so helpful. Thank you for this video!
@MrMudbill5 ай бұрын
I really want to use secure cookies more, but it's next to impossible when you deal with an SPA that is hosted on a different domain as the API (for example using an "app" and "api" subdomain on the same primary domain). Cookies are extremely picky (hence their security), so getting cross-site cookies is a massive pain. Cookies are trivial in stuff like NextJS because you have the API on the same domain.
@0xA5 ай бұрын
Should just have to set the domain attribute in the cookie no? Unless you're trying to access it with JS..
@Niksorus5 ай бұрын
Fantastic, I'm down for a longer video 😄
@vrinfotechies5 ай бұрын
Yoo thanks for the explanation of creating a fully working auth model for my website thanks
@galaxygur3 ай бұрын
So you say, its just for the purpose of optimization, to avoid calling database to check user token on each request, instead backend can verify it cryptographically; is it really worth it though, are there any benchmarks?
@dimitriborgers98005 ай бұрын
Apart from the sign out of all devices advantage, adding a refresh token doesn't improve security, right? Someone who steals your long term access token is the same as stealing your long term refresh token?
@danhorus5 ай бұрын
3:33 I would prefer to send them a one-time password instead. Email headers such as the sender's address could be spoofed, so you need to be wary of social engineering