I love the positivity with which you explain these concepts! The love you clearly have for dev and coding makes the topics a lot easier to follow and makes your videos a joy to watch.
today in the interview a question was asked about implementing auth in the app, and I mumble hard. I open youtube and my man kyle upload this, thanks bro you are god send
You can always make complex things so clear!Can you also make a video about all the tabs in the inspector? I'm always confused.. ex. performance, memory, security, etc
you should mention it is a stateful authentication and authorization. using UUID is weak because of collisions and you also have to maintain memory storage for it, but with JWT you it is stateless. both have pros and cons
Fore sure but JWT is not good for systems that demand any serious authorization demand, because you can't invalidate someone's auth at will and any authorization you store as payload in the JWT will always be detached from their real time authorization, ie: an admin, user B, changes roles from a normal user, user A, that user A will have old authorization role until his JWT payload expires or until he logins again.
9:20 - You just copied and pasted a cookie and it worked, what if a hacker did the same, copied your cookie and pasted on their browser? Would it not also work for them on their browser while at a different location?
Note: Oversimplifying auth greatly increases the risk of not doing it properly. Do not try implementing an auth solution yourself (handling identities or token brokerage) unless you are prepared to have the data breached for the project at hand, or are ready to shell out some cash to some pen testers to ensure you did it right. All that being said: use popular auth libraries and brokers (federated identities, Auth0, cognito, etc).
Through webhooks. You let the Payment gateway charge your customers and then it will trigger the webhook you provided it so that it can "push" that data to your backend
How does this work then for Baas such as Supabase? In their Nuxt examples they have "useSupabaseClient" which is ran on the front end. Is this still safe? Or am I mixing things up. It seems a lot of examples in a Vue/Nuxt application are performing the checks if the user is signed in on the front end. I know its a little specific to Nuxt but im sure the principle is the same for vanilla JS using Supabase
Hi, good videos, is it possible you to make a very easy example how to use Authjs v5 that is out? you may use crediential and mongodb local database. if you have time for this. would be very usefulle because the doc on authjs v5 is so week.
Absolutely important video. Explains persistent login state too. Thanks for this. Note: using session-ids or auth tokens doesn't change this flow, do don't worry if you don't know about one. Chill
I will except for the fact that it actually affects every single process of the flow. Choosing between the two in a correct way for your specific projects use case is detrimental to its performance. If you are using session ids and have enough users actively using the site you could have upwards of hundreds of gigabytes of data being stored in memory just for session state information. However if you go the token route you need to realize even tho your saving on ram now for every request even one’s not requiring state information will be sent with all the session state data Unless you go for a naïve approach where you store the token in local storage which will allow for bad actors to exploit your users a lot easier
I loved ! it was very clear! but I have a question, what happens if our client and backend are from different domain? I understand that httponly cookies would no longer work, right? If that is so, how else could we store the sid? Thank you!
What's your opinion on storing the user in a jwt in a cookie? That way isn't necessary a session in a database, but your jwt can be verified as valid in your server
In my opinion, JWT is great for authentication, but not so much for authorization. Sure, you can include the rules as part of the JWT payload, but the more fine-grained your rules are, the more the size of the JWT payload grows, which in turn means slower requests due to the bigger upload required. And if you are only going to use JWT for authentication, the benefit of not needing a database request for the session is lost... i.e. if you are going to consult the DB for authorization, you might as well be better off maintaining a session ID in a key/value store, where the value is a cache for permissions that have been evaluated already, and are thus quick to check. If your requirements are as simple as "admin", "moderator", "regular", JWT is probably good enough, but beyond that, probably no.
In my opinion, that's fine, as long as you check the JWT signature properly, and you're OK with users being able to read the data in the JWT (if you don't encrypt it). There is one difference though: you can't invalidate the session to log someone out. You will still have to store a session ID on the server for anything invalidated and not yet expired.
@@uplink-on-yt you're right, didn't remembered the option to invalidate the session. Also, storing the refresh token in another cookie is a bad idea right? If using refresh tokens, I can invalidate the refresh token, assuming a jwt validity of like a few hours
@@uplink-on-yt you can always create a black list on the server or allow tokens for a small amount of time like an hour, JWT is much stronger security given that uuid might have collisions
Thanks for the video, great stuff as always. Quick question, doesn't it increases the chances of a CSRF attack if we store the session token in cookies? How do you deal with that stuff?
I didn’t watch video but Basically if you use the cookie approach a CSRF token can help reduce attacks using either Synchronizer or Double Submit pattern. Also make sure your auth cookies use httpOnly with SameSite set to Lax or Strict with cors restricted to specific domain and allow credentials set to true and secure attribute on production, newer browsers and TLS versions will prevent third parties from doing malicious post requests with those cookie and cors settings. Also some things that could provide extra security is restrict your server to only allow Content-Type application/json to enable preflight checks for request. This is just the cookie approach, securing a client JWT is also a pain if you want persistence; auth is not easy if you wanna do it right lol. I’ve gone down the auth rabbit hole so many times, I wish Auth0 custom domains were free 😢
Well I got Questions, you are using a Map for the sesssions, so imagine if I log in a browser, I create a session, and then in another browser I log in too? do I create another session? would that invalidate my session in the other browser? do my other session gets updated with the new sessionId? or do I get the same sessionId as response? so, basically do I create another sessionId (would have 2 now)? do I replace the current sessionId? or do I keep using the same sessionId?.
How does the secure option in setting up the cookie works? It is supposed to accept cookies sent by https only, but as we can see your example is working fine even if you are using http only.
I've spent a few hours trying to get this to work. I click the buttons and absolutely nothing happens. I have the extensions cookies.js, cors, express, and live server. My code is 1:1 at this point and I do not understand why nothing is happening. If anyone can help it'd be greatly appreciated, thank you. EDIT: I hit f12 and found that it was refusing to connect to the port at 3000, I changed all the ports to 5500 and it stil refused to connect. still at a loss here
Like others have mentioned, this is definitely a simplified pass at authorization - much like a hello world example. Though well explained and a great starting point. I suggest looking into Zanzibar-like auth models to go deeper into the topic. I quite like Oso's tool for this - they also have great educational blog posts on authZ.
A teacher's access to their classroom's students was mentioned in the video. This is actually an interesting start to a more complex authorization system - classrooms, schools, school districts, etc. (Particularly the users with access to these various levels).
Authentication is strongly related to HTTP errors. The "delete my CZcams channel" example is wrong because the client doesn't ask for the right to do something, (can I delete my CZcams account?), it just try to do the action DELETE on the resource from my.youtube server (HTTP DELETE my.youtube/). The server then check authentication (by validating a token, not a UUID), and authorization (by checking if the user is authorized to POST,PUT, UPDATE or DELETE the target resource according to the HTTP request action code, and do the action if those two checks succeeded. And if any check or the action fails, then the server must reply with the appropriate HTTP error code (500 - unauthorized, 403 - forbidden, 404 - not found, already deleted ?). Session ID on the server is a mess to manage, that's why you should: 1. always keep user related data in some shared cache or database and authenticate the user token for each and every request. 2. ensure that no action depends on a previous transient state, in order to keep "data integrity", aka "does this request fail if it is not received by the server which hold this transient state in session?".
Right now im stuck on auth flow. I have create nextjs with flow like this. Pls comment if my flow are wrong, and any article's or videos is very helpful 1. Hit the external api auth 2. If error trhow error 3. If success save token in cookie, http only 4. If the token expired i use axios interceptor to get new token and resend form submit It is right? Im so confused about the authenticate and authorization. Thanks 🙏
I'm working on PHP web site with login page and I use PHP session stored in Cookie and I din't put any instruction or timer in my code to delete session after some time but after some time user is automatically logged out and I don't know why. I Googled this problem but didn't find any good answer so I hope somebody here can help me.
@@StamyIIReturn I don't use any library for this, just vanila PHP. It is a bit older PHP but I must use it becouse of other things (connecting to the old Informix DB)
Really oversimplify the whole concept of auth here, it is fine for a beginner friendly concept video but telling people that auth is not hard is kinda misleading, It is okay to do simple authentication in a small website but it won't be really secure for a big one. This is why companies provided auth services because they are more professional than us, we don't really need to be expert at every aspect in CS but we really shouldn't just say one part is "easy" just because we can do a easy version of it
I don't think he's implying that implementing auth is easy but rather auth is "simple" to understand, because I can attest to the fact that it's very daunting as one is starting out. He's telling those who may be less familiar with the concept of auth as a whole, or maybe those who are avoiding it because it's a "scary" topic, not to be afraid, the concept is much simpler that you might expect. After all, this is web dev "simplified" not web dev "exhaustive".
Hi kyle i am currently learning backend but there's one question I am stuck at how do we send files especially larger one from front end to backend like in any chat application
super easy right. Thats propably exacly the way x, meta or google handle their security. No OpenId Connect, no passkeys, no two-factor auth. Just plain simple bs. Thanks for wasting my time
I love the positivity with which you explain these concepts! The love you clearly have for dev and coding makes the topics a lot easier to follow and makes your videos a joy to watch.
Best teacher on the web. Great choice and variety of topics. Thanks!
today in the interview a question was asked about implementing auth in the app, and I mumble hard.
I open youtube and my man kyle upload this, thanks bro you are god send
One, among many, incredibly useful video.
Do not delete wds, please) too much useful and up to date info, here. Thank you)
Auth gets even simpler if you don't tie it to subjects (that is, users). C.f. Webkeys for an example of doing capabilities over the web.
You can always make complex things so clear!Can you also make a video about all the tabs in the inspector? I'm always confused.. ex. performance, memory, security, etc
Perfect! I'm currently working on auth for my web app
I want to thank, you, Kevin Powell, Ania Kubow and Patrick God for the insane influence in my career you guys have.
What a crazy coincidence, yesterday I was looking for a video about an authentication tutorial
If you're as good in playing guitar as you are in Nodejs u got skills... Play one minute in every video
you should mention it is a stateful authentication and authorization.
using UUID is weak because of collisions and you also have to maintain memory storage for it, but with JWT you it is stateless.
both have pros and cons
Fore sure but JWT is not good for systems that demand any serious authorization demand, because you can't invalidate someone's auth at will and any authorization you store as payload in the JWT will always be detached from their real time authorization, ie: an admin, user B, changes roles from a normal user, user A, that user A will have old authorization role until his JWT payload expires or until he logins again.
@@minimovzEt right, but you can create some sort of black list
9:20 - You just copied and pasted a cookie and it worked, what if a hacker did the same, copied your cookie and pasted on their browser? Would it not also work for them on their browser while at a different location?
This video is SO helpful. Thank you for showing the examples!
Authorized implies you are authenticated, but the opposite is not always true.
Nice Video Sir!
I found your top-secret easter egg 😀
Thank you, Kyle.
Hey please make a video for error handling on frontside and back-end
Thanks
Hello thank you for this tutorial! I suggest setting Cookie sameSite to lax which is the default one and better for security
pls dont ever delete your videos
Note: Oversimplifying auth greatly increases the risk of not doing it properly. Do not try implementing an auth solution yourself (handling identities or token brokerage) unless you are prepared to have the data breached for the project at hand, or are ready to shell out some cash to some pen testers to ensure you did it right.
All that being said: use popular auth libraries and brokers (federated identities, Auth0, cognito, etc).
Can you breakdown how payment integration work in application or as general ?
stripe
Through webhooks. You let the Payment gateway charge your customers and then it will trigger the webhook you provided it so that it can "push" that data to your backend
How does this work then for Baas such as Supabase? In their Nuxt examples they have "useSupabaseClient" which is ran on the front end. Is this still safe? Or am I mixing things up. It seems a lot of examples in a Vue/Nuxt application are performing the checks if the user is signed in on the front end. I know its a little specific to Nuxt but im sure the principle is the same for vanilla JS using Supabase
Gawd I love you Kyle. You are hands down my favorite coding content creator.
Hi, good videos, is it possible you to make a very easy example how to use Authjs v5 that is out?
you may use crediential and mongodb local database.
if you have time for this. would be very usefulle because the doc on authjs v5 is so week.
Absolutely important video. Explains persistent login state too. Thanks for this. Note: using session-ids or auth tokens doesn't change this flow, do don't worry if you don't know about one. Chill
I will except for the fact that it actually affects every single process of the flow. Choosing between the two in a correct way for your specific projects use case is detrimental to its performance. If you are using session ids and have enough users actively using the site you could have upwards of hundreds of gigabytes of data being stored in memory just for session state information. However if you go the token route you need to realize even tho your saving on ram now for every request even one’s not requiring state information will be sent with all the session state data Unless you go for a naïve approach where you store the token in local storage which will allow for bad actors to exploit your users a lot easier
Would you ever show a Auth0 server and HTML and css tutorial? Or even go further into this as a course? I’m interested
Kyle Cookespeare in rescue again!
I loved ! it was very clear!
but I have a question, what happens if our client and backend are from different domain?
I understand that httponly cookies would no longer work, right?
If that is so, how else could we store the sid?
Thank you!
What's your opinion on storing the user in a jwt in a cookie? That way isn't necessary a session in a database, but your jwt can be verified as valid in your server
In my opinion, JWT is great for authentication, but not so much for authorization. Sure, you can include the rules as part of the JWT payload, but the more fine-grained your rules are, the more the size of the JWT payload grows, which in turn means slower requests due to the bigger upload required.
And if you are only going to use JWT for authentication, the benefit of not needing a database request for the session is lost... i.e. if you are going to consult the DB for authorization, you might as well be better off maintaining a session ID in a key/value store, where the value is a cache for permissions that have been evaluated already, and are thus quick to check.
If your requirements are as simple as "admin", "moderator", "regular", JWT is probably good enough, but beyond that, probably no.
In my opinion, that's fine, as long as you check the JWT signature properly, and you're OK with users being able to read the data in the JWT (if you don't encrypt it). There is one difference though: you can't invalidate the session to log someone out. You will still have to store a session ID on the server for anything invalidated and not yet expired.
@@uplink-on-yt you're right, didn't remembered the option to invalidate the session. Also, storing the refresh token in another cookie is a bad idea right?
If using refresh tokens, I can invalidate the refresh token, assuming a jwt validity of like a few hours
@@uplink-on-yt you can always create a black list on the server or allow tokens for a small amount of time like an hour, JWT is much stronger security given that uuid might have collisions
@@boenrobot and social auth? (oauth2)
is this how you would protect routes in an app also (by sending request to server first)?
thank kyle, very clear auth, request react router 6 with private route for manage authorization area of many form
Thanks for the video, great stuff as always. Quick question, doesn't it increases the chances of a CSRF attack if we store the session token in cookies? How do you deal with that stuff?
I didn’t watch video but Basically if you use the cookie approach a CSRF token can help reduce attacks using either Synchronizer or Double Submit pattern. Also make sure your auth cookies use httpOnly with SameSite set to Lax or Strict with cors restricted to specific domain and allow credentials set to true and secure attribute on production, newer browsers and TLS versions will prevent third parties from doing malicious post requests with those cookie and cors settings. Also some things that could provide extra security is restrict your server to only allow Content-Type application/json to enable preflight checks for request. This is just the cookie approach, securing a client JWT is also a pain if you want persistence; auth is not easy if you wanna do it right lol. I’ve gone down the auth rabbit hole so many times, I wish Auth0 custom domains were free 😢
@@NickHamilton88 Thanks a lot for sharing that.
Bro, this really opened my eyes. Thanks for a video we all need, but didn't realize
Well I got Questions, you are using a Map for the sesssions, so imagine if I log in a browser, I create a session, and then in another browser I log in too? do I create another session? would that invalidate my session in the other browser? do my other session gets updated with the new sessionId? or do I get the same sessionId as response? so, basically do I create another sessionId (would have 2 now)? do I replace the current sessionId? or do I keep using the same sessionId?.
Yay! I'm glad you're well again.
Very nice, hey will you pls make video on how to implement RBAC and how should differentiate admin rest api and frontstore rest apis
Very Good Information Dude. I love This
I am curios if you plan also to do more tutorials for Deno/Fresh?
With JWT authorization, SESSION IDs are not needed, right?
what password manager is this? Looks great!
thanks😄😁🌟🌟
the best/simples video on the platform
finally I get rid of other big nightmare
Thank you for all your help Mr Vanilla Ice
How does the secure option in setting up the cookie works? It is supposed to accept cookies sent by https only, but as we can see your example is working fine even if you are using http only.
This is sooo good! Thank you so much!
could you do a video on http requests? like from the perspective of a javascript sort, but not caching the stash on the server api
I've spent a few hours trying to get this to work. I click the buttons and absolutely nothing happens.
I have the extensions cookies.js, cors, express, and live server.
My code is 1:1 at this point and I do not understand why nothing is happening. If anyone can help it'd be greatly appreciated, thank you.
EDIT: I hit f12 and found that it was refusing to connect to the port at 3000, I changed all the ports to 5500 and it stil refused to connect. still at a loss here
Like others have mentioned, this is definitely a simplified pass at authorization - much like a hello world example. Though well explained and a great starting point.
I suggest looking into Zanzibar-like auth models to go deeper into the topic. I quite like Oso's tool for this - they also have great educational blog posts on authZ.
A teacher's access to their classroom's students was mentioned in the video. This is actually an interesting start to a more complex authorization system - classrooms, schools, school districts, etc. (Particularly the users with access to these various levels).
perfect explanation as always, keep it up
Does that mean that If I know your uuid I can log in as you? there are no more steps of verification?
Authentication is strongly related to HTTP errors.
The "delete my CZcams channel" example is wrong because the client doesn't ask for the right to do something, (can I delete my CZcams account?), it just try to do the action DELETE on the resource from my.youtube server (HTTP DELETE my.youtube/).
The server then check authentication (by validating a token, not a UUID), and authorization (by checking if the user is authorized to POST,PUT, UPDATE or DELETE the target resource according to the HTTP request action code, and do the action if those two checks succeeded.
And if any check or the action fails, then the server must reply with the appropriate HTTP error code (500 - unauthorized, 403 - forbidden, 404 - not found, already deleted ?).
Session ID on the server is a mess to manage, that's why you should: 1. always keep user related data in some shared cache or database and authenticate the user token for each and every request. 2. ensure that no action depends on a previous transient state, in order to keep "data integrity", aka "does this request fail if it is not received by the server which hold this transient state in session?".
Can you make a video about typescript decorator?
Now in post request cannot saved nor get
5:40 Found the easter egg; I had to take a look lol
How do you store in local storage or cookies securely on client side? Can anyone hack your local storage and get the session info?
Can you share the github repo please ? I wanted to read it because It's easier to understand
You're amazing man !
Excellent! Now please summarize CSRF tokens.
No Kyle!!! You have a good day!!!!!!
Very useful tutorial thank you
Right now im stuck on auth flow.
I have create nextjs with flow like this. Pls comment if my flow are wrong, and any article's or videos is very helpful
1. Hit the external api auth
2. If error trhow error
3. If success save token in cookie, http only
4. If the token expired i use axios interceptor to get new token and resend form submit
It is right?
Im so confused about the authenticate and authorization. Thanks 🙏
Authenticate = Login. Authorize = Permission.
4:13 obviously or at least hopefully😂😂😂😂
I'm working on PHP web site with login page and I use PHP session stored in Cookie and I din't put any instruction or timer in my code to delete session after some time but after some time user is automatically logged out and I don't know why.
I Googled this problem but didn't find any good answer so I hope somebody here can help me.
Are you using a library for the session? Check if sessions default timeout is x minutes.
@@StamyIIReturn I don't use any library for this, just vanila PHP. It is a bit older PHP but I must use it becouse of other things (connecting to the old Informix DB)
How to safeguard session cookie in order to save it from hackers ?
Can you do this with plain Vanilla Javascript
5:35 yeah i found your ester-egg 😍😍
Really oversimplify the whole concept of auth here, it is fine for a beginner friendly concept video but telling people that auth is not hard is kinda misleading, It is okay to do simple authentication in a small website but it won't be really secure for a big one. This is why companies provided auth services because they are more professional than us, we don't really need to be expert at every aspect in CS but we really shouldn't just say one part is "easy" just because we can do a easy version of it
I don't think he's implying that implementing auth is easy but rather auth is "simple" to understand, because I can attest to the fact that it's very daunting as one is starting out. He's telling those who may be less familiar with the concept of auth as a whole, or maybe those who are avoiding it because it's a "scary" topic, not to be afraid, the concept is much simpler that you might expect. After all, this is web dev "simplified" not web dev "exhaustive".
Exactly what I was thinking
He said it's complex in the very first sentence of the video lmao.
@@maziasty true
Understand easy but implement with senior principal engineer for more security. Collaborate.
What do you think of trpc
found the easter egg!
Hi kyle i am currently learning backend but there's one question I am stuck at how do we send files especially larger one from front end to backend like in any chat application
Forms requests can deal with that. They send binary data and it can be streamed.
formData should be able to handle this.
Thanks
Hye Kyle, I have been wanting to build a react front end and express js backend, please any tutorial on that??
Also crud with react and express
Please don't spread these kind of videos. It's going to make new developers think this is a safe way for authentication. It is way oversimplified
how should a new dev implement auth?
Just here to say I found your top secret easter egg
its hard in nextjs to make na auth guard :/
Your the man
AMAZING
very.nice
Liked it!
good stuff
You are the budget Theo!
Theo is the budget Kyle.
nice video
super easy right. Thats propably exacly the way x, meta or google handle their security. No OpenId Connect, no passkeys, no two-factor auth. Just plain simple bs. Thanks for wasting my time
Found it! 🥚
Simply its out-class
I thought the easter egg is the number of likes and views is real-time, turns out I watched the video at 2.3k likes and 47k views 🤣
👍
First, yeey!
5st!
You mean 5th
@@321sas 5th! I had no time for typing lol
Just 10 seconds ago )
Google can delete your channel too :) lol [I know, just joking around]
This guy deleted my comments
You should give us authorization to delete your videos.
thanks😄😁🌟🌟
the best/simples video on the platform