Authentication Patterns in Next.js

Analogy categoryAnalogies

Authentication in Next.js spans multiple execution contexts — Server Components that render on request, Client Components that run in the browser, Middleware that runs at the edge before a request reaches a route, and Server Actions that mutate data — and each context has different rules about reading cookies, verifying sessions, and redirecting. A coherent auth strategy typically combines a session cookie (HTTP-only, signed or encrypted) checked in Middleware for route protection, with server-side session verification inside Server Components for actual data access decisions.

🏏

Cricket analogy: It's like a stadium's layered security: a ticket check at the outer gate (middleware), a separate wristband check at the pavilion entrance (server component), and a final ID check for the players' area (server action) — each checkpoint verifies identity differently for its context.

Protecting Routes with Middleware

middleware.ts runs on the Edge Runtime before a request completes, so it's the right place to redirect unauthenticated users away from protected routes like /dashboard before any page code executes, minimizing wasted server work. Middleware reads the session cookie via request.cookies.get('session'), but because it runs on the Edge Runtime it cannot use Node-specific APIs like most database drivers — so it typically only checks whether a valid-looking token exists, deferring full verification (checking a database or validating a JWT signature with a Node-only library) to the actual Server Component.

🏏

Cricket analogy: It's like a stadium steward at the outer perimeter doing a quick visual ticket check to turn away anyone without a ticket at all, while the full barcode scan and seat verification happens later at the specific block entrance.

typescript

// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const session = request.cookies.get('session')?.value;
  const isProtected = request.nextUrl.pathname.startsWith('/dashboard');

  if (isProtected && !session) {
    const loginUrl = new URL('/login', request.url);
    loginUrl.searchParams.set('from', request.nextUrl.pathname);
    return NextResponse.redirect(loginUrl);
  }

  return NextResponse.next();
}

export const config = { matcher: ['/dashboard/:path*'] };

Never trust middleware alone as your only security boundary. Because it runs on the Edge Runtime and often only checks for cookie presence rather than doing full cryptographic verification, always re-verify the session inside the Server Component or Server Action that actually reads or mutates sensitive data.

Session Verification in Server Components and Actions

Inside a Server Component, you read the session cookie with the cookies() function from next/headers, verify it (decrypt a session token, or query a sessions table), and either render the page or call redirect('/login') from next/navigation. Server Actions need their own independent auth check at the top of the function body — never assume that because a page rendered successfully, every subsequent Server Action call is automatically authenticated, since actions can be invoked directly and must defend themselves.

🏏

Cricket analogy: It's like a bowler re-checking the field placement before every single delivery, not just once at the start of the over, because conditions and the batter's position can change ball to ball.

typescript

'use server';
import { cookies } from 'next/headers';
import { verifySession } from '@/lib/session';

export async function deletePost(postId: string) {
  const sessionToken = cookies().get('session')?.value;
  const user = await verifySession(sessionToken);

  if (!user) {
    throw new Error('Unauthorized');
  }

  // proceed with the authorized mutation
  await db.post.delete({ where: { id: postId, authorId: user.id } });
}

Token-Based Auth and Third-Party Providers

Libraries like Auth.js (NextAuth) or Clerk abstract the OAuth handshake, session storage, and token refresh logic, exposing hooks like useSession() for Client Components and server helpers like auth() for Server Components and Route Handlers. When integrating a third-party identity provider (Google, GitHub, an enterprise SSO), the callback URL registered with that provider must exactly match your app's route handler path, and the provider-issued access token should be stored server-side (in an encrypted session or a database-backed session store) rather than passed to the client, to avoid exposing scopes the browser doesn't need.

🏏

Cricket analogy: It's like an ICC-accredited umpire whose certification is recognized across every member board — you don't re-certify from scratch for each country, you trust the accrediting body's token.

When using an OAuth provider, never store the raw access token in a client-readable cookie or localStorage — keep it server-side and only expose the minimal session data (like user ID and role) the client actually needs to render UI.

Authentication spans Middleware, Server Components, Client Components, and Server Actions, each with different capabilities and trust levels.
Middleware runs on the Edge Runtime and should do a fast, lightweight check (cookie presence), not full cryptographic verification.
Server Components read cookies via cookies() from next/headers and should independently verify the session before rendering protected data.
Server Actions must perform their own auth check at the top of the function — never assume a successfully rendered page guarantees a safe action call.
Libraries like Auth.js and Clerk abstract OAuth flows and expose useSession() for clients and auth() for servers.
OAuth callback URLs must exactly match what's registered with the provider, and raw access tokens should never be exposed to the client.
Treat middleware as the first, cheap filter and Server Component/Action checks as the actual security boundary.