Authentication & Authorization in Next.js

Authentication and authorization are the gatekeepers of any real-world application. In Next.js, the decision of where to run auth logic — inside a Server Component, in middleware, or on the client — directly affects security, performance, and user experience. With the App Router and React Server Components, the safest place to check identity is on the server, where secrets never reach the browser and sessions can be verified before rendering starts.

Next.js does not ship with a built-in auth system. Instead, you compose one from primitives: the request/response objects in route handlers, the server-side cookies available in Server Components, middleware for lightweight route guards, and Server Actions for form submissions. Third-party libraries such as Auth.js and Clerk provide the actual identity plumbing, while Next.js provides the runtime and routing layer that wires them together.

This guide covers Auth.js v5 with the Next.js App Router, Clerk integration, route protection with middleware and role-based access, securing Server Actions, and choosing between JWT and database session strategies. The goal is a production-grade mental model: keep secrets on the server, verify every request, and minimize the attack surface of your application.

Authenticationis the process of proving who you are. It answers the question: "Is this user really who they claim to be?" Common mechanisms include passwords, OAuth providers, magic links, and WebAuthn. The output of authentication is usually a session or token that the application can verify on subsequent requests.

Authorizationhappens after authentication. It answers: "What is this user allowed to do?" Authorization is where you enforce roles, permissions, ownership, and quotas. A user may be authenticated but not authorized to view an admin dashboard. Confusing the two is a common source of security bugs: proving identity does not grant permission.

Auth.js v5, still often referred to as NextAuth, is the open-source authentication library for the web. It supports credentials, OAuth, email magic links, and passkeys. For Next.js 16 and the App Router, you install the next-auth package, create an auth.ts configuration file, and expose a catch-all route handler under /app/api/auth/[...nextauth]/route.ts.

Start with environment variables. Auth.js requires a AUTH_SECRET for token signing and session encryption. You can generate one with npx auth secret. OAuth providers need their client ID and client secret, and you should configure their callback URLs to point to /api/auth/callback/<provider>.

The central configuration lives in auth.ts. This file defines providers, session strategy, callbacks, and database adapter. In the App Router, you import the auth helper from this file to read the session in Server Components, and use SessionProvider in a client wrapper when you need session state on the client.

Expose the Auth.js HTTP API through a catch-all route handler. This single handler accepts sign-in, sign-out, callback, and session requests. The GET and POST methods are both delegated to the handlers exported from auth.ts.

Server Components can read the session directly with the auth helper. There is no need to wrap the app in a provider, which keeps the root layout server-rendered and avoids sending session data to the client unnecessarily.

If you need session data on the client, for example to conditionally show UI after hydration, create a client component with the SessionProvider and use the useSession hook. Keep the provider as low in the tree as possible so that only the components that actually need it are wrapped.

Clerk is a managed authentication platform that provides user management, organizations, roles, and UI components out of the box. It is a strong alternative to Auth.js when you want dashboards, user impersonation, and multi-organization support without building the backend infrastructure yourself.

Install the Clerk SDK, add your keys to .env.local, and wrap the root layout with ClerkProvider. Clerk uses its own middleware to manage session state, so you will also need a middleware.ts file at the project root.

Clerk exposes an auth() helper for Server Components and route handlers. It returns an object with the user ID, session claims, and organization information. Use it to gate content, check roles, and personalize data fetching.

The Clerk middleware is where you enforce global route protection. Use the createRouteMatcherhelper to define public routes, and protect everything else by default. This matches the "deny by default" security posture: every route requires a session unless explicitly listed as public.

Route protection in Next.js can happen at multiple layers. Middleware is ideal for coarse-grained access control: is the user signed in? Are they hitting an admin prefix? Server Components and route handlers are better for fine-grained decisions that depend on database state, such as ownership or subscription tier.

The middleware matcher is the most common source of protection bugs. A matcher that is too narrow leaves routes unprotected; a matcher that is too broad runs auth on every asset request, including static files and images. The standard Clerk matcher above excludes _next/static, _next/image, favicons, and files with explicit extensions.

Redirecting to sign-in is usually better than returning a 401 for page routes. A 401 is correct for APIs, but a browser user hitting a protected page should be sent somewhere useful. Always preserve the original URL as a callback so the user returns after signing in.

In Server Components, you can check the role and ownership with database context. This is where you enforce rules like "only the project owner can delete it" or "only paid subscribers can access this feature." Keep the checks explicit and return early on failure.

In Client Components, you can only check what the client already knows. The session data is derived from the server and exposed through a provider. Client-side guards are useful for UI affordances, but they must never be the only line of defense. Always re-verify permissions on the server.

Server Actions run on the server, so they have access to the same cookies and session data as route handlers and Server Components. The correct pattern is to call your auth helper inside the action and reject unauthorized requests immediately. This is where most form submissions are protected, because forms are the primary way users mutate state.

Auth.js actions import auth from auth.ts. Clerk actions import auth from @clerk/nextjs/server. The shape of the returned session differs, but the pattern is the same: verify, then act.

Server Actions are protected against cross-site request forgery by default because they require a same-origin request and a valid session. However, you should still validate and sanitize every input. Never trust the shape of data sent from a form, and never expose internal IDs or error messages that reveal the existence of resources.

Auth.js supports two session strategies: JSON Web Tokens stored in an encrypted cookie, and database sessions stored in a persistence layer. Clerk manages session state internally and exposes it through short-lived tokens. The choice of strategy affects latency, revocation, and complexity.

In Auth.js, choose the strategy with the session.strategy option. The JWT strategy is the default and works well for most applications. Switch to database sessions when you need to revoke sessions, track active logins, or store large amounts of session metadata.

Token lifecycle matters regardless of strategy. Keep access tokens short-lived, refresh tokens longer but rotatable, and session cookies scoped to your domain with the Secure, HttpOnly, and SameSite attributes set. Auth.js and Clerk set these defaults for you, but review them when you customize cookies.