An open lobby, a keycard for the upstairs floors, and a guard who actually checks.

Public vs private pages

Every screen falls into one of two buckets. Getting this split right before you write guards saves a lot of pain.

The golden rule: client hides, server enforces

This is the single most important idea, and the one juniors miss. Any check that runs in the browser or the app can be bypassed. A user can edit JS in dev tools, call your API directly with curl, or root their phone. So front-end guards are UX, not security.

React (SPA) — guard with a wrapper component

In a plain React SPA, routing happens in the browser. You protect a route by wrapping it in a component that checks auth and either renders the page or redirects.

// ProtectedRoute.jsx — the elevator guard
function ProtectedRoute({ children }) {
  const { user, loading } = useAuth();

  if (loading) return <Spinner />;          // don't flash either way yet
  if (!user) return <Navigate to="/login" replace />;
  return children;
}

// usage in the router
<Route path="/dashboard" element={
  <ProtectedRoute><Dashboard /></ProtectedRoute>
} />

For role-based routes, pass an allowed-roles list and redirect to a "403 / not allowed" page when the role doesn't match — that's authorization on top of authentication.

Next.js — guard on the server, before the page renders

Next.js can check auth before a single byte of the page reaches the browser — a real advantage over a pure SPA. There are two main spots:

// middleware.ts — gate a whole section before render
export function middleware(req) {
  const token = req.cookies.get("session")?.value;
  if (!token) {
    return NextResponse.redirect(new URL("/login", req.url));
  }
  return NextResponse.next();
}
export const config = { matcher: ["/dashboard/:path*", "/settings/:path*"] };

React Native — guard by swapping navigators

Mobile doesn't have URLs to intercept, so the pattern is different and actually cleaner: you render a different navigator depending on auth state. No "protected screen" can exist in the tree when the user is logged out.

// App navigation — two separate stacks
function Routes() {
  const { user, loading } = useAuth();

  if (loading) return <Splash />;            // while reading secure storage
  return user
    ? <AppStack />      // dashboard, profile, settings
    : <AuthStack />;    // login, signup, forgot-password
}

Every layer of protection at once

Real protection is layered. The client guard is the outer convenience; the server is the inner truth. Read the arrows top-to-bottom: the request passes (or fails) the client guard, then independently passes (or fails) the server check.

Read it as a sentence: sort routes into public and private → guard private ones on the client for UX → redirect the unauthenticated to login and the unauthorized to 403 → and re-check auth on the server for every request, because the client guard can always be bypassed. That single sentence is the entire model.

Every way to guard, side by side

The same job — "don't let the wrong person see this" — has a platform-shaped answer. Here's the menu.