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!

thank you for this video!!! clears out a lot of things in my head 🚀

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

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

Fun fact, chrome extensions CAN access secure, httpOnly, SameSite cookies. Food for thought.

@t3dotgg

2 жыл бұрын

This scares me

@Nil-js4bf

2 жыл бұрын

wtf, why would they do that. Must be one of the permissions that it asks for that I never look at.

@sidwebworks9871

2 жыл бұрын

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.

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

@stupeyca

Жыл бұрын

Same, man.

This is great! I'm using the template that you created n my personal project and auth has never been easier. Thanks!

@t3dotgg

2 жыл бұрын

I didn’t build it!!! All the T3-OSS team

@EldorJ10

2 жыл бұрын

@@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 😄

@elonmask7271

2 жыл бұрын

could you link the repo pls

Awesome video, thanks Theo! ♥

Ur are awesome installing Twitch just for u man so i can watch this live❤️

These are my favorite types of videos that you make. You are by far the easiest and most concise teacher I have found on KZread for beginners

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

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.

love your channel man even at 1mill still will be underrated

Thank you. You are increadible on explaining a concept. clear and on point

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.

Really helpful video Theo!

Crystal clear explanation. Thanks a lot :-)

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.

I am so glad I saw this video. Thanks ! Also, imo I like shorter videos like these.

Please make a detailed video on different authentication patterns.

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.

legit i only watch you because I love your hair haha good stuff man thanks

Very well explained, thanks

This information was very informative. The enjoyability was enjoyable. This video contained its contents.

@Allyourneedsmet

2 жыл бұрын

The video was videoing

@stefanplusplus917

Жыл бұрын

ratio

What about if I need to share this users list across multiple projects ( auth microservice I guess ) but still need oAuth and next-auth ?

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

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

fantastic vid!!!

A self learned dev like me who will be working as a freelancer in a few months badly needs this

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!

@trenom

Жыл бұрын

try using middleware in nextjs

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.

@ManoToor

2 жыл бұрын

Look into containers and kubernetes

@RaZziaN1

8 ай бұрын

going kubernetes is too much@@ManoToor

Yes when offing you're client you should make a request first. 🤭 Learning auth right now this came in a perfect time

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??

@Atmos41

2 жыл бұрын

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 :)

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.

@harvenius

2 жыл бұрын

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”.

@t3dotgg

2 жыл бұрын

Fully agree with Mike. Try to ignore my channel til you get that first job 🙏

@walkingin6375

2 жыл бұрын

@@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.

@walkingin6375

2 жыл бұрын

@@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

@D3ADPIX

2 жыл бұрын

@@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.

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!

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

@CottidaeSEA

2 жыл бұрын

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 KZread 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.

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)

so good!

Great content bro, btw what is T3?

could you get the permissions and put it a global store on login?

Nice video! Is this codebase available to clone ?

It is only works on monolith application, what if we need separated API with scaling in mind?

@philheathslegalteam

2 жыл бұрын

Both servers must respect the same secret. JWTs makes this super easy (hence why nearly all OAuth systems uses it)

thanks a looot! :)

Can you make a video about middleware and pros and cons of handling protected pages in middleware vs at page level?

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?

@philheathslegalteam

2 жыл бұрын

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

@lindor94

2 жыл бұрын

​@@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?

@philheathslegalteam

2 жыл бұрын

@@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

@philheathslegalteam

2 жыл бұрын

@@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

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.

@nooblife1668

2 жыл бұрын

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?

@andsnpl

2 жыл бұрын

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.

@sneak9407

2 жыл бұрын

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.

@MasonPayne

2 жыл бұрын

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.

Can't wait

Awesome chat!

Can we use T3 stack as a PWA ?

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

@t3dotgg

2 жыл бұрын

It would look a lot like this example but with a hell of a time dealing w/ DNS

@martins3037

2 жыл бұрын

@@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

@eduardosotero

2 жыл бұрын

You can use Next auth with a custom provider, on this provider you just implement the authorization method pointing to your express server route

@martins3037

2 жыл бұрын

@@eduardosotero Thanks for the tip!

@lindor94

2 жыл бұрын

Make your own ;)

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?

@DavidWoodMusic

2 жыл бұрын

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.

@jameshamilton2015

2 жыл бұрын

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

@DavidWoodMusic

2 жыл бұрын

@@jameshamilton2015 Brother of I have indigestion and the only thing I'm splitting is turds

@philheathslegalteam

2 жыл бұрын

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.

Where can I see the source of this damn code?

Unpopular opinion: Saying cookies are a safe way to authenticate a user is like saying Angular is a good framework. :)

hello can you make trpc tutorial content from the scratch, your contents really help me a lot

Second nerds

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?

@YuichiTKD

Жыл бұрын

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

the cookie is accessible from the browser, no? still, better than local/session storage for sensitive info

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.

@andrewTaylorCodes

Жыл бұрын

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.

@seanbruceful

Жыл бұрын

@@andrewTaylorCodes I have no problem with front end validation, I have problem with only validating data on front-end. I totally agree with you.

so many hairs on the left eye, how can you even see screen?

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?

@gsimsamarawikrama5733

Жыл бұрын

you move the auth to middleware that executes before matching routes that you specify

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.

That's great but if you're doing offline-first you have to look at the storage.

waiting for "Auth: It's Harder Than You Think"

Please, make more videos like this around everything, please this just helped me so much. more more more more

Happy to see you are uploading at reasonable hours sweet Theodore.

After the video, I have a LOT more questions about auth.

if milo yiannopoulos became a coder

@rod6722

Жыл бұрын

Thought the same thing the first time I saw him! xD

nice

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?

@t3dotgg

2 жыл бұрын

Because your client can’t know. “Logged in” is a snapshot, not a status

@devonlamond

2 жыл бұрын

​@@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.

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...

Why is JWT bad I don't understand? Why is storing JWT in localStorage bad???

Wow...

zamn, TRPC is so good

Who else was thinking about Kerberos while listening to this? XD

Auth? Do we even need it?

@NathanHedglin

2 жыл бұрын

lol

@f1f1f182

2 жыл бұрын

Embrace the honour system!

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.

@philheathslegalteam

2 жыл бұрын

This is incredibly important. Drop Credentials i favor of Magic email link if you wanna provide email login.

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.

It wasn't in fact easier than you thought

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 :(

@danieljenikovsky9455

2 жыл бұрын

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?...

@Nil-js4bf

2 жыл бұрын

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.

@Szergej33

2 жыл бұрын

@@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).

@philheathslegalteam

2 жыл бұрын

@@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.

This is really awesome. And I haven't even watched the full video.

11:45

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).

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)

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 😂😂😂😂

So what do you think of access / refresh token? Is it necessary or can you just have one token in httponly cookie?

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.

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.

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