A protected component or route only displays its protected content when the application's authentication state satisfies the required condition. A protected component is useful for user experience, but it should never be treated as the actual security boundary. The backend must still protect the corresponding data and operations. ### Simple Protected Component ```jsx function RequireAuth({ children }) { const { user, status } = useAuth(); if (status === "checking") { return

Checking session...

; } if (!user) { return ; } return children; } ``` Usage: ```jsx ``` Conceptually: ```text RequireAuth ↓ checking session? ↓ yes → loading UI no ↓ authenticated? / \ yes no ↓ ↓ content login UI ``` ### Why the Checking State Matters This implementation is problematic: ```jsx if (!user) { return ; } ``` if the application has not finished checking the existing session yet. The user could briefly see: ```text Login page ``` before [React](/courses/reactjs) discovers that they are already authenticated. A better auth state distinguishes: ```text checking unauthenticated authenticated ``` ### Protected Routes with React Router A route guard can render an `Outlet` when the user is authenticated: ```jsx import { Navigate, Outlet } from "react-router"; function ProtectedRoute() { const { user, status } = useAuth(); if (status === "checking") { return

; } if (!user) { return ( ); } return ; } ``` Routes can then be grouped conceptually as: ```jsx }> } /> } /> ``` ### Preserve the Intended Destination When Useful Suppose an unauthenticated user opens: ```text /orders/123 ``` After login, a good experience may return them to that page rather than always sending them to the homepage. Conceptually: ```text Protected URL requested ↓ save intended destination ↓ redirect to login ↓ login succeeds ↓ return to intended URL ``` The exact implementation depends on the router and authentication architecture. ### Protected Component vs Protected API These solve different problems: ```text Protected React component → should this UI be shown? Protected API endpoint → is this request actually allowed? ``` Never assume this is sufficient security: ```jsx if (!user) { return null; } ``` If the API endpoint itself accepts unauthorized requests, the application remains insecure. ### Do Not Fetch Protected Data Before Auth State Is Ready If authentication is still being checked, avoid unnecessary protected requests that will immediately fail with 401. A useful flow is: ```text Check session ↓ authenticated ↓ request protected data ``` ### Related Questions to Learn More ```text React Router and Navigation → How Do You Create Protected Routes in React Router? Context API → How Does useContext Work in React? Provider Pattern → What Is the Provider Pattern in React and When Should You Use It? React API Integration → How Do You Make Authenticated API Requests in React? ``` The router-specific protected-route implementation is covered more deeply in the dedicated [React Router](/courses/reactjs) category; this question focuses on how route protection fits into authentication architecture. ### Interview-Ready Answer Protected [React](/courses/reactjs) components and routes check authentication state before displaying private UI. A good implementation distinguishes session checking from unauthenticated state, can redirect unauthenticated users to login, and may preserve their intended destination. Protected routes improve UX but are not security boundaries; backend endpoints must independently require authentication and authorization.