Autenticação no Next.js: Auth.js vs Better Auth vs Clerk | We.Inc
Compare Auth.js, Better Auth, Clerk, Supabase Auth e uma sessão feita à mão no Next.js 16, com código de configuração para cada um e um seletor que filtra a lista conforme as suas necessidades.
Autenticação no Next.js: as opções comparadas
Na maioria das aplicações Next.js, escolha uma biblioteca em vez de escrever a autenticação você mesmo. O Clerk é hospedado e o mais rápido de configurar, o Supabase Auth combina com aplicações que já usam Supabase, e o Better Auth ou o Auth.js mantêm os usuários no seu próprio banco de dados. Seja qual for a escolha, verifique a sessão de novo no código do servidor, porque checagens no proxy sozinhas não protegem os dados.
Visão geral
Opção
Onde ficam os usuários
Clerk
Nos servidores do Clerk
@clerk/nextjs, ClerkProvider, clerkMiddleware em proxy.ts
Supabase Auth
No seu projeto Supabase
clientes @supabase/ssr mais um proxy que renova a sessão
Better Auth
No seu próprio banco de dados
instância auth mais app/api/auth/[...all]/route.ts
Auth.js (next-auth v5 beta)
No seu banco de dados ou em um cookie JWT
auth.ts mais app/api/auth/[...nextauth]/route.ts
Fazer a sua própria
No seu próprio banco de dados
jose ou iron-session, cookies httpOnly, uma camada de acesso a dados
O guia oficial do Next.js lista doze bibliotecas de autenticação compatíveis, o que é mais escolha do que a maioria das pessoas quer. Esta comparação reduz a lista aos cinco caminhos que a maioria das equipes realmente considera, mostra o código mínimo de cada um no App Router e explica as verificações que a sua aplicação ainda precisa fazer, não importa qual biblioteca faça o login.
Marque os requisitos que importam para você, como manter os dados dos usuários no seu próprio banco ou ter telas de login prontas.
O seletor esconde as opções que não atendem a todos os requisitos marcados.
Abra o código de configuração das opções que sobraram e compare quanto você teria que escrever.
Leia a seção de segurança antes de publicar, seja qual for a opção escolhida.
Guarde as sessões em cookies definidos no servidor com HttpOnly, Secure, SameSite e uma expiração, como recomenda o guia do Next.js.
Coloque uma função verifySession() em um único arquivo só de servidor e chame-a nas páginas, Server Actions e Route Handlers.
Não dependa de um layout para checar a autenticação. Layouts não são renderizados de novo na navegação do lado do cliente, então a checagem pode ser pulada.
Mantenha o conteúdo da sessão pequeno: um id de usuário e um papel, nunca um endereço de e-mail ou número de telefone.
Gere os segredos com openssl rand -base64 32 (ou npx auth secret no Auth.js) e guarde-os em variáveis de ambiente.
Perguntas frequentes
O NextAuth ainda é mantido?
O Auth.js, projeto antes chamado NextAuth, diz no próprio site que agora faz parte do Better Auth. O comando de instalação para Next.js continua sendo npm install next-auth@beta. Projetos novos muitas vezes já começam no Better Auth, enquanto as aplicações existentes com Auth.js continuam funcionando.
Posso proteger páginas só com o proxy.ts?
Não. A documentação do Next.js chama as checagens no proxy de otimistas: boas para redirecionamentos rápidos com base em um cookie, mas não são uma barreira de segurança. Verifique a sessão de novo perto dos dados, porque Server Functions e rotas fora do matcher nunca passam pelo proxy.
Qual opção é a mais barata?
Bibliotecas que guardam os usuários no seu próprio banco, como Better Auth ou Auth.js, não cobram por usuário; você paga pelo banco de dados e pelo envio de e-mails. O Supabase Auth inclui 50,000 usuários ativos por mês no plano gratuito em outubro de 2026. Consulte a página de preços do Clerk para ver a cota gratuita atual.
Essas opções funcionam com o Next.js 16?
Sim. Clerk e Supabase documentam o proxy.ts para o Next.js 16 e o middleware.ts para versões anteriores, e o Better Auth oferece um helper de cookie para o proxy mais uma checagem completa da sessão para o código do servidor.
Sessão sem estado ou no banco de dados?
Um cookie assinado (sem estado) é mais simples e não precisa de consulta, mas você não consegue revogá-lo antes de expirar. Uma sessão no banco custa uma consulta por checagem e permite que o usuário saia de todos os dispositivos. Muitas bibliotecas deixam você escolher.
Hospedado versus auto-hospedado
O Clerk cuida do armazenamento de usuários, das páginas de login e do controle de sessão para você, e você só coloca os componentes dele no seu layout. Você troca um pouco de controle e uma conta mensal em escala por velocidade e uma interface caprichada desde o primeiro dia.
O Better Auth e o Auth.js rodam dentro da sua aplicação e gravam no seu banco de dados. Os dados e as telas são seus, mas também ficam com você o envio de e-mails, os fluxos de redefinição de senha e as atualizações.
Se você já usa Supabase
O Supabase Auth liga o login diretamente à row level security do Postgres, então uma política como auth.uid() = user_id protege os dados na camada do banco. O pacote @supabase/ssr guarda a sessão em cookies para que os Server Components consigam lê-la.
A documentação do Supabase avisa que getSession() retorna dados não verificados. Use getClaims(), que confere a assinatura do token, ou getUser(), que consulta o servidor de autenticação, antes de confiar em quem é o usuário.
Escrevendo a sua própria
O guia do Next.js mostra o passo a passo com uma Server Action para o formulário, Zod para validação, bcrypt para o hash e jose para assinar um cookie de sessão de sete dias. É uma boa forma de entender as peças envolvidas.
Para produção, o mesmo guia recomenda uma biblioteca, porque limite de requisições, verificação de e-mail, vinculação de contas e login multifator somam trabalho rápido.
Configuração mínima de cada opção
Clerk
Instale @clerk/nextjs e defina NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY e CLERK_SECRET_KEY. No Next.js 16 o arquivo de middleware é o proxy.ts.
Supabase Auth
Um cliente de servidor criado a cada requisição a partir do armazenamento de cookies, usando a chave publicável. getClaims() verifica o token antes de você confiar nele.
Better Auth
Monte o handler em uma rota catch-all e depois leia a sessão no servidor com os cabeçalhos da requisição.
Auth.js (next-auth v5 beta)
O auth.ts exporta handlers, auth, signIn e signOut. Defina AUTH_SECRET (npx auth secret cria um).
O seu próprio cookie de sessão assinado
Uma versão curta do padrão do guia do Next.js: o jose assina o conteúdo e o cookie é HttpOnly, Secure e SameSite=Lax.
Onde verificar a sessão
Checagens de autenticação por local (do guia de autenticação do Next.js)
Local
Tipo de checagem
Por quê
Otimista, só o cookie
Redirecionamentos rápidos; roda antes da renderização, inclusive nos prefetches
Camada de acesso a dados
Segura
Um único verifySession() por onde passa toda leitura de dados
Server Actions
Segura
Tratadas como endpoints públicos; verifique o papel antes de alterar dados
Route Handlers
Segura
401 quando não há login, 403 quando o papel está errado
Layouts
Evite
Não são renderizados de novo na navegação, então as checagens podem ser puladas
Clerk
O caminho mais rápido até uma página de login funcionando; os usuários ficam no Clerk.
Supabase Auth
Os usuários ficam no seu Postgres do Supabase; os planos pagos cobram os usuários que passam da quantidade incluída.
Better Auth
Biblioteca dentro da sua aplicação, grava no seu banco, com plugins para recursos extras.
Opção tradicional, agora parte do Better Auth; a v5 ainda é publicada como beta.
Fazer a sua própria
Controle total; você escreve cada fluxo e cuida da segurança.
Os registros de usuários ficam em um banco que eu controlo
Telas de login e de perfil prontas
Sem cobrança por usuário do provedor de autenticação
Login ligado à row level security do Postgres
Seletor de opções de autenticação
Marque os requisitos que importam e a lista mantém só as opções que atendem a todos eles.
Requisitos
Nenhuma opção atende sozinha a todos os requisitos marcados. Desmarque um para comparar.