Context
Clerk and Auth.js (next-auth) solve authentication for the same kind of app, but they sit on opposite sides of the build-versus-buy line. Clerk is a managed, hosted service: drop-in UI components like <SignIn />, users, sessions, MFA, and password recovery handled for you, billed per monthly active user (MAU) above the free tier. Auth.js is an open-source, self-hosted library: free, with users in your own database, many OAuth providers available, and the UI on you. The real axis of the decision isn't which one is "better," it's what you want to pay: managed convenience and a per-user cost, or open-source control and more assembly work.
One context detail so you don't read the numbers the wrong way: next-auth downloads more (around 5.1 million per week) than @clerk/nextjs (close to 1.5 million). That doesn't make Clerk "less mature"; it reflects that a free open-source library tends to show up in more projects than a paid service. A note on versions: "Auth.js" is the rebrand name that ships with v5, but the package pinned here is next-auth v4 (4.24.14), still the most installed, and it's the v4 API the examples below use.
When to choose Clerk
Clerk pays off when the goal is having login working in minutes, with the minimum of hand-written authentication code. The most visible differentiator is the drop-in UI components: an entire login screen fits in a single component.
// app/sign-in/[[...sign-in]]/page.tsx
import { SignIn } from "@clerk/nextjs";
export default function SignInPage() {
return <SignIn />;
}
That <SignIn /> renders the form, validation, OAuth, MFA, and error messages, all hosted and maintained by Clerk, with a <ClerkProvider> at the root and middleware protecting the routes. You don't model a user table, you don't write a session flow, you don't build the screen: you wire the providers from the dashboard and ship. The price of that speed is twofold. First, financial: above the free tier, the bill grows per monthly active user, so cost scales with your user base. Second, control: users and sessions live in Clerk's infrastructure, not in your database, which means more lock-in and less control over where the data sits. For many products, getting to market fast is worth that trade.
When to choose Auth.js
Auth.js pays off when you want to own the authentication data and not pay per user for it, accepting that you assemble more of it yourself.
// 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!,
}),
],
});
This route handler is the heart of the configuration: you declare the OAuth providers in code (and there are many available), and with an adapter the users and sessions go into your own database, under your control. There's no per-MAU cost: you pay only for the infrastructure you already run. Lock-in is minimal, because everything is open-source code inside your project, not a third party's API. The tradeoff is effort: the login screen, the "sign in with" buttons, and handling session states are on you, and you wire callbacks and session manually instead of getting them ready-made. It's more upfront work in exchange for full control and predictable cost.
Verdict
The decision reduces to a single trade: managed convenience and a per-user cost, against open-source control and more assembly work. If you want login live in minutes, with drop-in UI, MFA, and user management you don't have to maintain, and you accept paying per active user and leaving the data in Clerk's infrastructure, Clerk delivers that with very little code. If you want users in your own database, with no per-MAU cost and without depending on an external service, Auth.js delivers that in exchange for building the UI and wiring session and callbacks yourself.
In practice, the tiebreaker tends to be the cost model and the data model, not the feature sheet. A product that needs to validate fast, with a small team, tends to gain from Clerk taking authentication off its plate; a product sensitive to per-user cost at scale, or that needs user data in its own database for compliance or integration, tends to prefer Auth.js's control. Worth remembering, if you're starting now: next-auth v5 (under the Auth.js brand) changes the configuration API, so check which version your tutorial assumes before copying the setup.