 Welcome back for the second video from our NestGS series. In our first video, we learned how to protect our API with an access token. This video will continue where we left off and add some role-based access control to our NestGS API. Knowing who your authenticated user is and whether they have access to your API is one thing, but knowing their roles and or permissions helps us maintain a fine-grained control over which actions they can perform for each API endpoint. So let's get going. Let's start by opening the codebase from the first video. In that video, we create an authorization guard that checks if an API request has a valid access token. In this video, we'll create a second guard that will check for permissions in that access token. We can create a permission guard through the NestGS CLI by running nest generate card authorization slash permissions with the no spec flag. The NestGS CLI will create a new permissions.card.js file in our authorization folder. We'll start by removing some of the boilerplate code generated by the NestGS CLI. We won't be using observables and or can activate function will only return a boolean, true if all permissions are granted. Before we continue, let's not forget to start our NestGS development server by running npm run start colon dev. Before we start creating our permissions guard, we want to pass along the required permissions for each API endpoint. We can use nest set metadata for this. We'll add a read cats permission to the cat endpoint. Our authorization guard validates and parses the access token. One benefit of using the express middleware is that it will add all JSON web token claims to a user object on the request. Let's grab the permissions from our access token. We'll get the request from our cards context and check if there are any permissions added to its user object. If there are none, we'll use an empty array. Once we know which permissions are assigned to the user, we can check which permissions are required to access the current endpoint. We'll inject the reflector in the cards constructor. This reflector will give us access to the permissions metadata we set in our controller. Now that we've injected the reflector, we can pass it our cards contact handler to get all required permissions for the current endpoint. When there are no configured required permissions, we'll use an empty array. We now know the permissions assigned to the user and which permissions are required to access the current API endpoint. Let's check if our user assigned permissions contain all required permissions. We've configured the permissions metadata as an array, which allows us to require multiple permissions for an endpoint if we need to. If we have no permissions configured for the current endpoint, this means there are no extra permissions required to access the endpoints. If there are no required permissions or the user has all of the required permissions, we'll return true from the can activate method. Should the user have no or not all required permissions assigned, we'll return a four or three forbidden error with the message insufficient permissions. The last thing we need to do is add the permission guards to our cat endpoint in our controller. Make sure to add it after the authorization guard. When we try out our cat endpoint, you'll notice we get a four or three error. This is because we haven't assigned any permission to our user yet. Before we add permissions, let's enable RBAC in our API setting. We'll also enable the option to add permissions to the access token and press save. Let's hop on over to our API's permission stop and add the read cat's permission to our API. Now that we have configured our API's permissions, we can add it to a role. We're doing role based access control after all. Let's give the role a name and a clear description. When the role is created, we can add the read cat's permission through the permission step. First select our nest.js API and then our permission. Lastly, we can assign our newly created catperson role to a user. Open up the user details and hop on over to the roles step. We'll click the assign role button and choose our catperson role. If we issue a new access token for the user, we can see it now contains the read cat's permission and add the other permissions you might have added to the user's role. Let's try to get the cat endpoint again with our new access token. It should now return a success response since our access token contains the correct permission. That's all for today. If you'd like to see more nest.js content in the future, please let us know in the comments below and don't forget to subscribe. See you all next time!