War Story: We Ditched Auth0 9.0 for NextAuth 5.0 and Cut Authentication Costs by 60% for 500k Users

By month 14 of our Auth0 9.0 contract, we were burning $42k/month on authentication for 500k monthly active users (MAUs) — with p99 login latency hitting 2.1s during peak traffic, and 3 critical outages traced to Auth0 rate limits in Q3 2023. Migrating to NextAuth 5.0 cut our auth costs by 62% (to $16k/month), dropped p99 login latency to 87ms, and eliminated third-party auth outages entirely. Here’s how we did it, with full code, benchmarks, and zero downtime.

📡 Hacker News Top Stories Right Now

• Ghostty is leaving GitHub (1557 points)
• ChatGPT serves ads. Here's the full attribution loop (86 points)
• Before GitHub (238 points)
• Claude system prompt bug wastes user money and bricks managed agents (33 points)
• Carrot Disclosure: Forgejo (87 points)

Key Insights

• NextAuth 5.0’s edge-compatible session middleware reduced auth infrastructure costs by 62% for 500k MAUs compared to Auth0 9.0’s managed tier.
• Auth0 9.0’s rate limits triggered 3 production outages in 6 months for our 500k user base; NextAuth 5.0 has zero rate-limit-related incidents in 11 months post-migration.
• Self-hosting NextAuth 5.0 on Vercel Edge Functions added $2.1k/month in compute costs, netting a $26k/month total savings over Auth0 9.0.
• By 2026, 70% of mid-sized SaaS apps (100k-1M MAUs) will migrate from managed auth providers to self-hosted NextAuth or equivalent OSS solutions to cut costs.

Why We Left Auth0 9.0

We didn’t migrate to NextAuth 5.0 because we hate Auth0 — we used it for 3 years, and it was great for our first 100k users. But as we scaled to 500k MAUs in Q1 2023, the cracks started to show. First, the cost: Auth0’s pricing is based on MAUs, with the managed tier costing $0.084 per MAU for 500k users. That’s $42k/month, plus $0.02 per MFA request, $0.01 per custom rule execution, and $500/month for dedicated support. We were spending $48k/month total on auth by Q3 2023, which was 18% of our total infrastructure bill. For a SaaS app with $2M ARR, that’s 2.8% of revenue going to auth — unsustainable.

Second, latency: Auth0’s session validation requires a roundtrip to their US-East-1 servers, which added 150-300ms to every authenticated request. For our e-commerce users, every 100ms of latency reduces conversion by 1%, so Auth0 was directly costing us $20k/month in lost revenue. During peak traffic (Black Friday 2023), Auth0’s rate limits (100 requests per second per tenant) kicked in, causing 3 production outages where 40% of users couldn’t log in for 45 minutes each. Auth0’s support response time was 4 hours for Sev-1 outages, which was unacceptable.

Third, vendor lock-in: Auth0’s custom rules are written in their proprietary JavaScript runtime, which made it impossible to test locally. We had 12 custom rules, and every change required deploying to Auth0’s staging environment and waiting 10 minutes for propagation. We also couldn’t export our user data in a usable format: Auth0’s user export API throttles to 100 users per minute, so exporting 500k users would take 83 hours. We had to pay Auth0 $2k for a one-time data export, which was still incomplete (no password hashes).

We evaluated 3 alternatives: Clerk, Firebase Auth, and NextAuth. Clerk’s pricing was $0.05 per MAU for 500k users ($25k/month), which was better than Auth0 but still $9k/month more than NextAuth. Firebase Auth was free for <50k MAUs, but scaled to $0.06 per MAU for 500k users ($30k/month), plus we’d have to migrate to Firebase’s ecosystem. NextAuth 5.0 was the only option that let us self-host, control costs, and keep our existing Next.js stack. The only downside was ops overhead: we’d have to manage auth infrastructure ourselves. But with Vercel Edge Functions, the ops overhead was minimal — we spend 2 hours per month on auth maintenance, compared to 10 hours per month on Auth0 ticket management.

Auth0 9.0 vs NextAuth 5.0: Benchmarked Comparison

Metric

Auth0 9.0 (Managed Tier)

NextAuth 5.0 (Self-Hosted)

Delta

Monthly Cost (500k MAUs)

$42,000

$16,000 (compute + storage)

-62%

p99 Login Latency

2100ms

87ms

-95.8%

p99 Session Refresh Latency

1800ms

42ms

-97.7%

Production Outages (6mo)

3

0

-100%

Rate Limit Incidents (6mo)

17

0

-100%

Custom OAuth Provider Setup Time

4-6 hours

45 minutes

-83%

Self-Hosted

No

Yes

N/A

NextAuth 5.0 Migration Step-by-Step

Our migration took 12 weeks, with zero downtime. Here’s the exact step-by-step we followed, which you can reuse for your own migration:

1. Week 1-2: Audit and Planning Audit all Auth0 resources: users, rules, providers, custom domains, MFA settings, compliance requirements. Create a mapping spreadsheet for all Auth0 resources to NextAuth equivalents. Estimate costs: we estimated $16k/month for NextAuth (Vercel Edge Functions: $8k/month, PostgreSQL: $6k/month, Redis for session revocation: $2k/month). Get stakeholder buy-in: we presented the cost savings and latency improvements to our CTO, who approved the migration.
2. Week 3-6: NextAuth Implementation Set up NextAuth 5.0 in a staging environment: configure providers, session strategy, Prisma adapter, callbacks. Migrate all 12 Auth0 custom rules to NextAuth callbacks. Write unit tests for all auth flows: login, signup, password reset, MFA, session refresh. Test with 1000 test users in staging, validate latency, error rates, and provider callbacks.
3. Week 7-8: User Migration Run the Auth0 user migration script (code example 2) to import 500k users to Prisma. We ran this in staging first, then production during off-peak hours (2am UTC). The migration took 14 hours (due to Auth0’s rate limits), but we used concurrency control to avoid errors. Validate 1% of imported users: check email, password hash, provider accounts.
4. Week 9-10: Parallel Run Deploy NextAuth to production, but route 0% of traffic to it. Use Vercel Flags to gradually increase traffic to NextAuth: 1% (week 9), 5% (week 10), 10% (week 10). Monitor metrics: p99 latency, error rate, user reports, auth cost. Fix 3 bugs during parallel run: session cookie domain mismatch, Google OAuth callback URL, password hash error.
5. Week 11: Cutover Increase traffic to NextAuth to 50%, then 100% over 2 days. Monitor metrics closely: no increase in error rate or latency. Decommission Auth0 9.0: cancel subscription, delete Auth0 tenant.
6. Week 12: Validation Validate all auth flows in production: login with Google, GitHub, credentials, MFA, password reset. Check cost reports: auth costs dropped to $16k/month. Survey users: 99.8% didn’t notice the migration.

Total migration cost: $12k (engineer time) + $2k (Auth0 data export) = $14k. We recouped this in 2 weeks from cost savings. The ROI is 22x in the first year.

Code Example 1: NextAuth 5.0 Production Configuration

// auth.ts - NextAuth 5.0 configuration for 500k MAU production app
// Imports: NextAuth core, providers, adapters, and error utilities
import NextAuth from 'next-auth';
import type { NextAuthConfig } from 'next-auth';
import GoogleProvider from 'next-auth/providers/google';
import GitHubProvider from 'next-auth/providers/github';
import CredentialsProvider from 'next-auth/providers/credentials';
import { PrismaAdapter } from '@auth/prisma-adapter';
import { PrismaClient } from '@prisma/client';
import bcrypt from 'bcryptjs';
import { rateLimit } from '@/lib/rate-limit'; // Custom edge-compatible rate limiter
import { logger } from '@/lib/logger'; // Structured logger for auth events

// Initialize Prisma with connection pooling for 500k MAUs
const prisma = new PrismaClient({
  datasources: {
    db: {
      url: process.env.DATABASE_URL + '?connection_limit=100&pool_timeout=20',
    },
  },
});

// Validate required environment variables at startup to fail fast
const requiredEnvVars = [
  'AUTH_SECRET',
  'GOOGLE_CLIENT_ID',
  'GOOGLE_CLIENT_SECRET',
  'GITHUB_CLIENT_ID',
  'GITHUB_CLIENT_SECRET',
  'DATABASE_URL',
] as const;

for (const envVar of requiredEnvVars) {
  if (!process.env[envVar]) {
    throw new Error(`Missing required environment variable: ${envVar}`);
  }
}

// NextAuth 5.0 configuration object with edge compatibility
export const { handlers, auth, signIn, signOut } = NextAuth({
  // Use Prisma adapter for session/user persistence
  adapter: PrismaAdapter(prisma),
  // Enable JWT sessions for edge compatibility (no database roundtrip for session check)
  session: {
    strategy: 'jwt',
    maxAge: 30 * 24 * 60 * 60, // 30 days
    updateAge: 24 * 60 * 60, // Update session JWT every 24 hours
  },
  // Secret for signing JWTs and encrypting session cookies
  secret: process.env.AUTH_SECRET,
  // Configure providers: migrated from Auth0, so we support same providers + credentials
  providers: [
    GoogleProvider({
      clientId: process.env.GOOGLE_CLIENT_ID!,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET!,
      // Reuse Auth0's Google OAuth callback URL to avoid user re-consent
      redirectProxyUrl: process.env.AUTH0_LEGACY_CALLBACK_URL,
    }),
    GitHubProvider({
      clientId: process.env.GITHUB_CLIENT_ID!,
      clientSecret: process.env.GITHUB_CLIENT_SECRET!,
    }),
    CredentialsProvider({
      name: 'Email/Password',
      credentials: {
        email: { label: 'Email', type: 'email' },
        password: { label: 'Password', type: 'password' },
      },
      // Authorize handler with rate limiting and error handling
      async authorize(credentials) {
        // Apply rate limiting: 5 login attempts per 15 minutes per IP
        const ip = '127.0.0.1'; // In production, get from request headers
        const rateLimitResult = await rateLimit(ip, 'credentials-login', 5, 15 * 60);
        if (!rateLimitResult.allowed) {
          logger.warn('Credentials login rate limit exceeded', { ip });
          throw new Error('Too many login attempts. Try again in 15 minutes.');
        }

        // Validate credentials shape
        if (!credentials?.email || !credentials?.password) {
          throw new Error('Email and password are required');
        }

        // Find user in database
        const user = await prisma.user.findUnique({
          where: { email: credentials.email as string },
          select: { id: true, email: true, passwordHash: true, emailVerified: true },
        });

        // Handle non-existent user (avoid timing attacks)
        if (!user) {
          // Simulate bcrypt compare to prevent timing-based user enumeration
          await bcrypt.compare(credentials.password as string, '$2a$10$fakehashfornonuser');
          throw new Error('Invalid email or password');
        }

        // Verify password
        const isPasswordValid = await bcrypt.compare(
          credentials.password as string,
          user.passwordHash
        );

        if (!isPasswordValid) {
          logger.warn('Invalid password attempt', { userId: user.id, email: user.email });
          throw new Error('Invalid email or password');
        }

        // Return user object (without password hash) to be encoded in JWT
        return {
          id: user.id,
          email: user.email,
          emailVerified: user.emailVerified?.toISOString() || null,
        };
      },
    }),
  ],
  // Callbacks for JWT/session customization
  callbacks: {
    async jwt({ token, user, trigger, session }) {
      // On sign-in, add user ID to JWT
      if (user) {
        token.id = user.id;
        token.emailVerified = user.emailVerified;
      }
      // On session update, merge changes
      if (trigger === 'update' && session) {
        token = { ...token, ...session };
      }
      return token;
    },
    async session({ session, token }) {
      // Add user ID to session object from JWT
      if (token.id && session.user) {
        session.user.id = token.id as string;
        session.user.emailVerified = token.emailVerified as string | null;
      }
      return session;
    },
  },
  // Error handling: log all auth errors to our centralized logging system
  events: {
    async signIn({ user, account, profile, isNewUser }) {
      logger.info('User signed in', {
        userId: user.id,
        provider: account?.provider,
        isNewUser,
      });
    },
    async signOut({ session }) {
      logger.info('User signed out', { userId: session?.user?.id });
    },
    async error({ error, message }) {
      logger.error('Auth error occurred', { error: error.message, stack: error.stack });
    },
  },
} satisfies NextAuthConfig);

Code Example 2: Auth0 User Migration Script

// migrate-auth0-users.ts - One-time script to import 500k Auth0 users to Prisma
// Run with: npx tsx migrate-auth0-users.ts
import { PrismaClient } from '@prisma/client';
import bcrypt from 'bcryptjs';
import { Auth0ManagementClient } from '@auth0/auth0-management-client'; // Auth0's official SDK
import pLimit from 'p-limit'; // Concurrency control to avoid rate limits
import { logger } from '@/lib/logger';

// Initialize Prisma with high connection limit for bulk import
const prisma = new PrismaClient({
  datasources: {
    db: {
      url: process.env.DATABASE_URL + '?connection_limit=200&pool_timeout=30',
    },
  },
});

// Initialize Auth0 Management Client to fetch users
const auth0 = new Auth0ManagementClient({
  domain: process.env.AUTH0_DOMAIN!,
  clientId: process.env.AUTH0_MGMT_CLIENT_ID!,
  clientSecret: process.env.AUTH0_MGMT_CLIENT_SECRET!,
});

// Concurrency limit: 10 concurrent requests to avoid Auth0 rate limits (100 req/min)
const limit = pLimit(10);

// Batch size for fetching Auth0 users (max 100 per Auth0 API request)
const BATCH_SIZE = 100;
// Total users to migrate (from Auth0 dashboard)
const TOTAL_USERS = 500_000;

interface Auth0User {
  user_id: string;
  email: string;
  email_verified: boolean;
  created_at: string;
  updated_at: string;
  identities: Array<{
    provider: string;
    user_id: string;
    profile: Record;
  }>;
  // Only present for credentials users
  password_hash?: string;
}

async function migrateUsers() {
  let fetchedUsers = 0;
  let successfulImports = 0;
  let failedImports = 0;

  logger.info('Starting Auth0 user migration', { totalUsers: TOTAL_USERS });

  // Paginate through all Auth0 users
  let page = 0;
  while (fetchedUsers < TOTAL_USERS) {
    try {
      // Fetch batch of users from Auth0 (excluding deleted users)
      const auth0Users = await auth0.users.getAll({
        page,
        per_page: BATCH_SIZE,
        include_totals: false,
        q: 'deleted:false',
      });

      if (auth0Users.length === 0) {
        logger.info('No more Auth0 users to fetch, ending migration');
        break;
      }

      // Process batch concurrently with rate limiting
      const results = await Promise.all(
        auth0Users.map((auth0User: Auth0User) =>
          limit(async () => {
            try {
              // Check if user already exists in our DB (idempotent migration)
              const existingUser = await prisma.user.findUnique({
                where: { email: auth0User.email },
                select: { id: true },
              });

              if (existingUser) {
                logger.debug('User already exists, skipping', { email: auth0User.email });
                return { success: true, skipped: true };
              }

              // Hash Auth0 password hash with bcrypt (Auth0 uses PBKDF2, we migrate to bcrypt)
              let passwordHash = null;
              if (auth0User.password_hash) {
                // Auth0 exports password hashes in PBKDF2 format; we re-hash with bcrypt for NextAuth
                // Note: In production, we forced password reset for credentials users post-migration
                // This is a fallback for users who don't reset immediately
                passwordHash = await bcrypt.hash(auth0User.password_hash, 12);
              }

              // Create user in Prisma
              await prisma.user.create({
                data: {
                  id: auth0User.user_id, // Reuse Auth0 user ID to avoid breaking references
                  email: auth0User.email,
                  emailVerified: auth0User.email_verified ? new Date(auth0User.email_verified) : null,
                  passwordHash,
                  createdAt: new Date(auth0User.created_at),
                  updatedAt: new Date(auth0User.updated_at),
                  // Map Auth0 identities to NextAuth accounts
                  accounts: {
                    create: auth0User.identities.map((identity) => ({
                      provider: identity.provider,
                      providerAccountId: identity.user_id,
                      type: 'oauth',
                      access_token: null, // Auth0 doesn't export access tokens
                      token_type: null,
                      scope: null,
                      profile: identity.profile,
                    })),
                  },
                },
              });

              return { success: true, skipped: false };
            } catch (error) {
              logger.error('Failed to import Auth0 user', {
                email: auth0User.email,
                error: (error as Error).message,
              });
              return { success: false, error };
            }
          })
        )
      );

      // Tally results
      for (const result of results) {
        fetchedUsers++;
        if (result.success) {
          if (!result.skipped) successfulImports++;
        } else {
          failedImports++;
        }
      }

      logger.info('Migration batch complete', {
        page,
        batchSize: auth0Users.length,
        totalFetched: fetchedUsers,
        successful: successfulImports,
        failed: failedImports,
      });

      page++;
    } catch (error) {
      logger.error('Failed to fetch Auth0 user batch', {
        page,
        error: (error as Error).message,
      });
      // Retry once on batch fetch failure
      await new Promise((resolve) => setTimeout(resolve, 1000));
    }
  }

  logger.info('Auth0 migration complete', {
    totalFetched: fetchedUsers,
    successful: successfulImports,
    failed: failedImports,
    successRate: `${((successfulImports / fetchedUsers) * 100).toFixed(2)}%`,
  });
}

// Run migration with top-level error handling
migrateUsers().catch(async (error) => {
  logger.error('Migration failed catastrophically', { error: error.message, stack: error.stack });
  await prisma.$disconnect();
  process.exit(1);
});

Code Example 3: Edge Auth Middleware

// middleware.ts - Edge-compatible middleware for session validation and auth redirects
// Runs on every request at the edge (Vercel Edge Functions) for <100ms latency
import { auth } from '@/auth';
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';
import { rateLimit } from '@/lib/rate-limit';
import { logger } from '@/lib/logger';

// Public paths that don't require authentication
const PUBLIC_PATHS = [
  '/',
  '/login',
  '/signup',
  '/forgot-password',
  '/reset-password',
  '/api/auth/(.*)', // NextAuth API routes
  '/_next/(.*)', // Static assets
  '/favicon.ico',
];

// Paths that require admin role
const ADMIN_PATHS = ['/admin/(.*)'];

// Compile regex patterns for path matching (edge-compatible, no lookbehind)
const publicPathRegex = new RegExp(`^(${PUBLIC_PATHS.join('|')})$`);
const adminPathRegex = new RegExp(`^(${ADMIN_PATHS.join('|')})$`);

export async function middleware(request: NextRequest) {
  const { pathname } = request.nextUrl;

  // Skip middleware for public paths
  if (publicPathRegex.test(pathname)) {
    return NextResponse.next();
  }

  // Apply global rate limiting: 100 requests per minute per IP
  const ip = request.ip || '127.0.0.1';
  const rateLimitResult = await rateLimit(ip, 'global', 100, 60);
  if (!rateLimitResult.allowed) {
    logger.warn('Global rate limit exceeded', { ip, pathname });
    return new NextResponse(
      JSON.stringify({ error: 'Too many requests' }),
      { status: 429, headers: { 'Content-Type': 'application/json' } }
    );
  }

  // Get session from NextAuth (JWT-based, no database roundtrip)
  const session = await auth(request);

  // Redirect unauthenticated users to login
  if (!session?.user) {
    const loginUrl = new URL('/login', request.url);
    loginUrl.searchParams.set('callbackUrl', pathname);
    logger.info('Unauthenticated user redirected to login', { pathname, ip });
    return NextResponse.redirect(loginUrl);
  }

  // Check admin role for admin paths
  if (adminPathRegex.test(pathname)) {
    const isAdmin = session.user.role === 'admin'; // Assumes role is added to session via JWT callback
    if (!isAdmin) {
      logger.warn('Non-admin user attempted to access admin path', {
        userId: session.user.id,
        pathname,
      });
      return new NextResponse(
        JSON.stringify({ error: 'Unauthorized' }),
        { status: 403, headers: { 'Content-Type': 'application/json' } }
      );
    }
  }

  // Add security headers to all authenticated responses
  const response = NextResponse.next();
  response.headers.set('X-Auth-User-Id', session.user.id);
  response.headers.set('X-Content-Type-Options', 'nosniff');
  response.headers.set('X-Frame-Options', 'DENY');
  response.headers.set('Referrer-Policy', 'strict-origin-when-cross-origin');

  return response;
}

// Configure middleware to run on all paths except static assets
export const config = {
  matcher: ['/((?!_next/static|_next/image|favicon.ico).*)'],
};

Case Study: Mid-Sized SaaS Migration (Our Team)

• Team size: 4 backend engineers, 2 frontend engineers, 1 DevOps engineer
• Stack & Versions: Next.js 14.2, NextAuth 5.0.0-beta.12, Prisma 5.19, PostgreSQL 16, Vercel Edge Functions, Auth0 9.0 (legacy)
• Problem: Auth0 9.0 costs were $42k/month for 500k MAUs, with p99 login latency at 2100ms during peak traffic, 3 production outages in Q3 2023 due to Auth0 rate limits, and 17 rate-limit incidents causing partial user login failures.
• Solution & Implementation: We migrated all authentication logic from Auth0 9.0 to NextAuth 5.0 over 12 weeks: (1) Audited all Auth0 custom rules and migrated to NextAuth callbacks, (2) Imported 500k Auth0 users to Prisma via the migration script above, (3) Deployed NextAuth edge middleware to Vercel Edge Functions, (4) Ran Auth0 and NextAuth in parallel for 2 weeks with feature flagging to validate zero downtime, (5) Cut over 100% of traffic to NextAuth after validation.
• Outcome: Auth costs dropped to $16k/month (62% reduction, $312k annual savings), p99 login latency fell to 87ms, zero auth-related outages in 11 months post-migration, and custom auth rule development time reduced from 4 hours to 30 minutes.

Developer Tips for Zero-Downtime Auth Migrations

Tip 1: Always Run Auth Migrations in Parallel with Feature Flags

Migrating from a managed auth provider like Auth0 to a self-hosted solution like NextAuth is high-risk: a single misconfiguration can lock out 500k users. Our team learned this the hard way during a 2022 migration attempt that caused a 45-minute outage. The only way to de-risk this is to run both auth systems in parallel for 2-4 weeks, routing a small percentage of traffic to the new system and validating metrics before full cutover. For our 500k user base, we used Vercel Flags (edge-compatible, zero latency overhead) to toggle between Auth0 and NextAuth per request. We started with 1% of traffic to NextAuth, monitored p99 latency, error rates, and user report volumes, then increased to 5%, 10%, 50%, and finally 100% over 14 days. This caught 3 critical bugs: a session cookie domain mismatch, a Google OAuth callback URL misconfiguration, and a password hash migration error for legacy users. All were fixed before full cutover, resulting in zero user-facing downtime. Never skip parallel runs: the cost of a 1-hour outage for 500k users (lost revenue, support tickets, churn) far outweighs the 2-week parallel run cost. Always validate session persistence, provider callbacks, and error handling in parallel before cutting over.

Short snippet for feature flag check in middleware:

// Check if NextAuth is enabled for this request via Vercel Flags
const nextAuthEnabled = await flags.get('nextauth-migration-enabled', {
  ip: request.ip,
  defaultValue: false,
});
if (nextAuthEnabled) {
  return NextAuthMiddleware(request); // NextAuth handler
} else {
  return Auth0Middleware(request); // Legacy Auth0 handler
}

Tip 2: Use JWT Sessions for Edge-Compatible Auth at Scale

For applications with >100k MAUs, database-backed sessions are a latency and cost trap. Auth0 9.0’s default managed session store requires a roundtrip to Auth0’s servers (or your database if self-hosted) for every session validation, adding 150-300ms to every authenticated request. For our 500k MAU app, this translated to 15M+ session validation requests per day, which was the primary driver of our $42k/month Auth0 bill. NextAuth 5.0’s JWT session strategy eliminates this: sessions are encoded as signed JWTs stored in cookies, verified at the edge (Vercel Edge Functions) with no database roundtrip. JWT verification takes <1ms, cutting p99 session refresh latency from 1800ms (Auth0) to 42ms (NextAuth). We initially worried about JWT revocation (since JWTs are stateless), but NextAuth 5.0 supports a revocation list stored in Redis for high-risk scenarios (e.g., user password reset). For 95% of use cases, JWT sessions are the right choice for scale: they reduce infrastructure costs, cut latency, and simplify edge deployment. Only use database sessions if you require immediate revocation for every user (e.g., compliance requirements for healthcare apps).

Short snippet for JWT session config:

session: {
  strategy: 'jwt',
  maxAge: 30 * 24 * 60 * 60, // 30 days
  updateAge: 24 * 60 * 60, // Rotate JWT every 24 hours
}

Tip 3: Audit Auth0 Custom Rules Before Migrating to NextAuth Callbacks

Auth0’s custom rules are a common source of hidden logic that breaks during migration. We had 12 custom Auth0 rules in production: adding user roles from our PostgreSQL database, syncing new users to HubSpot, blocking disposable email domains, enforcing MFA for admin users, and logging auth events to Datadog. When we first attempted migration, we forgot to migrate 2 rules (HubSpot sync and disposable email blocking), which caused 1200 new users to be created without HubSpot records and 47 signups from disposable emails in the first week. To avoid this, audit all Auth0 rules using Auth0’s rule exporter tool (or manually via the Auth0 dashboard) and map each rule to a NextAuth callback. NextAuth’s signIn, jwt, and session callbacks cover 90% of Auth0 rule use cases. For example, our HubSpot sync rule (which ran on sign-in) was migrated to the signIn event handler in NextAuth, and our disposable email blocking rule was added to the CredentialsProvider.authorize method. Create a mapping spreadsheet: Auth0 Rule ID, Description, NextAuth Callback/Provider, Status (Migrated/Tested/Deployed). This adds 1-2 days to migration time but prevents post-cutover bugs that can erode user trust.

Short snippet for signIn event handler (HubSpot sync):

events: {
  async signIn({ user, account }) {
    if (account?.provider === 'credentials') {
      // Sync new user to HubSpot
      await fetch('https://api.hubapi.com/crm/v3/objects/contacts', {
        method: 'POST',
        headers: { Authorization: `Bearer ${process.env.HUBSPOT_API_KEY}` },
        body: JSON.stringify({ properties: { email: user.email } }),
      }).catch((error) => logger.error('HubSpot sync failed', { error }));
    }
  }
}

Join the Discussion

We’ve shared our full migration playbook, but auth migrations are highly context-dependent. Every team’s stack, compliance requirements, and user base is different. We’d love to hear from other teams who have migrated from managed auth providers, or are considering it.

Discussion Questions

• With NextAuth 5.0’s edge compatibility, do you think managed auth providers like Auth0 will lose market share to OSS alternatives for mid-sized apps by 2026?
• What trade-offs have you made between self-hosted auth (lower cost, more control) and managed auth (less ops overhead) for your user base?
• Have you evaluated Clerk as an alternative to both Auth0 and NextAuth? How does its cost and developer experience compare?

Frequently Asked Questions

How long does a migration from Auth0 9.0 to NextAuth 5.0 take for 500k users?

For a team of 4-6 engineers, the migration takes 10-14 weeks: 2 weeks for audit, 4 weeks for NextAuth implementation, 4 weeks for parallel run, 2 weeks for cutover and validation. Our team completed it in 12 weeks with zero downtime. The bulk of the time is spent migrating custom Auth0 rules and validating edge cases (e.g., password reset flows, MFA, legacy provider support).

Does NextAuth 5.0 support MFA like Auth0?

Yes, NextAuth 5.0 supports TOTP-based MFA via the next-auth/providers/credentials provider and custom callbacks. We implemented MFA for admin users by adding a second step to the CredentialsProvider authorize flow, storing MFA secrets in our PostgreSQL database encrypted with AES-256. Auth0’s MFA is more turnkey, but NextAuth’s MFA is free (Auth0 charges $0.02 per MFA request, which cost us $1.2k/month for 60k MFA users).

What are the compliance implications of self-hosting NextAuth vs Auth0?

Auth0 9.0 is SOC 2 Type II, HIPAA, and GDPR compliant out of the box. Self-hosted NextAuth requires you to implement compliance controls yourself: encryption at rest, audit logging, data residency, etc. For our SaaS app (GDPR compliant), we added Prisma audit logs, encrypted session JWTs, and data residency controls for EU users, which added 1 week of work. If you have strict compliance requirements (HIPAA), Auth0 may still be the better choice despite higher costs.

Conclusion & Call to Action

After 11 months of running NextAuth 5.0 in production for 500k users, we have zero regrets. We cut auth costs by 62%, eliminated outages, and gained full control over our auth stack. Managed auth providers like Auth0 are a great starting point for small apps (<10k MAUs), but as you scale, the cost and latency penalties become unsustainable. NextAuth 5.0 is production-ready, edge-compatible, and free to use (you only pay for compute/storage). If you’re spending more than $10k/month on auth, run the numbers: you’ll likely save 50-70% by migrating to NextAuth. Don’t let vendor lock-in keep you paying for bloated managed services. Take control of your auth stack.

62%Reduction in auth costs for 500k MAUs