Auth0 APIs, RBAC, and Actions Overview Using Node JS and Google Cloud Datastore

This video demonstrates the basics of hooking up your APIs in Auth0. In this video we will set up permissions and roles so that when a use logs in to Auth0, we can request the relevant scopes from the end user and add custom claims on the user's access token. We will use basic conditional logic in Actions to assign relevant roles and permissions to the user in real time when the user is logging in. At the end of the video, we will see how we can set up a service account in one of our post-sign up actions and create a user in Google Cloud Datastore.
We will use Postman to execute the calls to our API and allow only authenticated users to make requests to our "create boat route". We will take it a layer further and guard the route behind a specific permission that lives on the user's access token as well.
Leave a comment with what you would like to see next!

[@sridharnarsingh2353]

Nice and detailed video, thanks for the same. How does the Auth0 deny (or allow) access to the APIs based on the permission. Is this something that needs to be handled in the application based on the token?

[@Kelvers45]

When you log into Auth0, you get an access token returned to your application (assuming you passed an audience for the API in the authorizationParams to the /authorize call). Before you are sent back to your application and while Auth0 is in control, you can append custom scopes/claims to your access token. Or on your API in Auth0, you can enable RBAC and add permissions to your access token automatically. Your application now has an access token that is encoded in session storage of your browser as a cookie or keychain/android secure storage for native applications. When you make a request to your backend API, you can pass that access token as a bearer token (in the case of SPAs and Native apps) to your endpoint. In the case of Regular Web Applications the cookie is passed automatically with the request. In your API, you can use Auth0 SDKs to validate the access token is issued by Auth0, not expired, and contains the appropriate permissions to access the endpoint. You determine which permissions are required to allow or deny access here and usually with the help of Auth0 SDKs but you can also decode the token with a package like jwt-decoder and conduct your own logic on what is required to make the call.