Next.js Authentication with Auth.js
A production-minded Auth.js tutorial for Next.js App Router projects, covering sessions, role-aware access, callbacks, and secure auth boundaries.
Authentication architecture goes wrong when the session model, role checks, and route boundaries are designed independently. In a Next.js App Router codebase, those decisions need to line up before you wire providers and callbacks together.
This tutorial focuses on a clean Auth.js integration that works with server components, route handlers, and role-aware application flows. If you are still deciding whether your app should lean into server rendering, read The Practical Guide to React Server Components first.
Secure Next.js authentication is easier when session rules, role checks, and callback behavior are designed before UI guards.
Decide the session strategy first
Before you install anything, define the constraints that matter:
- Do you need immediate session revocation?
- Will multiple devices stay logged in at once?
- Are roles simple enough to encode once, or do they need to reflect live database state?
For editorial platforms and SaaS dashboards, database-backed sessions are usually easier to audit. JWT sessions are acceptable when you need stateless edge reads and can tolerate slightly looser revocation semantics.
Configure Auth.js in the App Router
Keep the auth boundary small. Put provider setup, session callbacks, and exported helpers in one module so route handlers and server components share the same primitives.
import NextAuth from 'next-auth';
import GitHub from 'next-auth/providers/github';
export const { handlers, auth, signIn, signOut } = NextAuth({
providers: [GitHub],
session: { strategy: 'database' },
callbacks: {
async session({ session, user }) {
session.user.id = user.id;
session.user.role = user.role;
return session;
},
},
});The important part is not the provider choice. It is having one canonical auth() entry point that every protected server surface can use.
Protect server components, route handlers, and actions
The App Router gives you multiple execution surfaces, so the mistake is assuming one guard covers them all.
- Server components should read the session early and branch before expensive data work.
- Route handlers should reject unauthenticated or unauthorized requests explicitly.
- Server actions should validate both identity and capability, not just the existence of a session.
This is the same principle discussed in Building a Full-Stack App with the Next.js App Router: the mutation boundary matters more than the button that triggered it.
Design role checks around capabilities
Avoid sprinkling role === 'admin' throughout the tree. Model capabilities instead:
canPublishcanManageUserscanViewBilling
That lets you evolve roles without rewriting every branch. It also keeps authorization logic close to the policy layer instead of scattering it into layout files, loaders, and client components.
Production checklist
Before shipping, verify the boring parts:
- Session cookies are
httpOnly,secure, and use the rightsameSitepolicy. - Redirect URLs are explicit and environment-safe.
- Session callbacks do not leak fields the client does not need.
- Protected pages are not relying on client-only redirects for access control.
- Audit logs exist for privilege changes and sensitive account actions.
Authentication feels straightforward in demos because the state space is small. It becomes maintainable in production when the session contract, role model, and server boundaries are designed together.
Related next reads
Frequently Asked Questions
When should I use database sessions instead of JWT sessions?
Use database sessions when you need revocation, central session inspection, or multi-device logout. JWT sessions are lighter, but they push more invalidation logic into your application.
Do I still need middleware if I validate sessions in server code?
Yes, middleware is still useful for fast route gating and redirect behavior. Server-side validation remains the source of truth for sensitive reads and writes.
