Centralized authentication & authorization in layout loaders (v6)

[functasti]

I'm working with React Router v6.30.1 (createBrowserRouter) and would like to centralize authentication and authorization logic at the layout level, rather than duplicating it across each route’s loader.

My goal is to restrict access to certain parts of the URL hierarchy (e.g., the /admin section). Since parent loaders are always called before child loaders, I’m considering this approach:

<Route path="admin" element={<AdminLayout />} loader={authNLoader}>
  <Route index element={<SectionA />} loader={aDataLoader} />  
  <Route path="b" element={<SectionB />} loader={bDataLoader} />
  <Route path="b/:id" element={<ItemB />} loader={bItemsDataLoader} />
  
  <Route path="c" element={<SectionCLayout />} loader={authZLoader}>    
    <Route path="c1" element={<SubSectionC1 />} loader={c1DataLoader} />    
    <Route path="c2" element={<SubSectionC2 />} loader={c2DataLoader} />
    <Route path="c3" element={<SubSectionC3 />} loader={c3DataLoader} />    
  </Route>
</Route>

-authNLoader at the /admin level checks if the user is authenticated.
-authZLoader under /admin/c checks for more specific permissions.
-Leaf routes like /admin/b/:id or /admin/c/c1 just focus on data fetching.

Is this a recommended pattern in React Router 6? Are there any caveats or edge cases I should be aware of when centralizing authentication and authorization in layout loaders like this?

Thanks!

[sergiodxa]

Since parent loaders are always called before child loaders

This is wrong, parent and child loaders are all called in parallel

You need to add authorization to every loader as you don't know which will will resolve it faster.

[nickkfwong]

@functasti Thank you for your explanation too!

A follow up question is - If I choose to use middleware and do authentication there, is the same concept apply?
Especially, does the middleware run at both the parent route, and on the child route independently?

For example, in this repo foxlau/react-router-v7-better-auth

The auth is performed at middleware level auth-guard.server.ts

... which then set the context or redirect

export const authMiddleware: unstable_MiddlewareFunction = async (
  { request, context },
  next,
) => {
  const authSession = await getAuthSession(request);

  if (!authSession) {
    throw redirect("/auth/sign-in");
  }

  context.set(authSessionContext, authSession);

  return await next();
};

Since in routes/layout.tsx middleware is used and therefore we can expect unauthorized user must be redirected away already so we can happily focus on the auth data contained by the context.

export const unstable_middleware = [authMiddleware];

export async function loader({ context }: Route.LoaderArgs) {
  const authSession = context.get(authSessionContext);
  return data(authSession);
}

But in the protected child routes, such as routes/todos.tsx, I can't see anything related to the middleware or authentication? ...Is that expected or not?

export async function loader(_: Route.LoaderArgs) {
  const todos = await db.query.todo.findMany({
    orderBy: (todo, { desc }) => [desc(todo.createdAt)],
  });
  return data({ todos });
}

If the same concept applies, should I expect we need the middleware to run once in both the layout (parent) and child routes where the auth inside the middleware will run independently?
... or ... if we export middleware at parent route level, does it automatically apply to its child routes - such that the todos route indeed have the middleware run along with it?
(Likely im missing key conceptual understanding about the middleware...)

...sorry for long question, many thanks for your time!

[sergiodxa]

A follow up question is - If I choose to use middleware and do authentication there, is the same concept apply?
Especially, does the middleware run at both the parent route, and on the child route independently?

A middleware runs once per request, and it will run for any route and its children routes. So a middleware in a layout will run also for the routes nested inside that layout.

Since it runs once per request it means in many times the middleware will run once and then all routes (where it was defined and the parents) will run, but if RR for some reason only runs one route loader, it will run the middleware too.

That said, use middleware for authentication, but keep authorization in the route loaders. The middleware is a good place to check if the user is authenticated, but the route loaders are where you should check if the user is authorized to access that specific route.

[nickkfwong]

@sergiodxa I think Im much much comfortable than before and get a good understand what to use now for the described scenario. Thank you a lot!

If you don't mind for one more question about the internal - I'm curious, in the case where middleware is defined(exported) at layout route or a parent route level, then does it mean the loading of parent route and its child routes need to be somehow "ordered"?

Asking this since we talked about in the basic case child routes can be loaded independently of the layout - but if that is the case, how would the child route knows that there are some middlewares defined at its parent layout level? ... or is there some magic happen that makes the child route beware of the things defined at parent?

[sergiodxa]

Middleware functions run in order, loaders still run in parallel but after the every middleware has run.

[nickkfwong]

@sergiodxa understood, big thanks again for the detailed explanation!