Build a protected web app with React

How React apps are architected or constructed is outside the scope of this guide. It’s also worth noting that there are many React-based frameworks and generators for building web applications, such as Next.js, Create React App, and Gatsby. What is "best" is highly contextual to the product and user requirements for any given project.

To demonstrate our SDK integration, we will be using a simplified, non-production-ready, to-do app. This to-do app represents a Single Page Application (SPA) with nothing more than React Router added to "the stack" for routing and redirection.

This is a "hands-on" guide. We are providing the web app and resource server for you. You can find the repo on GitHub to follow along. All you’ll need is your own ForgeRock Identity Cloud or Access Manager. If you don’t have access to either, and you are interested in ForgeRock’s Identity and Access Management platform, reach out to a representative today, and we’ll be happy to get you started.

First, clone the JavaScript SDK Samples project to your local computer, cd (change directory) into the project folder, and install the needed dependencies:

There are two projects in this tutorial that require configuration:

Now that we have our environment and servers setup, let’s jump into the application! Within your IDE of choice, navigate to the reactjs-todo/client directory. This directory is where you will spend the rest of your time.

First, open up the index.js file, import the Config object from the JavaScript SDK and call the set() method on this object:

The use of set() should always be the first SDK method called and is frequently done at the application’s top-level file. To configure the SDK to communicate with the journeys, OAuth clients, and realms of the appropriate ForgeRock server, pass a configuration object with the appropriate values.

The configuration object you will use in this instance will pull most of its values out of the .env variables previously setup, which are mapped to constants within our constants.js file:

Go back to your browser and refresh the home page. There should be no change to what’s rendered, and no errors in the console. Now that the app is configured to your ForgeRock server, let’s wire up the simple login page.

First, let’s review how the application renders the home page:

index.js > router.js > view/home.js > inline code + components (components/)

For the login page, the same pattern applies except it has less code within the view file:

index.js > router.js > view/login.js > components/journey/form.js

Navigate to the app’s login page within your browser. You should see a "loading" spinner and message that’s persistent since it doesn’t have the data needed to render the form. To ensure the correct form is rendered, the initial data needs to be retrieved from the ForgeRock server. That will be the first task.

Since most of the action is taking place in components/journey/form.js, open it and add the JavaScript SDK import:

FRAuth is the first object used as it provides the necessary methods for authenticating a user against the Login Journey/Tree. Use the start() method of FRAuth as it returns data we need for rendering the form.

You will need to add two new imports from the React package: useState and useEffect. You’ll use the useState() method for managing the data received from the ForgeRock server, and the useEffect is needed due to the FRAuth.start() method resulting in a network request.

The above code will result in two logs to your console: one that will be null and the other should be an object with a few properties. The property to focus on is the callbacks property. This property contains the instructions for what needs to be rendered to the user for input collection.

Below is a summary of what you’ll do to get the form to react to the new callback data:

First, import the Password, Text and Unknown components.

Next, within the Form function body, create the function that maps these imported components to their appropriate callback.

Finally, check for the presence of the step.callbacks, and if they exist, map over them with the function from above. Replace the single return of <Loading message="Checking your session …​" /> with the following:

Refresh the page, and you should now have a dynamic form that reacts to the callbacks returned from our initial call to ForgeRock.

Since a form that can’t submit anything isn’t very useful, we’ll now handle the submission of the user input values to ForgeRock. First, let’s edit the current form element, <form className="cstm_form">, and add an onSubmit handler with a simple, inline function.

Refresh the login page and use the test user to login. You will get a mostly blank login page if the user’s credentials are valid and the journey completes. You can verify this by going to the Network panel within the developer tools and inspect the last /authenticate request. It should have a tokenId and successUrl property.

You may ask, "How did the user’s input values get added to the step object?" Let’s take a look at the component for rendering the username input. Open up the Text component: components/journey/text.js. Notice how special methods are being used on the callback object. These are provided as convenience methods by the SDK for getting and setting data.

The two important items to focus on are the callback.getInputValue() and the callback.setInputValue(). The getInputValue retrieves any existing value that may be provided by ForgeRock, and the setInputValue sets the user’s input on the callback while they are typing (i.e. onChange). Since the callback is passed from the Form to the components by "reference" (not by "value"), any mutation of the callback object within the Text (or Password) component is also contained within the step object in Form.

Each callback type has its own collection of methods for getting and setting data in addition to a base set of generic callback methods. These methods are added to the callback prototype by the SDK automatically. For more information about these callback methods, see our API documentation, or the source code in GitHub, for more details.

Now that the form is rendering and submitting, add conditions to the Form component for handling the success and error response from ForgeRock. This condition handles the success result of the authentication journey.

Once you handle the success and error condition, return to the browser and remove all cookies created from any previous logins. Refresh the page and login with your test user created in the Setup section above. You should see a "Success!" alert message. Congratulations, you are now able to authenticate users!

At this point, the user is authenticated. The session has been created and a session cookie has been written to the browser. This is "session-based authentication", and is viable when your system (apps and services) can rely on cookies as the access artifact. However, [there are increasing limitations with the use of cookies](https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/). In response to this, and other reasons, it’s common to add a step to your authentication process: the "OAuth" or "OIDC flow".

The goal of this flow is to attain a separate set of tokens, replacing the need for cookies as the shared access artifact. The two common tokens are the Access Token and the ID Token. We will focus on the access token in this guide. The specific flow that the SDK uses to acquire these tokens is called the Authorization Code Flow with PKCE.

To start, import the TokenManager object from the ForgeRock SDK into the same form.js file.

Only an authenticated user that has a valid session can successfully request OAuth/OIDC tokens. Make sure we make this token request after we get a 'LoginSuccess' back from the authentication journey. This is an asynchronous call to the ForgeRock server. There are multiple ways to handle this, but we’ll use the useEffect and useState hooks.

Add a useState to the top of the function body to create a simple boolean flag of the user’s authentication state.

Now, add a new useEffect hook to allow us to work with another asynchronous request. Unlike our first useEffect, this one will be dependent on the state of isAuthenticated. To do this, add isAuthenticated to the array passed in as the second argument. This instructs React to run the useEffect function when the value of isAuthenticated is changed.

Finally, we need to conditionally set this authentication flag when we have a success response from our authentication journey. In your form element’s onSubmit handler, add a simple conditional and set the flag to true.

Once the changes are made, return to your browser and remove all cookies created from any previous logins. Refresh the page and verify the login form is rendered. If the success message continues to display, make sure "third-party cookies" are also removed.

Login with your test user. You should get a success message like you did before, but now check your browser’s console log. You should see an additional entry of an object that contains your idToken and accessToken. Since the SDK handles storing these tokens for you, which are in localStorage, you have completed a full login and OAuth/OIDC flow.

Now that the user is authenticated and an access token is attained, you can now make your first authenticated request! The SDK provides a convenience method for calling the /userinfo endpoint, a standard OAuth endpoint for requesting details about the current user. The data returned from this endpoint correlates with the "scopes" set within the SDK configuration. The scopes profile and email will allow the inclusion of user’s first and last name as well as their email address.

Within the form.js file, add the UserManager object to our ForgeRock SDK import statement.

The getCurrentUser() method on this new object will request the user’s data and validate the existing access token. After the TokenManager.getTokens() method call, within the oauthFlow() function from above, add this new method.

If the access token is valid, the user information will be logged to the console, just after the tokens. Before we move on from the form.js file, set a small portion of this state to the global context for application-wide state access. Add the remaining imports for setting the state and redirecting back to the home page: useContext, AppContext and useNavigate.

At the top of the Form function body, use the useContext() method to get the app’s global state and methods. Call the useNavigate() method to get the navigation object.

After the UserManager.getCurrentUser() call, set the new user information to the global state and redirect to the home page.

Revisit the browser, clear out all cookies, storage and cache, and log in with you test user. If you landed on the home page and the logs in the console show tokens and user data, you have successfully used the access token for retrieving use data. Notice that the home page looks a bit different with an added success alert and message with the user’s full name. This is due to the app "reacting" to the global state that we set just before the redirection.

To ensure your app provides a good user experience, it’s important to have a recognizable, authenticated experience, even if the user refreshes the page or closes and reopens the browser tab. This makes it clear to the user that they are logged in.

Currently, if you refresh the page, the authenticated experience is lost. Let’s fix that!

Because the SDK stores the tokens in localStorage, you can use their presence as a hint for their authentication status without requiring a network request. This allows for quickly rendering the appropriate navigational elements and content to the screen.

To do this, add the TokenStorage.get method to the index.js file as it will provide what we need to rehydrate the user’s authentication status. First, import TokenStorage into the file. Use the TokenStorage.get() method within the initAndHydrate function. Second, add these values to the useGlobalStateMgmt function call.

With a global state API available throughout the app, different components can pull this state in and use it to conditionally render one set of UI elements versus another. Navigation elements and the displaying of profile data are good examples of such conditional rendering. Examples of this can be found by reviewing components/layout/header.js and views/home.js.

The presence of the access token can be a good hint for authentication, but it doesn’t mean the token is actually valid. Tokens can expire or be revoked on the server-side.

You can ensure the token is still valid with the use of getCurrentUser() method from earlier. This is optional, depending on your product requirements. If needed, you can protect routes with a token validation check before rendering portions of your application. This can prevent a potentially jarring experience of partial rendering UI that may be ejected due to an invalid token.

To validate a token for protecting a route, open the router.js file, import the ProtectedRoute module and replace the regular <Route path="todos"> with the new ProtectedRoute wrapper.

Let’s take a look at what this wrapper does. Open utilities/route.js file and focus just on the validateAccessToken function within the useEffect function. Currently, it’s just checking for the existence of the tokens with TokenStorage.get, which may be fine for some situations. We can optionally call the UserManager.getCurrentUser() method to ensure the stored tokens are still valid.

To do this, import UserManager into the file, and then replace TokenStorage.get with UserManager.getCurrentUser.

In the code above, we are reusing the getCurrentUser() method to validate the token. If it succeeds, we can be sure our token is valid and call setValid to 'valid' . If it fails, we know it is not valid and call setValid to 'invalid'. We set that outcome with our setValid() state method and the routing will know exactly where to redirect the user.

Revisit the browser and refresh the page. Navigate to the todos page. You will notice a quick spinner and text communicating that the app is "verifying access". Once the server responds, the Todos page renders. As you can see, the consequence of this is the protected route now has to wait for the server to respond, but the user’s access has been verified by the server.

Once the Todos page renders, notice how the todo collection has a persistent spinner to indicate the process of requesting todos. This is due to the fetch request not having the proper headers for making an authorized request, so the request does not succeed.

To make resource requests to a protected endpoint, we have an HttpClient module that provides a simple wrapper around the native fetch method of the browser. When you call the request() method, it will retrieve the user’s access token, and attach it as a Bearer Token to the request as an authorization header. This is what the resource server will use to make its own request to the ForgeRock server to validate the user’s access token.

Open utilities/request.js and import the HttpClient from the ForgeRock SDK. Then, replace the native fetch method with the HttpClient.request() method.

The init object in the above maps directly to the init options object seen in the official Request documentation in the Mozilla Web Docs. The interface of the response from the request also maps directly to the official Response object seen in the Mozilla Web Doc.

At this point, the user can log in, request access tokens, and access the page of the protected resources (todos). Now, revisit the browser and clear out all cookies, storage and cache. Keeping the developer tools open and on the network tab, log in with you test user. Once you have been redirected to the home page, do the following:

{% include full-image-with-caption.html imageurl="/images/community/build-reactjs-app/todos-page-successful-request.png" title="To-dos page with successful request" caption="Screenshot of successful request for to-dos with Network panel open" %}

Of course, you can’t have a protected app without providing the ability to log out. Luckily, this is a fairly easy task.

Open up the views/logout.js file and import the following:

Since logging out requires a network request, we need to wrap it in a useEffect and pass in a callback function with the following functionality:

Since we only want to call this method once, after the component mounts, we will pass in an empty array as a second argument for useEffect(). After FRUser.logout() completes, we just empty or falsify the global state to clean up and redirect back to the home page.

Once all the above is complete, return to your browser, empty the cache, storage and cache, and reload the page. You should now be able to log in with the test user, navigate to the todos page, add and edit some todos, and logout by clicking the profile icon in the top-right and clicking "Sign Out".

Congratulations, you just built a ForgeRock protected app with React JS.