Authentication: It’s Easier Than You Think
Вставка
- Опубліковано 23 лип 2024
- I get a LOT of questions about auth so I figured it was time for a video! We talk all about authentication and authorization. Watch rants like this live on / theo
LIVE EVERY WEDNESDAY AT ROUGHLY 1PM PT
Twitch: / theo
Twitter: / t3dotgg
Instagram: / fakiebigfoot
Everywhere else: t3.gg/links
And obv shoutout Idez as always 🙏
Keyword dump: REACT REACT NEXT JS NEXTJS NEXT-AUTH NEXTAUTHJS NEXTAUTH AUTHORIZING WEB APPS OAUTH JWT JAVASCRIPT TYPESCRIPT
Timestamps
00:00 what is “auth”?
01:05 where does “auth” happen?
02:52 but what about the client?
03:37 how does react know?
05:25 auth flows
10:18 auth example
15:29 rbac example
20:26 outro - Наука та технологія
I love this style of notepad-teaching, it's a lot less sterile and boring than most videos on these topics. Hoping for a lot more videos like this!
This is gold. I learned authorization with JWT a week ago and I've been stuck fot two days trying to implement it well, been searching a lot of tutorials and steps when actually I needed a general explanation of the authorization concept (I was getting confused with localStorage because I thought it was a bit insecure, which I learned to be true in this video lol). Maybe JWT wasn't the best place to start. Really helpful vid
thank you for this video!!! clears out a lot of things in my head 🚀
These are my favorite types of videos that you make. You are by far the easiest and most concise teacher I have found on UA-cam for beginners
Fun fact, chrome extensions CAN access secure, httpOnly, SameSite cookies.
Food for thought.
This scares me
wtf, why would they do that. Must be one of the permissions that it asks for that I never look at.
there are counter measures for this though, stuff like JWE instead of regular JWS tokens. Paired with a double submit cookie pattern to prevent CRSF.
Awesome video, thanks Theo! ♥
love your channel man
even at 1mill still will be underrated
Ur are awesome installing Twitch just for u man so i can watch this live❤️
This is a good overview, but I do feel like the community could smooth out some of the setup for an OAuth 2.1 setup with a code flow that uses PKCE
This is great! I'm using the template that you created n my personal project and auth has never been easier. Thanks!
I didn’t build it!!! All the T3-OSS team
@@t3dotgg ahhh I might misunderstood it then, thanks for clarifying. Although I wouldn't have known it without you so cheers for you and the whole T3-OSS Team 😄
could you link the repo pls
I've watched this video before and didn't understand shit, now I'm building a app using T3 stack and this made so much sense, and helped me a lot. Thanks Theo, keep up the great work, you are inspiring
Same, man.
Theo: let's pretend JWT doesn't exist
Me looking at road map @ work, sees more changes to our IAMv2 implementation: hmm yes let's
Thanks for sharing such valuable information. This walkthrough helped me a lot to understand better some things I couldn't grasp that well by myself.
Thank you. You are increadible on explaining a concept. clear and on point
Doesn't getServerSIdeprops force our entire page to be server-rendered? How can we avoid this? I'm trying to experiment with next.js middleware to try to solve this, so we don't lose static optimization.
legit i only watch you because I love your hair haha good stuff man thanks
Really helpful video Theo!
Standalone API flow:
Client: /login { credentials: ... }
Server: user found? -> store user data on server session + token that will expire after some time if isn't refreshed on next API calls -> set httponly cookie (secure? use SSL) -> set include credentials for requests
Client: /other_request (automatically send httponly cookie to server)
Server: check if httponly cookie is authorized user -> refresh token -> return data
Client: use data OR if server returns non authorized/session expired http code -> redirect to login page
---
Something like that...
This way you don't store anything on clientside in localstorage / unsecure cookies.
Also, you can write a simple middleware on serverside which does all the job on each request.
Please make a detailed video on different authentication patterns.
Great content bro,
btw what is T3?
Crystal clear explanation. Thanks a lot :-)
Anyway you can show how you’d deploy an app built with NextJS, Prisma, Trpc? For example if I’m using Azure Devops to deploy my react apps how would I deploy something that also has a backend? Probably a dumb question but it’s a bit confusing.
If I have a node backend, I would normally just build it locally, move it to a server on Azure and run the script to listen into api requests. The front end would be deployed through Azure devops pipelines.
Look into containers and kubernetes
going kubernetes is too much@@ManoToor
I am so glad I saw this video. Thanks ! Also, imo I like shorter videos like these.
Hey thank you for the video! What’s your view on the best approach to refreshing an auth token? I see all sorts of strategies out there lol
My issue is that filtering which parts of the frontend are shown on the server isn't as doable on a SPA + other-language-backend setup
A self learned dev like me who will be working as a freelancer in a few months badly needs this
I can't set cookie with tRPC. Anyone has an idea ?
I have a tRPC express backend and a nextjs frontend. I sent the jwt in an http-only cookie. But when I send requests to the server, the cookie is not sent along the request, and since it's http-only, I can't verify if the cookie was correctly set.
What about if I need to share this users list across multiple projects ( auth microservice I guess ) but still need oAuth and next-auth ?
Great stuff, Theo! Please, could you advice how to secure multiple pages? Usually all non-auth pages have guards or smth. Calling getServerSideProps and checking for session for each of them sounds not cool I assume. Thanks!
try using middleware in nextjs
This information was very informative. The enjoyability was enjoyable. This video contained its contents.
The video was videoing
ratio
Theo I’m a backend developer coming from go and kotlin, I wanted to check out js(importantly typescript) but don’t want to have the stress of setting it up. Would your create-t3-app allow me to only pick typescript??
I don't understand the question. create-t3-app only supports TS, in general coding in JS is asking for trouble. If you come from Kotlin, Typescript should be a piece of cake :)
Very well explained, thanks
Nice video! Is this codebase available to clone ?
fantastic vid!!!
Hey bro nice explaination with example. thanks for this. But I have a questions How to implement accessToken and RefreshToken login with Nextjs, Redux toolkit with Own backend (Express)
could you get the permissions and put it a global store on login?
Yes when offing you're client you should make a request first. 🤭
Learning auth right now this came in a perfect time
Can you make a video about middleware and pros and cons of handling protected pages in middleware vs at page level?
Fun fact, just because the token is in the secure cookie doesn’t prevent a malicious actor with XSS from making requests to your server from your client. That means they don’t need access to your token in the cookie, they made the request which sent the cookie anyway.
Keep your token in memory.
This is a very good point. But if you store the token in memory, you won't be able to "remember the user" if they close and repoen the client?
You're not wrong about the vulnerability, and I almost gave you credit on this because it was something I hadn't put much thought into. But honestly this falls apart with just a little inspection. Consider: most sites want to 1. share a session between tabs, and 2. keep users logged in on return visits. The first one you might be able to work around with some hacky postMessage, but the second one requires that you persist from memory to a (non httpOnly) cookie or browser storage.
Cross site scripting is easy to mitigate.
You can block request from a browser that doesn't come from your front end source.
Plus there several other ways to mitigate XXS... like another is adding CSRF-tokens to forms that submit request. So without those new token when your form renders, your request would be rejected.
Yes I agree about the “remember the user” issue of storing tokens in memory. Mostly I think where you store your tokens depends on the trade offs you are willing to make vs the functionality required for your use case.
Also, good point in the CSRF and XSS mitigation. CSRF doesn’t protect you if the stored XSS target is the page with the CSRF token. Encoding untrusted data will help here. On larger dev teams I’ve always run into places where a dev hasn’t done anything to protect themselves. So having fuzzing tests and auto pen-tests are helpful.
How about a roadmap / timeline for people looking to become frontend dev, like core stuff we need to go! It's honestly confusing like how much to know to apply for an entry-level position
Depends on where you're planning to work and what you're planning on working with. There are different fields even within frontend, just as there is with backend.
Generally I'd recommend having a decent grasp on PHP and JavaScript when it comes to languages. Knowing the basics of SQL is also good, no need to dig too deep into that though. CSS is a given if you're working with design, and you'll need a really good understanding of that if it's the thing you want to work with.
I'd also recommend learning some basic design patterns for OOP, as that is still very common. It's also just good knowledge to carry around when it comes to thinking about how to structure code. Even if you don't use the exact pattern, it'll often give you some ideas on how to do things.
Learn the basics of MVC; you probably won't need to understand a lot about it, but it's an easy concept to comprehend.
These are basically the things I'd recommend knowing, no need to be an expert though. Nothing too heavy, honestly. You should look at some job listings to see what they want you to know as well.
Other than this, it's all just accumulating experience. Get used to writing code, try using loads of patterns. Even if you're using functional programming, there are patterns you can use there, even OOP patterns (which are often very simplified, or at least less code) which just makes you a bit more comfortable with different ways of writing code.
Another recommendation is to just stay off UA-cam and write code instead. While it's tempting to look at a tutorial and just follow along, think of something simple to do first, try to do it, then you can see if someone has a better solution. Because it's all problem solving at the end of the day, and that's a skill you need to train.
thanks a looot! :)
It is only works on monolith application, what if we need separated API with scaling in mind?
Both servers must respect the same secret. JWTs makes this super easy (hence why nearly all OAuth systems uses it)
Hi, I'm a new dev, well.. I've been working for a while to become a dev, teaching myself. I want to focus on front end and am currently going through learning React.
I want to look into / get into the T3 stack, but not sure which tech to learn in which order, and do I still have to learn Mongo / Express / Node? Or are those replaced with Prisma / tRPC?
Hard when learning to tell exactly what each of the pieces does and which thing to learn in what order.
IF there was some kind of a structure for learning the t3 stack it'd be very helpful for me. Thanks in advance to anyone that answers this.
Look at job listings for roles you want, list down their requirements. Do not spend time investing in bleeding edge unproven tech such as trpc. There’s an infinite amount to learn when it comes to new and shiny shit, but the basics are always the bed rock. Get good with html/css and js/react, learn how to interact with an api and fetch data etc. apply like shit for jobs and learn on the job, don’t wait until you’re “ready”.
Fully agree with Mike. Try to ignore my channel til you get that first job 🙏
@@t3dotgg Haha, cool. Thanks, yeah I don't know. A lot of it goes by me, as I'm not quite there yet, but just trying to get what I need to start getting hired somewhere. Thanks for the advice.
@@harvenius Sure, I just wasn't sure if it was still worth learning express / node and mongo if I would later be using Prisma or Firebase or whatever. And even still what the point of learning them is with wanting to focus on Front End, but I've had difficulty doing projects because I've found that stuff needs a backend and so it's caused some frustration with feeling I need to learn backend to make projects even when I only want to be a frontend dev. blargh
@@walkingin6375 For learning purposes you can easily use existing APIs. Having said that following a simple express tutorial will probably set you up with most of what you need backend wise for personal projects while still getting to practice TS.
the cookie is accessible from the browser, no? still, better than local/session storage for sensitive info
Can we use T3 stack as a PWA ?
Where can I see the source of this damn code?
so good!
I started with Php, so server-side was always GOD. What do you thing about checking for a session cookie in the Next.js middleware, on paths that the user should not have access to if not auth-ed?
We use it in production since middleware went stable. Since the middleware gets executed inside the reverse proxy at the Edge there is no way it isnt secure. But you must have validation of JWT etc. Never blindly check a cookie, always make sure its encrypted right
@@philheathslegalteam Yeah since middleware is stable now I would love to use it for restricted paths :) I would generate a hash (server-side) after a successful user auth. A new session would be create in the database and only the hash would be stored in a cookie. When a user visits a restricted path, the middleware sends a request to the server and checks if the session hash is valid. Would it still be better to encrypt the cookie in this scenario?
@@lindor94 yep that is essentially session auth. Next Auth using cookies is great for this, same with any other cookie library.
We use JWTs so this is our workflow.
1. Securely create jwt cookie.
2. Refresh token often in client
3. Middleware on restricted route uses JWT verify with our JWT secret. If it has expired we hit up our OAuth system (sup abase) and use the refresh token to get a new JWT. If that fails we block the request and redirect to /
Also, middleware is not just limited to auth etc. We call several RPC Functions in our database from it on a different endpoint to make sure the user has access. Possibly the most useful technology Next.js has come out with for us.
We can now SSG the restricted routes without worrying abt security. And won’t even have to manually do useEffect redirects anymore. Next is great
@@lindor94 I don’t see encrypting the cookie to be very meaningful. Encode it yes. But an attacker will have the means to attack either way. Only prevents leaking of personal info if the cookie is a JWT. I’m no security expert so I wouldn’t be able to tell you tbh. We just use standard base64 encoded JWTs in cookie
please do a video with sessions and express-session
absolutely agree with you. My previous campany ask front-end to do somethings that back should do. Auth is one, anther is form validation. It drives me creazy.
I think some front end validation is good so that you don’t send an obvious bad request to the server. The server should perform validation because the client can not be trusted and there may be clients in the future you have no control over.
@@andrewTaylorCodes I have no problem with front end validation, I have problem with only validating data on front-end. I totally agree with you.
Awesome chat!
hello can you make trpc tutorial content from the scratch, your contents really help me a lot
I’m sorry, I have to correct a few things. If you set a cookie as “HttpOnly” it will not be accessible to JavaScript. I’m not sure of all of the different ways to making AJAX request but in my experience if you use window.fetch you will receive cookies from the server and will send cookies back (even HttpOnly cookies) in your request.
Sure you can protect cookie modification or forging by signing the cookie server side. But… without HttpOnly you make it easier for a browser extension or any other rogue JavaScript to hijack a user’s session.
so many hairs on the left eye, how can you even see screen?
Hey guys I am watching this as I'm learning nextAuth for the first time and I was happy to understand a lot of things (code wise at least) for once BUT what he said about JWTs got me confused. Wasn't he using JWTs in this very example? Are there other ways? Aren't JWTs secure?
i don't think that JWTs are insecure, is more that people abuse the format and fill it up with a lot of data that are not used for the particular request you're making (sometimes is metadata, nothing to do with authentication), so you end up having a heavy overhead in every request because of the token, RBAC can hel mitigate this, but yeah as someone working with auth0 jwts i can see how it can really quickly end up as a mess... another thing is that if you store some info on the token to save trips to databases or another BE request you still need to sync the info on the token with the source of data, so another worry to have, these are not easy/fun things to do so i think that's what he was talking about
It doesn’t help much when you ask “what is auth” and someone recites the Google answer to you for some authN/authZ junk they memorized for a test/interviews. This explanation is incredibly helpful
Also, this video helped me unblock my team on a current sprint - thanks!
In the RBAC example the "Admin only view" is rendered only when the user's role is admin. Still, when a non-Admin is logged in, is it possible to find "Admin only view" in the bundled javascript that is sent to the user's browser, via reverse engineering?
I think it would be dependent on your rendering.
Not 100% sure but hopefully someone else will chime in here as I am super curious about this as well.
Depends on how you split the code but essentially yes if you have a giant bundle it all goes along for the ride. The point is though that the backend should reject any requests to stuff you aren’t allowed to do, so it doesn’t really matter. Never trust the client. IMHO
@@jameshamilton2015 Brother of I have indigestion and the only thing I'm splitting is turds
Its still 100% safe to leave it that way if Your server stops the requests to any admin related endpoints. Frontend code id never secure.
That's great but if you're doing offline-first you have to look at the storage.
What about NextAuth?
Could you give an example of using Next-auth where the database and most API endpoints are on another server using Prisma
It would look a lot like this example but with a hell of a time dealing w/ DNS
@@t3dotgg it's actually for my work, so they're using NextJs as a front-end and Express in the backend. I know that's not ideal, but they like to decouple front and backend. We started with trpc and it works like a charm, but the auth is still a manual mess (custom Google and Twitter logins) so I'm still hoping to convince them to use Next-auth. Or make an exception to call the Prisma DB in the front-end
You can use Next auth with a custom provider, on this provider you just implement the authorization method pointing to your express server route
@@eduardosotero Thanks for the tip!
Make your own ;)
Can't wait
Please, make more videos like this around everything, please this just helped me so much. more more more more
All makes sense.. but, your strategy (in your example with nextjs) is a single page... what if you have a bunch of files or folders that require authentication ( while others do not ). Having that "check session method", in all those places seems terrible.
What is your strategy for many folders/files that need auth?
you move the auth to middleware that executes before matching routes that you specify
Happy to see you are uploading at reasonable hours sweet Theodore.
After the video, I have a LOT more questions about auth.
Second nerds
waiting for "Auth: It's Harder Than You Think"
Why is JWT bad I don't understand? Why is storing JWT in localStorage bad???
Unpopular opinion:
Saying cookies are a safe way to authenticate a user is like saying Angular is a good framework. :)
Why not both? If the client knows it is not logged in, why spend the time to make a request to the server if the client can assume that request will be denied?
Because your client can’t know. “Logged in” is a snapshot, not a status
@@t3dotgg Right, it can't know. But it can assume, or make educated guesses. Handle cases based on those guesses, verify on the server, and handle accordingly.
if milo yiannopoulos became a coder
Thought the same thing the first time I saw him! xD
zamn, TRPC is so good
nice
Wow...
This is really awesome. And I haven't even watched the full video.
I asked about auth on discord too😅. Was confused that NextAuth's JWT wasn't base64 encoded and the body/payload looked empty. Maybe the body is only empty for CredentialsProviders (??).
In any case, I've come to realize that it's better to use OAuth providers instead of CredentialsProviders. Why? Because Google is better at detecting if an account has been compromised than you are so let them deal with it. To limit the users you allow, just whitelist email addresses.
This is incredibly important. Drop Credentials i favor of Magic email link if you wanna provide email login.
Who else was thinking about Kerberos while listening to this? XD
You forgot the sign up process, email validation, eventually phone too, use Google login or Facebook login, Oauth, websso, etc... In the real world it's not so simple as you describe on your school video...
Cookie isn't automatically sent when we use AJAX, which often is the case with SPA. Cookie can only be secure if you sign it on the server to prevent modifications on the client (and subsequently, check for that signature every time). If you do however sign the cookie on the server, it's every bit as secure in localstorage. Cookie can be accessed with JavaScript just like localstorage. Secure flag for cookie will only help because it prevents sending cookie over insecure channels such as HTTP. If it's not signed, user may manually change both in the browser, modification isn't limited to localstorage. Signature is not relevant, if session token (stored in either cookie or localstorage) is a random number with sufficient entropy (for purpose of example: 32 bytes +), on account of the fact that even if user changes it in the browser, the chance of guessing someone else's token are for all intents and purposes impossible (approximately 1 in 2^256).
So what do you think of access / refresh token? Is it necessary or can you just have one token in httponly cookie?
You're assuming the backend api will be only used by a web browser. Cookies won't work on all clients, JWT is the better solution.
11:45
A lot of very good groundwork an basic knowledge about auth, well put together.
But pretending JWT-s don't exist is a bit steep, when they do exactly the opposite of what you are explaining, after the initial login request.
I do believe it is lazy, less secure and annoying to use jwt for identity claims, so you have to put the auth logic in the client too, and keep the session data in it for an extra sprinkle of lazyness. But that's how a lot of apps work, that's how a lot of "tech leads" want it to work and can't really pretend otherwise :(
JWT is perfectly fine for using database less Authentication. Just store only user id or user name in them. Sign it with a secret on the server. Store the token in the cookie. Make it small. Literally just pass data, that you need on the *server* to be able to authtorize the user efectively (which might just be users id). The key is that you do not have to store sessions in the database this way.
Also the "expires at" claim can be used for good FE experience when you can show a message to a user that his session is going to expire, so that he can renew it while it's valid, without login.
Of course everything I wrote can be done without JWTs (rolling your own solution) but why not use the standard?...
Can you explain how it's lazy, less secure and annoying? My understanding aligns with Daniel's - the advantage of it is that you don't need to store a "session" in the database.
I do think it's confusing because libs like NextAuth will talk about using both sessions and JWTs (i.e. sessions with "strategy: JWT" - what does that mean). And some sites talk about sessions being stored in cookies while JWTs are stored in local storage so it can be reused as a Authorization Bearer token when making requests as if that was the only possibility, but in reality, JWTs can also be stored in cookies too.
@@Nil-js4bf Yep, I'll clarify.
If you only store userid and name in it and stick it in the cookies, that's perfectly fine.
Lazy and less secure is when they want to store a lot of data in them. A larje JSON user object, their shopping cart (or any applicable app-specific info), their theme preferences, etc.
Cookies have a small max size, and session storage doesn't persist between tabs, so then you stick it into local storage. Effectively it's out in the open. The signature is strong enough encryption that you cannot (apart from very specific use cases) tamper with the content, but any JS can read that data.
Even worse, any other site can grab that token, send it back home, and with that token anyone else can pretend to be you, and the server would be non the wiser.
This is clearly not good practice, but it is very quick to implement, so many 'we are paying for features' mindset orgs prefer it.
And if you are already making the sensible choice not to use a bloated JWT, but only store user id in it, and put it in the cookies, at that point you might as well have a session DB and put the session id in the cookies, there is not much difference there (either is fine).
@@Szergej33 only chrome extensions can pull JWT, same with XSS attack. If Your app cannot mitigate XSS you have a much larger problem than localstorage.
Chrome extensions can also read secure cookies.
It wasn't in fact easier than you thought
Auth? Do we even need it?
lol
Embrace the honour system!
i'm not sure about the "cookie" part... I mean "document.cookie" is pretty accessible by JS... in fact as much as Local Storage.... plus, since the cookie is applied to every request, you are vulnerable to CSRF unless you put an extra header, or validation....
I like the idea of JWT, i'm all for your "stop putting shit in JWT" as such as if you change user permissions, if they are "on the server" they can be changed on the fly, as if they are "on the client" the token must be refreshed at every change.
For me auth is
4 routes: /login, /register, /forgot, /reset
and Middleware(s) on the server
if you want to store sessions of validate JWT is seems that thats all you have to think about (unless you want to complicate it)
Auth is only used to verify if a session is a guest or logged in user. Typically you can do this by checking if the user was granted the bearer token present in the request.
oAuth is more about scoping and permissions, and the process it takes to obtain access to the API. For example, you may have to have an approve application and keep requests within a specific scope.
All other validation is just implementation details and is usually handled with middleware or on a per request basis. For example, you don't need to check if a user has admin permissions to know that they are signed in.
JWT is all about verifying the user's claims. JWT can be overkill for auth because its a signed bearer token so it is a lot of data. Typically an arbitrary string is good enough. Some companies use JWT as a bearer tokens so you can't hijack the API to make unapproved requests. For example, I could inspect the http requests in the browser then use the already granted bearer token to bypass the entire authentication flow. If JWT is used, it would be much harder to do this.
That "ideally" makes sense if its all webauthn stuff authentication is more likely to happen on client via fingerprint. but obviously to get token in cookie you need to make a request to server just so the cookie is not suseptible to XSS attack. Also you can store the token in memory like in redux store if its JWT you can verify signature and get user details at client side only cause JWT already has that info embedded it. I prefer that redux store cause 99% of time the authentication server takes care of keeping user signed in and SSO on different domain. So every time its better to get new JWT on client side and store in redux if user is logged out or token is expired the client library making request to get token will redirect user to login page
Also I dont llike use DB to authorize part as far as we are talking of JWT here we can add those claims to JWT. and stop the user on client itself from making unauthrized actions.
Ah just posted when you said JWT f**ks up the model 😂😂😂😂
Dude thank god. im one min in and you already broke the spell of frustration that comes any time i want to look any video up...
1 ... Your making a video in your FIRST language, not your third. (no offense to anyone but it's very confusing why people who want to give technical tutorial lessons in a language that they struggle to speak... I give them credit for knowing multiple languages, but it's very hard to understand abstract concepts / nomenclature when the person has a thick ... accent
2.. your not going for the MOST LONG TAIL STACK POSSIBLE... yea this is gonna be auth except its routed through your frontend ... but you need to use this one module which is only available on a version of node that isnt compatable with the rest of your stack. and is outdated in a few months.
3... you actually giving some details about the stuff your doing.... it seems that most people that do the above 2... just FLY through the details , -> or have a shitty streaming setup...
all to say... keep up the good work you got a sub here.
no its not
CORRECTION: storing stuff in a cookie doesn't make it any secure what so ever. so it doesn't really matter just use the easiest way for your project.
considering a 2FA is always better(more secure), "and annoying"
also requesting stuff when you need it is SLOW and purposeless and adds 0 percent of security, unless you consider making it a little bit(maybe like 5%) harder(from the attacker's end) "more secure"
This dude is really just over complicating things for absolutely no reason other than he loves to hear himself talk.
I get a LOT out of the videos. I love learning where my thinking is not up to speed
Clerk has solved Auth