Who is logged in, and what are they allowed to do?

The UI knows who is logged in and what they can do. Gate views and actions by role, and be clear about where that check actually runs.

Store the token where script cannot reach it

A token in localStorage is readable by any script on the page. An httpOnly cookie is never exposed to JavaScript, so XSS (cross-site scripting) cannot steal it.

For my Next.js App Router app, should the auth token live in localStorage or an httpOnly cookie? Which one can an XSS script read, and what do I give up (e.g. reading the token in client code) by choosing the safer one?

Gate before the page renders

In Next.js App Router, the proxy file (middleware in older versions) runs before any page renders. Read the session cookie there and redirect unauthenticated requests. Server Components then check the role, so a user never downloads markup for a section they cannot access.

How do I redirect unauthenticated users in a Next.js App Router project before the page renders, using the proxy file (middleware in older versions) and a session cookie? Show a small code example.

Do not roll your own auth

Token storage, refresh, sessions, CSRF: each one is easy to get subtly wrong. When the Next.js side owns auth, reach for a library like Better Auth so you spend your time on roles and screens instead of reinventing login. When the backend owns auth (common on team projects), your job is to consume its tokens correctly, not build the flow.

For my project, does the Next.js app own authentication or does the backend? If I own it, would a library like Better Auth fit my stack at [describe it], and what would I still have to build myself?

Client checks are cosmetic

Hiding a button or disabling an action helps the UX, but that is all it does. A determined user opens devtools or hits the API directly. The real gate sits on the server.

For my action [action], if I only hide the button on the client, how would a determined user still trigger it, and where exactly does the server-side check have to live to stop them?

The real gate is on the server. Client-side checks only hide the UI.

Additional Resources

Explore these carefully curated resources to deepen your understanding and practice the concepts covered in this lesson.

MDN HTTP Authentication

Documentation

How HTTP authentication schemes work, including Bearer tokens and the Authorization header.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Authentication

Next.js proxy (formerly middleware)

Documentation

The proxy file runs before a request completes to redirect or rewrite based on auth state; it was called middleware before Next.js 16.

https://nextjs.org/docs/app/api-reference/file-conventions/proxy

Next.js: Authentication

Documentation

How authentication, sessions, and authorization fit together in a Next.js app.

https://nextjs.org/docs/pages/guides/authentication

Better Auth

Documentation

A framework-agnostic TypeScript auth library that handles sessions, cookies, and providers so you do not roll your own.

https://www.better-auth.com

PreviousNext