Wow can’t wait for the kit! Multi level auth is something I’ve been needing for a specific project. I’ve been using the tables but this seems far for more streamlined and efficient
How do you deal with changes while the user is logged in? So if somebody is changing your role in one group while you are logged in, how do you refresh the information on the token?
3 месяца назад
Some logic that let your API know the next time the user makes a request, refresh the token with the updated permissions, etc.
@@WebDevCody Thank you for your fast answer :) I'm new to frontend and work more in the backend. So if I understand it correctly you can use useSession to update your token on the server. But the following scenario: User A and B are logged in. User B is changing the role of user A in a group. How is the token of user A updated? UseSession cannot update other users token if I understand it correctly?
@@easylite376 you are correct. One way to mitigate this problem is to call the useSession update method inside the root of your application (assuming you are using a frontend framework). This way, every time the user enters or refresh your webapp it'll update the token. Once the the webapp is loaded, the client side routing will kick in and no other token updates will be made (unless you explicity call the update)
coincidentally this is like what im doing like right now. Great vid. Here is a video idea. How to use next auth with an external backend. Without nextjs built in backend if you get what im trying to say. because there is this backend guy i work with who built the jwt himself then in my next app i use next-auth so we are really confused on how to amalgamate the two strategies.
You don't use next auth in this case, the backend guy sends you the token, you store it in http only cookie and that's it. Then you send the jwt from the client in header in all your request to the backend to verify the user for access control. You should go study how auth work then you will understand what is going on there.
l'm looking to enhance the security of my Next.js app by implementing a feature where users need to re-enter their password before accessing routes displaying sensitive information or performing critical actions. How can I protect these routes to ensure that only authenticated users who have re-entered their password can access them?
Have you ever had to implement quotas? Like, for a subscription system (not pay as you go). Working on setting up something right now where I want the user to be able to perform X operations a month, based on their sub tier. I imagined I could just create a sql query and count the operations the user has performed in the alloted time frame, but that doesn't seem ideal for a few reasons. Maybe I make a "quotas" table with a period_start and period_end column, then deduct their quota? Im using stripe so I could also probably just use the web hook events to update their quota when they renew their sub or it cancels.
in the video I clearly see how you extend the Session object, and it works for me, but could you please explain how you extend the default User object, and the Token object? On my User object there are default properties like id, name, image, email. How do I extend it, so I can grab other properties from my db? Thank you! Very useful video
I really enjoyed the video! I have a question though: Would it be feasible to create an auxiliary function for data fetching? My concern stems from the fact that for every request, I need to include the authentication token in the header. Consequently, in every page, I find myself having to retrieve the token from the cookie using next/headers. I recall achieving this functionality with Axios and Next.js by setting the token within an Axios variable. Is it possible to replicate this behavior using the Fetch API? OBS: I'm using an external backend application
This useSession got me thinking, it's synchronous, so there is no communication with external system, but still can decode the session. I wonder if it's using a public key to decode a non http only cookie... What's your thoughts on that?
UseSession hits your server to have the server decode the token. If you open the network tab you’ll see it make requests to your api since the browser doesn’t know how to decode the encrypted token
Informative video. I have a question though. How can I integrate SAAS level i18n support in next js app router. so if user added more than one language they can see the translated route otherwise they will see no lang route by default.
Thanks, but after introducing app router we need to add manual lang/locale route. before in page router, we just need to add config for i18n. So for default lang we need to add redirect logic so nextjs can also load no lang route. it seems like we are trying to hack that feature.also heard that redirecting locale route is bad for SEO.
@@WebDevCody Refreshing JWT is super tricky, specially if you update the role of other user that is already logged. The last time I did this was with websockets to notify the clients they should revalidate, if there is a better way without needing to check each request I want to know it.
@@neociber24 from the next-auth docs, it looks like you can just call session.update() from the UI and that will trigger the JWT callback to re-run with an trigger === "update" argument.
Good informations were exchanged here. And what if user uses multiple devices to log in to the same account. Multiple devices, multiple cookies and you cannot update them because it lives on user device. This is another argument to check everything on request.
Couldn't u keep a socket open and from serverside push a message if the users role changes or their membership revoked then from client-side get refreshed token
Hey Cody - are there any concerns here from a security standpoint? Could a user alter their JWT to a new plan/role ? How do you make sure that these things cant be spoofed/intercepted
no, because the token is signed using a secret that only lives on the backend, so if someone tries to modify the JWT, your server will see it was changed and throw authentication errors
@@WebDevCody sure but next-auth exposes update method and api to the client via session provider. I could update my role and plan myself using the provided API. It is a weird default, but you have to explicitly disallow session updates that were triggered initially client-side or at least not let them update critical information.
@@WebDevCody When using useSession hook there is an update method that calls an API. In the JWT callback there is a trigger set to "update". Now notice that you can send anything to the API. You should check the trigger and only update fields that have no critical information. Everything critical should be set during sign in. In v5 there is a new server-side unstable_update.
It's not recommended. The main reason access tokens are sent over cookies (with httpOnly flag enabled) is that client side javascript (malicious and not malicious) won't be able to access it directly. However the user's browser still keep the cookie saved locally and it'll automatically send it to your server on every request, allowing your server to authenticate your users.
