Clerk vs Auth.js

Clerk ships React components — <SignIn />, <SignUp />, <UserButton />, <UserProfile /> — that drop into a Next.js app and handle the entire flow. Customization happens through theme variables and per-component props. The default UI is well-designed; teams use it as-is more often than not.

Auth.js gives you the auth logic; the UI is yours to build. You write a sign-in page that calls signIn('google'), handle the callback, render the session state. The provider-recipe docs are excellent, but you're the one writing JSX.

With Clerk, users live in Clerk's database. You query them via Clerk's API or webhook them into your own DB on signup/update for relational queries. The dashboard handles user search, edit, ban, soft-delete. Most apps end up with both — canonical users at Clerk, denormalized copies in their DB for joins.

With Auth.js, users live in your database from day one. The default Postgres adapter creates users, accounts, sessions, verification_tokens tables. You write the JOIN, you own the schema. Want to add a 'subscribed' boolean to the user? You add a column.

Clerk's B2B features are first-class: organizations, role-based access control, organization invitations, SAML SSO (on Pro+), domain-based auto-join, organization switcher UI. The mental model matches B2B SaaS conventions; the components are drop-in.

Auth.js doesn't have B2B features built in. You'd build the org table, the org_members join table, the role enum, the invitation flow, and the SSO integration yourself (often via WorkOS or Keycloak as the SSO middleware). It's all standard work, but it's all yours to do.

Clerk ships TOTP, SMS, email codes, backup codes, and WebAuthn passkeys as built-in flows. The UI prompts users to enroll, manages backup codes, handles recovery. You toggle MFA requirements per-app or per-org.

Auth.js supports passkeys via the WebAuthn adapter. TOTP and SMS MFA are not built-in — you wire up your own (using libraries like otplib for TOTP, Twilio for SMS) and store the factor data in your DB.

Clerk uses session tokens by default with active-session tracking. Users see a 'Devices' list in their profile and can revoke individual sessions. Tokens are short-lived; refresh happens transparently. Multi-tab session sync just works.

Auth.js supports both JWT (stateless) and database sessions. JWT is simpler but doesn't allow revocation; database sessions allow revocation but require a DB lookup per request. The choice is a real architectural decision you'll make and live with.

Clerk supports 20+ social providers (Google, GitHub, Microsoft, Apple, Discord, Twitch, Facebook, etc.). Custom OIDC providers are supported on Pro. Enterprise SSO (SAML) is a Pro feature; it works with Okta, Azure AD, Google Workspace, Auth0, etc.

Auth.js supports 70+ providers out of the box, plus a generic OAuth/OIDC adapter for anything not in the list. Enterprise SSO comes via adding Keycloak or WorkOS as a provider; Auth.js doesn't speak SAML directly.

Clerk emits webhooks for user.created, user.updated, session.created, session.ended, organization.created, etc. Signing via Svix. The webhook payload is well-documented and the dashboard has a replay tool. Most apps use webhooks to mirror users into their own DB.

Auth.js has callback hooks (signIn, jwt, session) that run inline during auth flows — you mutate the session payload, write to your DB, decline a sign-in. There's no async webhook system because the events happen in your own code.

Migrating off Clerk involves: exporting users (CSV or API), importing into a new auth system, having every user re-authenticate (password hashes are not portable across systems), and deciding what to do with active sessions (force re-login or accept the rotation). It's a real project — typically 1–3 weeks plus customer comms.

Auth.js has nothing to migrate from — your users are in your database. If you decide to switch to Clerk later, the same migration applies in reverse. The 'staying in Auth.js' path is just changes to your own code.