Migrating Auth from Vite to Next.js: Supabase, Clerk, and Auth.js Patterns That Actually Work

The Architectural Shift in Authentication

When you move a project from Vite to Next.js, you aren't just changing a build tool; you are shifting your application's gravity from the Client to the Server. In a standard Vite + React SPA, authentication is almost entirely client-side. You likely store tokens in localStorage, manage state via a useAuth hook, and protect routes using client-side redirects.

In Next.js, authentication lives in the Request/Response cycle. Because of Server Components and Middleware, you have to sync your auth state across three different environments: the Browser, the Edge/Middleware, and the Node.js Server.

This guide breaks down how to migrate your auth patterns for the three most popular providers while maintaining security and performance.

1. Supabase: Moving from supabase-js to @supabase/auth-helpers-nextjs

In Vite, you probably initialized a single supabase client in a utility file. In Next.js, you must use a client creator pattern to ensure that cookies are correctly passed between the client and server.

The Vite Way (Client Only)

// lib/supabase.ts
import { createClient } from '@supabase/supabase-js';
export const supabase = createClient(URL, ANON_KEY);

The Next.js Way (Server-Side Logic)

You should now use the SSR-ready libraries. The critical change is ensuring your Middleware refreshes the session before it expires, as Server Components cannot set cookies.

// middleware.ts
import { createMiddlewareClient } from '@supabase/auth-helpers-nextjs';
import { NextResponse } from 'next/server';

export async function middleware(req) {
  const res = NextResponse.next();
  const supabase = createMiddlewareClient({ req, res });
  await supabase.auth.getSession();
  return res;
}

Migration Tip: If you find the manual rewriting of these API routes and middleware wrappers tedious, tools like ViteToNext.AI can help automate the boilerplate migration of your Vite logic into a Next.js App Router structure.

2. Clerk: From Frontend API to Edge Middleware

Clerk is arguably the easiest to migrate because it handles the heavy lifting, but the implementation pattern changes significantly. In Vite, you likely wrapped your app in <ClerkProvider>. In Next.js, you move the protection layer to the middleware.ts file.

Key Migration Steps:

1. Remove ProtectedRoute components: In Vite, you might have a component that checks if (!user) return <Redirect />. In Next.js, use authMiddleware() to block unauthorized requests before they even reach the page component.
2. Server Components Context: Use auth() for Server Components and useAuth() for Client Components.

// app/dashboard/page.tsx
import { auth } from "@clerk/nextjs";

export default function Page() {
  const { userId } = auth();
  // This happens on the server, no loading spinner needed!
  return <div>Welcome, {userId}</div>;
}

3. Auth.js (NextAuth): The Full-Stack Strategy

If you were using a custom JWT solution or Firebase in Vite, migrating to Auth.js is the standard recommendation for Next.js. Auth.js is built specifically for the Next.js lifecycle.

The Transition Pattern

Instead of managing a token in localStorage (which is invisible to the server), Auth.js uses HttpOnly cookies.

• Vite: Fetching data involves sending an Authorization: Bearer <token> header.
• Next.js: Server Components automatically have access to the session cookie. You can fetch data directly in the component without an internal API route.

// app/api/auth/[...nextauth]/route.ts
import NextAuth from "next-auth";

const handler = NextAuth({
  providers: [...],
  callbacks: {
    session: ({ session, token }) => ({
      ...session,
      user: { ...session.user, id: token.sub },
    }),
  },
});
export { handler as GET, handler as POST };

Handling Protected Routes

In a Vite SPA, you usually define protected routes in App.tsx using a custom Route wrapper. In Next.js, you have two cleaner options:

1. Middleware (Global): Best for blocking entire segments (e.g., /dashboard/*).
2. Layout Redirection (Local): Best for fine-grained control inside specific Route Groups.

// app/(dashboard)/layout.tsx
export default async function DashboardLayout({ children }) {
  const session = await getServerSession();
  if (!session) redirect("/login");
  return <>{children}</>;
}

Conclusion

Migrating auth from Vite to Next.js is primarily a shift from "managing state" to "managing cookies." By leveraging Middleware and Server Components, you eliminate the "flicker" of unauthenticated content and improve your app's security posture by keeping sensitive tokens out of localStorage.

Whether you choose Supabase for its backend-as-a-service features, Clerk for its polished UI, or Auth.js for its flexibility, the goal is the same: leverage the server to handle identity.

Further reading: ViteToNext.AI Migration Guide