This tutorial demonstrates how to add authorization and access control to a React application. We recommend you to Log in to follow this quickstart with examples configured for your account.
I want to integrate with my app15 minutes
I want to explore a sample app2 minutes
Get a sample configured with your account settings or check it out on Github.
Access Control in Single-Page Applications
In Single-Page Applications you use Access Control to define what different users can see, and which routes they can access. With Auth0, you can implement access control by using scopes granted to users.
To set up access control in your application, enforce the following restrictions:
- The data from an API can only be returned if the user is authorized to access it. This needs to be done when implementing the API.
- The user can access specific routes and UI elements in your application only if they have the appropriate access level.
The previous step used the
read:messages scope for accessing API resources. This scope indicates that the user can only view the data. You can consider users with this scope regular users. If you want to give some users permission to edit the data, you can add the
Determine a User's Scopes
You can use scopes to make decisions about the behavior of your application's interface.
You can specify which scopes you want to request at the beginning of the login process.
If a scope you requested is available to the user, their Access Token receives a
scope claim in the payload. The value of this claim is a string with all the granted scopes, but your application must treat the Access Token as opaque and must not decode it. This means that you cannot read the Access Token to access the scopes.
To get the scopes, you can use the value of the
scope parameter that comes back after authentication. This parameter is a string containing all the scopes granted to the user, separated by spaces. This parameter will be populated only if the scopes granted to the user are different than those you requested.
To see which scopes are granted to the user, check for the value of
authResult.scope. If there is no value for
authResult.scope, all the requested scopes were granted.
Handle Scopes in the
Add a local member to your
Auth service and initialize it with all the scopes you want to request when users log in. Use this member when initializing your instance of the
setSession method to save the scopes granted to the user into browser storage.
First, check for the scopes in the
scope key from
authResult. If it's not empty, the user was granted a different set of scopes than the one the application requested, so you need to use the ones in
If it's empty, all the scopes requested were granted, so you can use the values from the variable that stores the requested scopes.
Add a method called
userHasScopes that checks for scopes in local storage. You can use this method to conditionally hide and show UI elements to the user and to limit route access.
Conditionally Display UI Elements
You can use the
userHasScopes method with the
isAuthenticated method to show and hide certain UI elements.
Protect Client-Side Routes
You may want to give access to some routes in your application only to authenticated users. You can check if the user is authenticated with the
In this example, if an unauthenticated user tries to access the
/ping route, they are redirected to the
Limit Route Access Based on Scopes
To prevent access to client-side routes based on a particular scope, make a call to the
userHasScopes method in the route's
If the user does not have the
write:messages scope, they are redirected to the main route.
Conditionally Assign Scopes to Users
By default, when you register scopes in your API settings, all the scopes are immediately available and any user can request them. If you want to handle access control, you need to create policies for deciding which users can get which scopes.
Considerations for Client-Side Access Control
For the access control on the application-side, the
scope values that you get in local storage are only a clue that the user has those scopes. The user could manually adjust the scopes in local storage to access routes they shouldn't have access to.
On the other hand, to access data on your server, the user needs a valid Access Token. Any attempt to modify an Access Token invalidates the token. If a user tries to edit the payload of their Access Token to include different scopes, the token will lose its integrity and become useless.
You should not store your sensitive data application-side. Make sure you always request it from the server. Even if users manually navigate to a page they are not authorized to see, they will not get the relevant data from the server and your application will still be secure.