DEV Community

JWT Authentication in React with react-router

Sanjay Arya on May 28, 2023

In this blog post, we'll explore the seamless integration of JWT authentication with React and react-router. We'll also learn how to handle public ...

Read full post

crayoncode • May 31 '23

Please keep in mind the implications of storing secrets such as access tokens (e.g. a JWT) in localStorage. Browser storage such as localStorage or sessionStorage do not provide sufficient isolation against e.g. XSS attacks and the secrets kept in localStorage can easily be exposed by malicious code.

Further reading:
auth0.com/blog/secure-browser-stor...
snyk.io/blog/is-localstorage-safe-...

Sanjay Arya • May 31 '23

Thank you for raising this important concern. You're absolutely right that storing access tokens or any sensitive information in localStorage can pose security risks, especially in the context of XSS attacks. It's crucial to consider these implications and take necessary precautions.

One alternative approach to mitigate such risks is to use techniques like HttpOnly cookies or secure authentication mechanisms. By employing secure storage methods and implementing best practices, we can enhance the overall security of our applications.

I appreciate your valuable input and the reminder to prioritize security in handling sensitive data.

Camilo Martinez • May 30 '23 • Edited

Exellent article, well described and organized, easy to follow.

I didn't understand something on the router. It defines two "/" routes to main, but how it know which one use?
I didn't catch how the router detects when to use the public and the authorized one.

Sanjay Arya • May 31 '23 • Edited

Thank you for your kind words! I'm glad you found the article helpful.

In React Router, the routes are processed in the order they are declared. This means that the first matching route will be rendered.

When a user navigates to a specific route, React Router will check the routes in the order they are defined. If a route's path matches the current URL, React Router will render the corresponding element.

When the user is authenticated (has a token), the routesForNotAuthenticatedOnly is excluded from the route configuration. Therefore, only the routes from routesForPublic and routesForAuthenticatedOnly will be considered. If the path matches "/", React Router will render the <ProtectedRoute /> component, which leads to the "User Home Page" component being displayed.

On the other hand, when the user is not authenticated (no token), the routesForNotAuthenticatedOnly routes are included. In this case, if the path matches "/", React Router will render the "Home Page" component from routesForNotAuthenticatedOnly, because it is declared before the routes from routesForAuthenticatedOnly.

  // Combine and conditionally include routes based on authentication status
  const router = createBrowserRouter([
    ...routesForPublic,
    ...(!token ? routesForNotAuthenticatedOnly : []),
    ...routesForAuthenticatedOnly,
  ]);

The order of route declaration is significant. React Router processes the routes in the order they are defined, and the first matching route is rendered. In this scenario, since the path "/" matches the first route in routesForNotAuthenticatedOnly, that route's corresponding component will be rendered.

So, to clarify, when the user is not authenticated, the "Home Page" component from routesForNotAuthenticatedOnly will be rendered when the path matches "/", as it is declared before the routes from routesForAuthenticatedOnly.

By conditionally including different route configurations based on the authentication status, you can control which routes are available to the user and which components are rendered for different scenarios.

Camilo Martinez • May 31 '23

That was a Mega explanation!
All clear, thanks!

KevinOsorioCodes • May 31 '23

Hi, very good article, but I think it is more maintainable if we use useContext with useReducer for these cases, in this way we handle possible predefined state changes and we don't let them change in any way through the code. this way we can have a useAuthStateContext and a useAuthDispatchContext to make it more maintainable and even easier to use. greetings and congratulations!

Sanjay Arya • May 31 '23

Thank you for your feedback and congratulations! I appreciate your input and agree that using useContext with useReducer can offer better maintainability for handling state changes.

In my projects, I often utilize the combination of useContext and useReducer for managing authentication state. However,
for the purpose of this article, I have chosen to simplify the implementation and use useState.

Here is the updated version of the AuthProvider component that implements the reducer pattern:

import axios from "axios";
import { createContext, useContext, useMemo, useReducer } from "react";

// Create the authentication context
const AuthContext = createContext();

// Define the possible actions for the authReducer
const ACTIONS = {
  setToken: "setToken",
  clearToken: "clearToken",
};

// Reducer function to handle authentication state changes
const authReducer = (state, action) => {
  switch (action.type) {
    case ACTIONS.setToken:
      // Set the authentication token in axios headers and local storage
      axios.defaults.headers.common["Authorization"] = "Bearer " + action.payload;
      localStorage.setItem("token", action.payload);

      // Update the state with the new token
      return { ...state, token: action.payload };

    case ACTIONS.clearToken:
      // Clear the authentication token from axios headers and local storage
      delete axios.defaults.headers.common["Authorization"];
      localStorage.removeItem("token");

      // Update the state by removing the token
      return { ...state, token: null };

    // Handle other actions (if any)

    default:
      console.error(
        `You passed an action.type: ${action.type} which doesn't exist`
      );
  }
};

// Initial state for the authentication context
const initialData = {
  token: localStorage.getItem("token"),
};

// AuthProvider component to provide the authentication context to children
const AuthProvider = ({ children }) => {
  // Use reducer to manage the authentication state
  const [state, dispatch] = useReducer(authReducer, initialData);

  // Function to set the authentication token
  const setToken = (newToken) => {
    // Dispatch the setToken action to update the state
    dispatch({ type: ACTIONS.setToken, payload: newToken });
  };

  // Function to clear the authentication token
  const clearToken = () => {
    // Dispatch the clearToken action to update the state
    dispatch({ type: ACTIONS.clearToken });
  };

  // Memoized value of the authentication context
  const contextValue = useMemo(
    () => ({
      ...state,
      setToken,
      clearToken,
    }),
    [state]
  );

  // Provide the authentication context to the children components
  return (
    <AuthContext.Provider value={contextValue}>{children}</AuthContext.Provider>
  );
};

// Custom hook to easily access the authentication context
export const useAuth = () => {
  return useContext(AuthContext);
};

export default AuthProvider;

And here is the updated version of the Logout component that utilizes the clearToken function from the useAuth hook:

import { useNavigate } from "react-router-dom";
import { useAuth } from "../provider/authProvider";

const Logout = () => {
  const { clearToken } = useAuth();
  const navigate = useNavigate();

  // Function to handle logout
  const handleLogout = () => {
    clearToken(); // Clear the authentication token
    navigate("/", { replace: true }); // Navigate to the home page ("/") with replace option set to true
  };

  // Automatically logout after 3 seconds
  setTimeout(() => {
    handleLogout(); // Invoke the logout action
  }, 3 * 1000);

  return <>Logout Page</>;
};

export default Logout;

Again thank you for sharing your thoughts. I appreciate your support!

WADIGZON DIAZ-WONG • Jun 1 '23

Good stuff Sanjay, thanks for sharing,
just a little clarification about file name:
authProvider.js is really authProvider.jsx

if you use .js you will get the following/similar error:

The esbuild loader for this file is currently set to "js" but it must be set to "jsx" to be able to parse JSX syntax. You can use "loader: { '.js': 'jsx' }" to do that.

Of course you have the right file name in the source code. :-)

Victor Kasap • Jun 1 '23

Good post, thank you 🙏
What do you think instead of using Context API, using Effector or Zustand?

What if backend sends you an HTTP cookie (JWT), that JWT includes time of creation and time expiration. This is jus first part of the full token, with the second part stored on the server. You only need to check expiration time of the token.

Sanjay Arya • Jun 2 '23

Thank you for your kind words! When it comes to alternative state management solutions, libraries like Effector or Zustand can offer different approaches compared to the Context API. While I haven't personally worked with Effector and Zustand, I do plan on exploring them in the future. However, I can share that Redux Toolkit is a widely adopted and powerful state management solution that I intend to cover in an upcoming article.

Regarding JWT tokens with time of creation and expiration, it is a common practice in authentication. If the backend sends the JWT as an HTTP cookie, you can extract relevant information such as the expiration time from the token and store it on the client-side. By checking the expiration time, you can determine the token's validity. If the token has expired, you may need to handle token renewal or reauthentication based on your application's requirements.

Tapan Sharma • May 30 '23

Hi,
Why do we need to create ? Why not simply do the following:
const router = createBrowserRouter([
...routesForPublic,
...(!token ? routesForNotAuthenticatedOnly : []),
...(token ? routesForAuthenticatedOnly : [] ),
]);
We check the token here in createBrowerRouter itself. This is easier and much more maintainable.

Sanjay Arya • May 30 '23

For the routesForNotAuthenticatedOnly, the logic is as follows:

If the user is not authenticated (token is falsy), the routesForNotAuthenticatedOnly array will be included in the routes configuration.
If the user is authenticated (token is truthy), an empty array [] will be included instead, effectively excluding the routesForNotAuthenticatedOnly from the routes configuration.
This logic is achieved using the conditional operator (!token ? routesForNotAuthenticatedOnly : []).

For the routesForAuthenticatedOnly, the logic is as follows:

The routes are always included in the routes configuration.
However, when a user visits any of the protected routes (e.g., /, /profile, etc.), the ProtectedRoute component is responsible for checking if the user is authenticated.
If the user is not authenticated (token is falsy), they will be redirected to the /login route using the Navigate component from react-router-dom.
This redirection ensures that only authenticated users can access the protected routes.
The logic for this redirection is implemented within the ProtectedRoute component, where it checks if the user is authenticated and handles the redirection accordingly.

Overall, these mechanisms ensure that the appropriate routes are accessible based on the user's authentication status. If the user is not authenticated, they can access the routesForNotAuthenticatedOnly, and if they are authenticated, they can access the routesForAuthenticatedOnly with the added protection of the ProtectedRoute component redirecting them to the login page if needed.

Eagering Dev • Jun 1 '23

Great Article.
Newly learned this function.
createBrowserRouter

Paul Dumebi • May 31 '23

Great Article

Okoro chimezie bright • Jun 1 '23

Thanks for sharing what a great stuff easy to follow.

React Hunter • May 31 '23

Great!
It described in good order and refined explanations.

Bernardo Guerreiro • Mar 7

Wish I could send this to every programmer that had the same struggles that I did, not only did you gave a perfect explanation on handling the token but also routes.
Great job and thank you.

Prince Muel • Jun 5 '23

This article was amazing. I'm using the createBrowserRoutesFromElements function, but it seems I'll change that.
A question I have for you is, how would someone handle refresh tokens using this setup? Thanks

vidhanshu borade • Feb 29 • Edited

But if we decide whether user is authenticated or not, just on the basis of existence of token, is it okay? won't if user manually add some garbage into the localStorage via inspecting, will let him sign in?
Is there any solution for this?
one solution I think, we can verify the validity of jwt in frontend, ig?

Thaw Htin Aung • Oct 2 '23

If I change
const routesForNotAuthenticatedOnly = [
{
path: "/",
element:,
},
];
to that,this exception occurs "Objects are not valid as a React child (found: [object RegExp]). If you meant to render a collection of children, use an array instead."

Sanjay Arya • Oct 3 '23 • Edited

You need to provide the element you want to render when a path is visited.

const routesForNotAuthenticatedOnly = [ { path: "/", element: 'NEED_TO_PROVIDE_COMPONENT_HERE', }, ];

Denys Vuika • Sep 12 '23

While the article features JWT in the title (a clickbait apparently), there is no JTW in the content or github example, besides setToken("this is a test token");

vehibip225@glalen.com • Nov 14 '23

how can i handle nested route.
currently at / i have component

and inside i have structure of login page like in Login compo i divided page in two half one half has image and in second half based on route i render either login or sign up . so fo that i have two route set up . at / i have and at at /sign-in i have

with your auth set up this is not working.