Authentication Patterns in the App Router

The plain-language idea

"Add auth" actually names three separate jobs, and the App Router has a specific, correct place for each:

1. Route protection — deciding whether a request is even allowed to reach a page at all. This belongs in proxy.ts (this project's proxy/middleware entry point), because it runs before any page component renders, on every matching request, and it's the one place that can redirect before any server work happens.
2. Reading who's signed in — a Server Component that needs to know the current user to render correctly (show their name, gate a section of the page). This reads the session directly, in the component, via a server Supabase client.
3. Actually signing someone in — a mutation: verifying a password, creating a session, setting cookies. This is a Server Action, because it's a write, and Server Actions are the App Router's mechanism for writes triggered from a form.

Mixing these up is the actual bug pattern worth knowing. Putting the redirect check inside a page component instead of middleware means the check only fires if that specific component happens to run it — a sibling page, or a nested layout, can accidentally skip it entirely. This project's own gating makes the point concretely: PROTECTED_PREFIXES in lib/supabase/middleware.ts is the actual source of truth for which routes require auth, not anything inside app/learn/[track]/[lesson]/page.tsx — reading that page's source in isolation shows no redirect() call at all, which would wrongly suggest the route is public.

See it in a real thing: three files, three jobs

// lib/supabase/middleware.ts — job 1: route protection, runs before any page renders
const PROTECTED_PREFIXES = ["/learn", "/dashboard", "/interview", "/genealogy", "/settings"];

export async function updateSession(request: NextRequest) {
  const supabase = createServerClient(/* ...cookie handling... */);
  const { data: { user } } = await supabase.auth.getUser(); // revalidates against Supabase, not just a local cookie read

  if (!user && isProtectedPath(request.nextUrl.pathname)) {
    const url = request.nextUrl.clone();
    url.pathname = "/login";
    url.searchParams.set("next", request.nextUrl.pathname);
    return NextResponse.redirect(url);
  }
  return supabaseResponse;
}

// app/dashboard/page.tsx — job 2: a Server Component reading who's signed in
import { createClient } from "@/lib/supabase/server";

export default async function DashboardPage() {
  const supabase = await createClient();
  const { data: { user } } = await supabase.auth.getUser();
  // middleware already guarantees `user` exists here for this route —
  // this read is for rendering personalized content, not for gating access
  return <h1>Welcome back, {user?.email}</h1>;
}

// app/(auth)/actions.ts — job 3: a Server Action, the actual sign-in mutation
"use server";
export async function login(_prev: AuthActionState, formData: FormData) {
  const supabase = await createClient();
  const { error } = await supabase.auth.signInWithPassword({
    email: String(formData.get("email")),
    password: String(formData.get("password")),
  });
  if (error) return { error: error.message };
  redirect("/dashboard");
}

Notice getUser() appears in both job 1 and job 2, but for different reasons: middleware calls it to decide whether the request may proceed at all; the dashboard page calls it again to read which user, for rendering — the second call isn't redundant paranoia, it's a completely different question being asked in a completely different place. getUser(), not getSession(), matters in both spots — getSession() only reads the (possibly stale) local cookie, while getUser() revalidates the token against Supabase Auth itself.

What people usually miss

Watch out

• A page.tsx with no visible redirect() doesn't mean the route is public. If gating is centralized in middleware, reading page source alone misses it entirely — the only reliable way to verify a route's real auth status is an actual unauthenticated request (checking for a redirect status code), not a code read.
• Middleware runs on every matching request, including ones that never render a React component — a direct API hit, a prefetch, a bot. Route protection has to live somewhere that sees all of those, which a page component fundamentally can't, since it only runs once Next.js has already decided to render it.
• A Server Component reading the session and middleware enforcing access are not redundant with each other, and dropping either one creates a real gap. Middleware without a page-level session read means the page can't personalize anything; a page-level read without middleware means a sufficiently fast prefetch or React Server Component request could theoretically render before the redirect logic (implementation-dependent, and not a bet worth making) — the split exists because each does a job the other structurally can't.
• Server Actions used for mutations need their own authorization check, separate from route protection. A Server Action can be invoked directly (not just via the form it's wired to), so a mutation that changes another user's data needs to verify the acting user owns that data inside the action itself — route-level gating only proved the request reached an allowed page, not that a specific action call is allowed to do what it's about to do.
• getSession() vs getUser() is not a stylistic choice. getSession() trusts whatever's in the cookie without checking it's still valid; getUser() makes a real round trip to Supabase to confirm the token hasn't been revoked. Using getSession() in a security-relevant check (as opposed to just reading cached user info you already trust) is a real, exploitable gap, not just a slower-vs-faster tradeoff.

The genealogy: proxy.ts is the App Router's answer to "where do I intercept a request"

This builds on the proxy-and-request-interception lesson's general mechanics — what proxy.ts can and can't do, and when it runs relative to routing. Auth gating is simply the single most common reason a real app reaches for that mechanism at all, which is why this project's own middleware file is the concrete example here rather than a synthetic one.