Autenticação no Next.js: NextAuth, Supabase e middleware

Problema

Token JWT no localStorage, middleware que só checa string vazia e sessão que não invalida no servidor. Ou misturar Supabase client no servidor sem contexto de cookies corretos.

Solução

Preferir sessão gerenciada (NextAuth/Auth.js ou Supabase SSR) com cookies seguros (httpOnly, Secure, SameSite). Middleware do Next para early redirect e checagem leve; autorização fina no Server Component / API com dados frescos do usuário.

Arquitetura

Login → provider (Google, e-mail magic link, etc.)
     → cookie de sessão assinada / refresh no servidor
Rotas protegidas → middleware (presença) + server (papel/permissão)

• CSRF e OAuth state tratados pela lib, não reinventados.
• Separation: o que roda no Edge vs Node runtime no middleware.

Código

// middleware.ts (ideia)
export function middleware(req: NextRequest) {
  const token = req.cookies.get("session")?.value;
  if (!token && req.nextUrl.pathname.startsWith("/app")) {
    return NextResponse.redirect(new URL("/login", req.url));
  }
  return NextResponse.next();
}
 
export const config = { matcher: ["/app/:path*"] };

No servidor, sempre validar sessão com a SDK oficial e não confiar só no middleware.

Performance

Middleware mínimo (sem chamadas pesadas); cache de claims com TTL curto se necessário; evitar waterfall de auth em cada RSC.

Melhorias futuras

RBAC no token de sessão custom; step-up MFA para ações sensíveis; auditoria de sessões.

Conclusão

Auth moderna no Next é cookies + servidor + política. Artigo assim fecha a curva full stack do seu blog.