在 Next.js App Router 应用程序中，如何处理身份验证？

Question

Accepted Answer

App Router 中的身份验证跨越多个层次——session、middleware、服务器端检查和保护 Server Actions。现代方法倾向于使用**服务器端 session 验证**而不是仅客户端检查。 ## Session 策略 ```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. 在 middleware 中进行粗粒度防护（快速，但不是全部） ```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 在每个匹配的请求之前在 Edge 上运行——非常适合廉价的重定向。但它应该只进行*轻量级*的存在性检查；不要将其作为唯一的授权依赖（cookie 可能无效）。 ## 2. 在使用数据的地方验证 session（真正的防护） ```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}

; } ``` 这个服务器端验证（在 Server Component 中）是**权威性**检查——它实际验证 session 并加载用户。 ## 3. 也要保护 Server Actions 和 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 是公开端点——**总是在其中重新检查 auth 和 authorization**，无论 UI 级别的防护如何。 ## 为什么要分层检查 ```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 ``` ## 为什么这很重要 App Router 中的身份验证是纵深防御：httpOnly cookies（XSS 安全的 session）、用于快速重定向的 middleware，以及——至关重要的——**在每个数据访问和变更点进行服务器端验证**。常见且危险的错误是将 middleware 检查或隐藏的客户端 UI 视为充分保护；真正的保护来自于在服务器上验证 session 和授权，无论何时读取或更改敏感数据。