Jak obsługujesz uwierzytelnianie w aplikacji Next.js App Router?

Question

Accepted Answer

Uwierzytelnianie w App Router obejmuje kilka warstw — sesje, middleware, kontrole po stronie serwera i ochronę Server Actions. Nowoczesne podejście faworyzuje **weryfikację sesji po stronie serwera** w stosunku do kontroli tylko po stronie klienta. ## Strategia sesji ```text Cookie-based sessions (httpOnly cookie): ✓ Store a signed session id or encrypted JWT in an httpOnly, secure cookie ✓ httpOnly = not readable by JavaScript → protects against XSS token theft ✓ Use a library: Auth.js (NextAuth), Clerk, Lucia, or a custom solution ``` ## 1. Gruba bramka w middleware (szybko, ale nie całą historię) ```ts // middleware.ts — quick check: does a session cookie exist? export function middleware(req: NextRequest) { const session = req.cookies.get("session")?.value; if (req.nextUrl.pathname.startsWith("/dashboard") && !session) { return NextResponse.redirect(new URL("/login", req.url)); } return NextResponse.next(); } ``` Middleware działa na Edge przed każdym dopasowanym żądaniem — idealne do tańskich przekierowań. Ale powinno wykonywać tylko *lekką* kontrolę obecności; nie polegaj na niej jako jedynym autoryzacji (plik cookie może być nieprawidłowy). ## 2. Weryfikuj sesję tam, gdzie używasz danych (rzeczywista bramka) ```tsx // app/dashboard/page.tsx — verify on the server, in the page itself import { redirect } from "next/navigation"; export default async function Dashboard() { const user = await getCurrentUser(); // validates the session cookie server-side if (!user) redirect("/login"); // authoritative check return

Welcome {user.name}

; } ``` Ta weryfikacja po stronie serwera (w Server Component) jest **autorytatywną** kontrolą — faktycznie sprawdza sesję i ładuje użytkownika. ## 3. Chroń również Server Actions i Route Handlers ```tsx "use server"; export async function deletePost(id: string) { const user = await getCurrentUser(); if (!user) throw new Error("Unauthorized"); // never trust the caller if (post.authorId !== user.id) throw new Error("Forbidden"); // authorization await db.post.delete({ where: { id } }); } ``` Server Actions to publiczne punkty końcowe — **zawsze ponownie sprawdzaj uwierzytelnianie i autoryzację wewnątrz nich**, niezależnie od bramowania na poziomie interfejsu użytkownika. ## Dlaczego warstwowe kontrole ```text Middleware → fast redirect for the common case (better UX, not security-critical) Server Component/Action → real verification (security boundary) Never rely on hiding UI in the client as a security measure ``` ## Dlaczego to ważne Auth w App Router to obrona w głąb: pliki cookie httpOnly (sesje bezpieczne przed XSS), middleware do szybkich przekierowań i — co kluczowe — **weryfikacja po stronie serwera w każdym punkcie dostępu do danych i mutacji**. Zawsze popełniany, niebezpieczny błąd to traktowanie kontroli middleware lub ukrytego interfejsu użytkownika klienta jako wystarczającego; rzeczywista ochrona pochodzi z weryfikacji sesji i autoryzacji na serwerze, gdziekolwiek czytane lub zmieniane są wrażliwe dane.