How can I implement JWT authentication with App Router in Next.js 16?

[vigneshwaran1702]

Summary

I'm building a Next.js 16 application using the App Router. I want to implement JWT authentication for protected routes but I'm unsure of the recommended approach. Could someone explain the best practice?

Additional information

Next.js: 16.x
Node.js: 22.x
OS: Windows 11

No runtime errors.
I'm looking for the recommended implementation pattern.

Example

Can you check in my( GitHub page https://github.com/vigneshwaran1702 )

[vigneshwaran1702]

One thing to check is whether the issue is caused by stale dependencies or cached build artifacts.

Try:

• Delete .next
• Reinstall dependencies (npm install or pnpm install)
• Start the development server again

If the problem persists, please share the relevant code and error output.

[lMysticl]

Deleting .next or reinstalling dependencies is unrelated here because there is no reported runtime failure.

For Next.js 16, the recommended approach is to use an established authentication library such as Auth.js, Better Auth, Clerk, or another supported provider instead of implementing the complete JWT lifecycle yourself.

The important architecture is:

1. Store the session token in a server-set HttpOnly, Secure, SameSite cookie — not localStorage.
2. Verify the session in a server-only data-access function.
3. Call that verification from every protected Server Action, Route Handler, and data query.
4. Use proxy.ts only for early redirects. It is an optimistic check, not the authorization boundary.

If you implement the JWT yourself, verify its signature and expiry on the server and still perform authorization at each protected operation. The official guide documents this separation: Next.js authentication.

[kuldeeprajput-dev]

For Next.js 16, use an auth library like Auth.js instead of building JWT auth from scratch.

Store the session/JWT in an httpOnly cookie and verify it in Server Components or Route Handlers. Use proxy.ts only for redirects, not as the main security layer.

Docs:
https://nextjs.org/docs/app/guides/authentication
https://authjs.dev/getting-started

[ZAKI-MUHAMAD-FADILAH]

I would add one important constraint to this architecture: don't make the JWT/session itself the source of truth for effective permissions.

For multi-layer authorization like this, I would separate it into:

Identity
   ↓
Organization entitlement
   ↓
User permission
   ↓
Backend resource/route policy
   ↓
Effective capabilities
   ↓
Server enforcement + UI projection

The key is that effectiveCapabilities should be computed from authoritative server-side data, not permanently merged into a long-lived JWT.

For example:

type Capability =
  | "analytics.read"
  | "analytics.write"
  | "billing.read"
  | "billing.manage";

type ResourcePolicy = {
  path: string;
  required: Capability[];
};

function resolveCapabilities({
  org,
  user,
}: {
  org: Set<Capability>;
  user: Set<Capability>;
}) {
  return new Set(
    [...user].filter(permission => org.has(permission))
  );
}

Then keep one registry for application resources:

export const resources = {
  analytics: {
    path: "/dashboard/analytics",
    required: ["analytics.read"],
  },

  billing: {
    path: "/dashboard/billing",
    required: ["billing.read"],
  },
} satisfies Record<
  string,
  {
    path: string;
    required: Capability[];
  }
>;

From there, the same policy can drive:

• server-side authorization;
• navigation/menu generation;
• component visibility;
• Route Handler / Server Action checks.

But these are still different enforcement points, not different authorization systems.

For example:

export function canAccess(
  capabilities: Set<Capability>,
  required: Capability[]
) {
  return required.every(permission =>
    capabilities.has(permission)
  );
}

A Server Component can use it:

const capabilities = await getEffectiveCapabilities(userId);

if (
  !canAccess(
    capabilities,
    resources.analytics.required
  )
) {
  notFound();
}

And the menu can derive directly from the exact same registry:

const menu = Object.entries(resources)
  .filter(([, resource]) =>
    canAccess(capabilities, resource.required)
  )
  .map(([key, resource]) => ({
    key,
    href: resource.path,
  }));

That removes the need to maintain:

route permissions
menu permissions
component permissions
middleware permissions

as separate mappings.

I would also avoid putting the full permission matrix into a long-lived JWT.

If an admin removes access while a token is still valid, a JWT containing stale permissions can continue advertising capabilities that no longer exist.

Instead, I would keep the token focused mostly on identity/session information and resolve authorization server-side, optionally caching the result with a short TTL or an authorization/version key.

Something like:

JWT/session
  userId
  organizationId
        ↓
Authorization Service / DAL
        ↓
org entitlement
+ user grants
+ backend policy
        ↓
effective capabilities

The frontend can receive a sanitized capability projection for UX purposes, but the backend or DAL must re-check authorization before any sensitive operation.

For backend-driven routes specifically, I would strongly prefer:

Backend contract
      ↓
generated/versioned resource schema
      ↓
frontend resource registry
      ↓
navigation + route metadata + UI

rather than manually reproducing backend paths and permission names in several frontend files.

If the backend contract can be represented by OpenAPI, JSON Schema, or another machine-readable schema, generating the TypeScript resource types/metadata from it also prevents frontend/backend authorization drift.

So my rule would be:

One authoritative authorization policy, many enforcement points.

Middleware/Proxy can perform cheap optimistic checks, Server Components can prevent unauthorized pages from rendering, and Server Actions/Route Handlers/DAL should perform the final security check.

The UI should reflect authorization — never be the authorization boundary itself.