Como você gerencia autenticação em um aplicativo Next.js App Router?

Question

Accepted Answer

A autenticação no App Router abrange várias camadas — sessões, middleware, verificações do lado do servidor e proteção de Server Actions. A abordagem moderna favorece **verificação de sessão do lado do servidor** em relação a verificações apenas do cliente. ## Estratégia de sessão ```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. Controle grosseiro no middleware (rápido, mas não é toda a história) ```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(); } ``` O middleware é executado no Edge antes de cada solicitação correspondente — ideal para redirecionamentos baratos. Mas deve apenas fazer uma verificação de presença *leve*; não confie apenas nele para autorização (o cookie pode ser inválido). ## 2. Verifique a sessão onde você usa os dados (o portão real) ```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}

; } ``` Esta verificação do lado do servidor (no Server Component) é a verificação **autoritária** — ela realmente valida a sessão e carrega o usuário. ## 3. Proteja também Server Actions e 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 são pontos finais públicos — **sempre reverifi que auth e autorização dentro deles**, independentemente do controle no nível da UI. ## Por que verificações em camadas ```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 ``` ## Por que isso importa Auth no App Router é defesa em profundidade: cookies httpOnly (sessões seguras contra XSS), middleware para redirecionamentos rápidos e — crucialmente — **verificação do lado do servidor em cada ponto de acesso e mutação de dados**. O erro comum e perigoso é tratar uma verificação de middleware ou uma UI de cliente oculta como suficiente; a proteção real vem da validação da sessão e autorização no servidor sempre que dados confidenciais são lidos ou alterados.