Clerk vs Auth.js

Contexto

Clerk e Auth.js (o next-auth) resolvem autenticação para o mesmo tipo de app, mas ficam em lados opostos da linha entre comprar e construir. Clerk é um serviço gerenciado e hospedado: componentes de UI drop-in como <SignIn />, usuários, sessões, MFA e recuperação de senha cuidados por eles, com cobrança por usuário ativo mensal (MAU) acima do plano grátis. Auth.js é uma biblioteca open-source e self-hosted: gratuita, com os usuários no seu próprio banco, muitos providers OAuth disponíveis, e a UI por sua conta. O eixo real da decisão não é qual é "melhor", e sim o que você quer pagar: conveniência gerenciada e custo por usuário, ou controle open-source e mais trabalho de montagem.

Um detalhe de contexto para não ler os números de forma errada: next-auth baixa mais (por volta de 5.1 milhões por semana) do que o @clerk/nextjs (perto de 1.5 milhão). Isso não torna a Clerk "menos madura"; reflete que uma biblioteca open-source gratuita tende a aparecer em mais projetos do que um serviço pago. Uma observação sobre versões: "Auth.js" é o nome do rebrand que acompanha a v5, mas o pacote fixado aqui é o next-auth v4 (4.24.14), ainda o mais instalado, e é a API v4 que os exemplos abaixo usam.

Quando escolher Clerk

Clerk compensa quando o objetivo é ter login funcionando em minutos, com o mínimo de código de autenticação escrito à mão. O diferencial mais visível são os componentes de UI drop-in: uma tela de login inteira cabe em um componente.

// app/sign-in/[[...sign-in]]/page.tsx
import { SignIn } from "@clerk/nextjs";

export default function SignInPage() {
  return <SignIn />;
}

Esse <SignIn /> renderiza formulário, validação, OAuth, MFA e mensagens de erro, tudo hospedado e mantido pela Clerk, com um <ClerkProvider> na raiz e o middleware protegendo as rotas. Você não modela tabela de usuário, não escreve fluxo de sessão, não constrói a tela: liga os providers pelo dashboard e sobe. O preço dessa velocidade é duplo. Primeiro, financeiro: acima do plano grátis, a conta cresce por usuário ativo mensal, então o custo escala com a base de usuários. Segundo, de controle: os usuários e sessões vivem na infraestrutura da Clerk, não no seu banco, o que significa mais lock-in e menos controle sobre onde os dados ficam. Para muitos produtos, chegar rápido ao mercado vale essa troca.

Quando escolher Auth.js

Auth.js compensa quando você quer ser dono dos dados de autenticação e não pagar por usuário para isso, aceitando montar mais coisa você mesmo.

// pages/api/auth/[...nextauth].ts
import NextAuth from "next-auth";
import GitHubProvider from "next-auth/providers/github";

export default NextAuth({
  providers: [
    GitHubProvider({
      clientId: process.env.GITHUB_ID!,
      clientSecret: process.env.GITHUB_SECRET!,
    }),
  ],
});

Esse route handler é o coração da configuração: você declara os providers OAuth em código (e há muitos disponíveis), e com um adapter os usuários e sessões vão para o seu próprio banco, sob seu controle. Não há custo por MAU: você paga apenas a infraestrutura que já roda. O lock-in é mínimo, porque tudo é código open-source dentro do seu projeto, não a API de um terceiro. A contrapartida é o esforço: a tela de login, os botões de "entrar com" e o tratamento de estados de sessão são por sua conta, e você conecta callbacks e sessão manualmente em vez de receber isso pronto. É mais trabalho inicial em troca de controle total e custo previsível.

Veredito

A decisão se reduz a uma única troca: conveniência gerenciada e custo por usuário, contra controle open-source e mais trabalho de montagem. Se você quer login no ar em minutos, com UI drop-in, MFA e gestão de usuários que você não precisa manter, e aceita pagar por usuário ativo e deixar os dados na infraestrutura da Clerk, Clerk entrega isso com pouquíssimo código. Se você quer os usuários no seu próprio banco, sem custo por MAU e sem depender de um serviço externo, Auth.js entrega isso em troca de construir a UI e conectar sessão e callbacks você mesmo.

Na prática, o desempate costuma ser o modelo de custo e o de dados, não a folha de recursos. Um produto que precisa validar rápido, com equipe pequena, tende a lucrar com a Clerk tirando autenticação da frente; um produto sensível a custo por usuário na escala, ou que precisa dos dados de usuário no próprio banco por conformidade ou integração, tende a preferir o controle do Auth.js. Vale lembrar, se estiver começando agora, que o next-auth v5 (sob a marca Auth.js) muda a API de configuração, então confira qual versão o seu tutorial assume antes de copiar o setup.