Clerk Authentication in Next.js App Router — Complete Setup Guide
Add Clerk Auth to a Next.js App Router project with middleware route protection, server-side sessions, and custom user profile sync.
Clerk handles the hard parts of authentication — sessions, MFA, social login, user management UI — but wiring it into the Next.js App Router correctly still requires understanding where middleware, Server Components, and webhooks each fit. This guide covers the full setup: middleware route protection, reading sessions on the server, and syncing users into your own database.
Step 1: Install and Configure Clerk
Wrap the root layout in ClerkProvider — this is what makes both server and client Clerk APIs work throughout your app.
Step 2: Protect Routes with Middleware
clerkMiddleware() runs before your routes render, attaching auth state to the request and optionally enforcing protection.
createRouteMatcher lets you declare protected paths as a pattern instead of manually parsing req.nextUrl.pathname — anything matching /dashboard(.*) or /settings(.*) requires a signed-in user, and auth.protect() redirects unauthenticated requests automatically.
Step 3: Read the Session in Server Components
No client-side loading state or fetch is needed — auth() and currentUser() resolve during the server render itself, since middleware already attached the session before the request reached this component.
Step 4: Add Sign In / Sign Up Pages
Clerk ships prebuilt components that handle the entire auth UI.
The catch-all route segment ([[...sign-in]]) is required — Clerk's components internally handle sub-routes like password reset and email verification.
Step 5: Sync Users to Your Own Database with Webhooks
Your application's business data almost always needs its own database row per user, keyed by the Clerk user ID. Don't query Clerk's API on every request to check if a user exists — sync via webhooks instead.
Verifying the payload with svix (Clerk's webhook provider) is mandatory — without it, anyone could POST a fake user.created event to your endpoint and create arbitrary database rows.
Step 6: Use Clerk User IDs as Your Foreign Key
Once synced, every business-data table references the Clerk user ID (via your own User.clerkId field), so authorization checks stay simple:
Key Takeaways
clerkMiddleware() combined with createRouteMatcher handles route protection before any page logic runs, auth()/currentUser() give you session data directly inside Server Components with no client round-trip, and webhooks — not polling — are the correct way to keep your own database in sync with Clerk's user records.
