Frontend · Backend

The Missing Piece in JWT Auth: Route Guards That Remember Where You Were Going

By 东风破_ · Aug 23, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Client-side route guards are the last link in a frontend auth chain. Without them, any user can manually type a URL and view protected UI shells even if API calls would fail. Pairing the guard with a redirect-back pattern eliminates the jarring experience of logging in only to land on the homepage instead of the page the user originally wanted.

Summary

A RequireAuth wrapper component sits between React Router and protected pages, checking Zustand's global token state before rendering anything. Without a token, it redirects to /login and passes the original path via location state. The login page reads that `from` value and, after a successful API call stores the token and user in Zustand and localStorage, navigates the user back to the page they originally requested. This closes the loop on a full JWT auth flow: login, state persistence, automatic Authorization headers via Axios interceptors, and now client-side page protection. The piece also distinguishes the responsibilities of the API layer, mock server, JWT signing/verification, Axios interceptors, Zustand store, localStorage, and route guards, framing the whole demo as a single coherent chain rather than isolated techniques.

Takeaways

— A RequireAuth component wraps children and checks for a token from Zustand; if absent, it renders <Navigate to="/login">.

— The guard passes the current path via location state so the login page knows where to redirect after success.

— Extracting the auth check into a single component avoids repeating `if (!token) navigate('/login')` in every protected page.

— On successful login, Zustand stores the token and user, localStorage persists the token across refreshes, and `navigate(from, { replace: true })` sends the user back to their original destination.

— The full auth chain runs: route guard check → login API call → mock JWT sign → token stored → Axios interceptor attaches token → mock JWT verify → protected data returned.

Conclusions

The article's value is in sequencing: it presents the route guard not as an isolated pattern but as the final step that makes the entire JWT flow feel complete to an end user.

Many tutorials stop at storing a token and attaching it to requests; adding the redirect-back behavior is a small detail that separates a demo from something that feels like a real application.

The final section explicitly names the 'why' behind each architectural choice (API layer, mock, Zustand, localStorage, interceptor, guard), which is a useful mental model for beginners who otherwise memorize APIs without understanding the division of labor.

Concepts & terms

Route Guard

A component that wraps protected routes and checks authentication state before rendering the target page. In React Router, it typically uses <Navigate> to redirect unauthenticated users to a login page.

Redirect-back pattern

Passing the originally requested URL (e.g., /pay) to the login page via router state, so that after successful authentication the user is navigated back to that URL instead of a default homepage.

Source: juejin.cn ↗ Google Translate ↗ Backup ↗