Implementing RBAC with Next.js SDK

[joelcowie]

Hi all,

I have a Next.js app, and taking advantage of built in API routes to cover my server logic and so far that’s working fine. I have installed and configured the auth0-nextjs SDK and everything works as expected.

However, my use case requires implementing RBAC, and including those roles and permissions in the token so that I can validate permissions on both the frontend and backend. It seems that RBAC is specific to an API, when our project is configured as a Regular Web Application (as recommended for a Nextjs app).

I have already created an action on Login to add the roles to a token, but that’s not granular enough - I specifically need to see the permissions of each user in the token. This use case seems supported if I use a separate API, enable RBAC, and “Add Permissions in the Access Token”, but as mentioned I don’t have an API configured, just a Regular Web App.

Is there a way to accomplish this in NextJS alone? I feel like I have a few options:

1. Separate our server logic out to an external service instead of Next API Routes, and configure an API in auth0 accordingly.
2. I’ve seen some related examples using Authorization Extension instead of Authorization Core, however I understand this is on track to be deprecated so I’d rather avoid this.
3. Implement some extra logic on login using an action/rule to get the user’s permissions via the management API and add them to the token. I could theoretically hit the management API on login but this would get expensive and have rate limits.

Is there something I’m not thinking of? Or some way to configure a separate API and have my Next API Routes use that?

Appreciate any help, thanks!

[dan.woda]

Hi @joelcowie,

Welcome to the Auth0 Community!

You’ve summarized the issue really well. I wouldn’t suggest #2 or #3.

In short, the problem is that permissions are limited to the Access Token (AT), your Next App is the client, and the client isn’t meant to inspect the AT.

That’s not to say your Next App can’t, it’s just not the intended audience of the AT. The permissions are in the AT, and you can decode it if you pass an audience and request a JWT.

With that said, this might not be how the AT is intended to be used.