I’m using Auth0 with a React single-page application.
I need to implement authorization logic at the frontend level — for example, hiding certain routes or UI elements depending on what the user is allowed to do (e.g., only admins can access an admin dashboard).
I see a few possible approaches:
Include user roles as a custom claim in the ID or access token via an Auth0 Post-Login Action (I’ve read that Auth0 provides this option). Then, check the roles in the React app.
Instead of roles, rely on the permissions claim that Auth0 automatically adds to the access token when RBAC is enabled (“Add permissions in the Access Token” option).
Dynamically retrieve roles or permissions from the Auth0 Management API (though I know this isn’t recommended directly from the browser).
I’ve read that tokens generally shouldn’t expose too much authorization data, and I’m trying to understand what’s considered a best practice for SPAs.
For frontend-only route visibility (not API enforcement), should I rely on roles in the token (via a Post-Login Action), on permissions in the token (via RBAC), or is there a more secure/recommended way to handle client-side authorization in a React SPA using Auth0?
Thank you for posting your question. Your best bet is to use the Auth0 RBAC inside the API setting, with the addition of adding the permission to the access token in the API RBAC setting. This way, users who have been assigned a specific role will automatically receive the permission during access token retrieval.
Thanks for the previous answers. I’m mainly concerned with the frontend side of RBAC.
Right now, I already receive the user’s permissions in the access token, but I’m not sure what the best practice is for authorizing access to specific frontend routes.
For example: only an admin user should be able to visit a certain page in my React app.
If the user’s role were present in the token, I could simply check it in the routing logic.
However, since I already have permissions in the token, I could instead base my route protection on those permissions rather than on roles.
This is where my confusion started: when I enabled RBAC, I assumed Auth0 would automatically include the user’s role in the token. Later, I discovered that roles are not included by default, and that you need a Post-Login Action to add them manually — and I also read recommendations saying that exposing roles in tokens is not ideal.
I hope this clarifies my doubts: For frontend-only route visibility, should I rely on roles added via a Post-Login Action, or should I structure all authorization logic around the permissions already included in the token?
I would advise structuring the authorization logic around the permissions already included in the token and using roles as the groups (how you assign capabilities) and permissions as capabilities (how you enforce access). This will also enable a granular approach to accessing the resources behind protected routes.