Next.js App Router auth that does not fight Server Components

Library choice matters less than where you enforce auth. Mixing client guesses with server truth is how you get flaky redirects and double fetches.

Keep authority on the server, refresh sessions predictably, and let the UI stay dumb. Patterns below are the ones we keep when apps grow past the demo.

Pattern 1: Server-side checks for access control

Use the server for “can the user do this?” decisions:

• Server Components that read session/user
• Route handlers that validate permissions
• Server actions that verify entitlements

Client components are for interaction, not authority.

Pattern 2: Keep one source of truth for session retrieval

Pick a single helper that:

• Reads the current session/user
• Returns a consistent shape
• Is used across pages, actions, and routes

This reduces bugs where one route checks the wrong thing.

Pattern 3: Middleware for routing, not for business logic

Middleware is great for:

• Redirecting unauthenticated users away from protected routes
• Enforcing “must be logged in” at the edge

But avoid stuffing complex authorization logic into middleware. Keep real permission checks on the server.

Pattern 4: Plan for “session refresh”

Sessions expire, cookies rotate, and users keep tabs open.

Make sure your UX handles:

• Expired sessions gracefully
• Redirect back to the originally requested page
• A clear sign-in prompt rather than silent failure

Pattern 5: Separate “identity” from “entitlement”

Being logged in isn’t the same as being paid.

Model:

• Identity: user, org membership, roles
• Entitlement: plan, credits, feature flags, limits

This separation is key for billing systems and usage limits.

If you’re using Supabase, the RLS guide at /blog/supabase-auth-rls-nextjs-saas is the natural next step.