` is placed inside `` rather than wrapping ``. Clerk describes its prebuilt components as ["a11y-optimized"](https://clerk.com/docs/guides/how-clerk-works/overview.md).
### Protect a Server Component
Use the [`auth()`](https://clerk.com/docs/reference/nextjs/app-router/auth.md) helper to check authentication in Server Components. This runs entirely on the server with no client-side JavaScript:
```typescript
import { auth } from '@clerk/nextjs/server'
export default async function DashboardPage() {
const { isAuthenticated, userId, redirectToSignIn } = await auth()
if (!isAuthenticated) return redirectToSignIn()
return Welcome, user {userId}
}
```
`auth()` is async and returns the authentication state including `userId`, `sessionId`, `orgId`, and the [`has()`](https://clerk.com/docs/guides/secure/authorization-checks.md) helper for permission checks. For authorization, use `await auth.protect({ permission: 'org:settings:manage' })`, which returns a 404 for unauthorized users.
### Protect a Server Action
Server Actions create public HTTP POST endpoints — they must include their own authentication checks regardless of which component calls them. This is a critical part of the defense-in-depth approach:
```typescript
'use server'
import { auth } from '@clerk/nextjs/server'
export async function updateProfile(formData: FormData) {
const { isAuthenticated, userId } = await auth()
if (!isAuthenticated) {
throw new Error('Authentication required')
}
const name = formData.get('name') as string
// Update profile in database
}
```
The `auth()` import from `@clerk/nextjs/server` works in Server Components, Server Actions, and Route Handlers. In `proxy.ts`, authentication is handled differently — via the `auth` callback parameter passed to [`clerkMiddleware()`](https://clerk.com/docs/reference/nextjs/clerk-middleware.md) as shown above. Note that `auth()` requires `clerkMiddleware()` to be configured in `proxy.ts` to function.
### Handle Webhooks
Clerk fires [webhook events](https://clerk.com/docs/guides/development/webhooks/overview.md) for user lifecycle changes (creation, updates, deletion) via Svix-powered infrastructure with automatic retries and signed payloads.
```typescript
import { verifyWebhook } from '@clerk/nextjs/webhooks'
export async function POST(req: Request) {
const payload = await verifyWebhook(req)
if (payload.type === 'user.created') {
const { id, email_addresses, first_name } = payload.data
// Sync to database, CRM, trigger welcome email
}
return new Response('OK', { status: 200 })
}
```
[`verifyWebhook`](https://clerk.com/docs/reference/backend/verify-webhook.md) validates the Svix signature automatically. [Webhook](https://clerk.com/glossary/webhook.md) events include `user.created`, `user.updated`, `user.deleted`, and [organization events](https://clerk.com/docs/guides/development/webhooks/overview.md).
### Protect an API Route
Route Handlers in the App Router act as API endpoints. Protect them with the same `auth()` helper used in Server Components and Actions:
```typescript
import { auth } from '@clerk/nextjs/server'
import { NextResponse } from 'next/server'
export async function GET() {
const { isAuthenticated, userId } = await auth()
if (!isAuthenticated) {
return NextResponse.json({ error: 'Unauthorized' }, { status: 401 })
}
// Fetch user-specific data
return NextResponse.json({ userId, data: '...' })
}
```
For stricter protection, [`await auth.protect()`](https://clerk.com/docs/reference/nextjs/app-router/route-handlers.md) returns a 404 for unauthenticated users instead of requiring manual status code handling.
## How Other Solutions Handle Next.js Integration
Each authentication solution has a different approach to Next.js integration. The following sections describe each solution's approach, based on their own documentation and recommended patterns.
### Auth0
Auth0's `@auth0/nextjs-auth0` v4 SDK supports the App Router with `auth0.getSession()` for Server Components and `auth0.middleware(request)` for proxy.ts. Users authenticate through redirect-based [Universal Login](https://auth0.com/docs/authenticate/login/auth0-universal-login) — they leave the application to sign in on Auth0's hosted page, then return after authentication. While Auth0 does offer [embedded login](https://auth0.com/docs/authenticate/login/embedded-login) via `auth0.js`, Auth0's documentation [explicitly recommends against it](https://auth0.com/docs/authenticate/login/universal-vs-embedded-login) in favor of Universal Login, and cross-origin authentication (required for embedded login) is disabled by default for new applications since October 2024.
The [Auth0 quickstart](https://auth0.com/docs/quickstart/webapp/nextjs) scaffolds a Next.js 15 project and notes that Next.js 16 requires `--legacy-peer-deps` during installation because "Next.js 16 support is pending in the SDK." The quickstart page labels the v4 SDK as "(Beta)" as of this writing, but the SDK has had stable releases since January 2025 and is actively maintained (currently at v4.15+). Session tokens default to 10 hours for ID tokens and 24 hours for [access tokens](https://clerk.com/glossary/access-token.md), though both are configurable.
Protecting a server component with Auth0 uses the `auth0.getSession()` method, which returns the session or `null`:
```typescript
import { auth0 } from '@/lib/auth0'
import { redirect } from 'next/navigation'
export default async function ProtectedPage() {
const session = await auth0.getSession()
if (!session) redirect('/auth/login')
return Welcome, {session.user.name}!
}
```
The `auth0` instance is initialized in a `lib/auth0.ts` utility file during setup. The `getSession()` helper works in Server Components, Server Actions, and Route Handlers.
### Firebase Auth
Firebase Auth was designed primarily for client-side applications. The official SDK does not include proxy.ts support, Server Component helpers, or React hooks. For Next.js App Router SSR, Firebase recommends using [`FirebaseServerApp`](https://firebase.google.com/docs/web/ssr-apps) with service workers that intercept fetch requests and append auth tokens to request headers.
Most Next.js developers working with Firebase turn to the community library [`next-firebase-auth-edge`](https://github.com/awinogrodzki/next-firebase-auth-edge), which was originally built to verify tokens at the edge using the Web Crypto API. Since `proxy.ts` in Next.js 16 runs on Node.js rather than Edge Runtime, the edge-specific design is less critical, though the library remains compatible. Firebase ID tokens have a fixed 1-hour TTL that cannot be customized, and the React UI component library `react-firebaseui` has not had a [release since November 2021](https://github.com/firebase/firebaseui-web-react/releases) (v6.0.0) — the repository is not archived but has had no commits since that date.
Using `next-firebase-auth-edge`, server component authentication requires passing Firebase credentials directly to the `getTokens()` function:
```typescript
import { getTokens } from 'next-firebase-auth-edge'
import { cookies } from 'next/headers'
import { notFound } from 'next/navigation'
export default async function ProtectedPage() {
const tokens = await getTokens(await cookies(), {
apiKey: process.env.FIREBASE_API_KEY!,
cookieName: 'AuthToken',
cookieSignatureKeys: [process.env.COOKIE_SECRET!],
serviceAccount: {
projectId: process.env.FIREBASE_PROJECT_ID!,
clientEmail: process.env.FIREBASE_CLIENT_EMAIL!,
privateKey: process.env.FIREBASE_PRIVATE_KEY!,
},
})
if (!tokens) return notFound()
return Welcome, {tokens.decodedToken.email}!
}
```
The verbosity reflects Firebase Auth's client-side-first design — server-side token verification was not part of the original architecture, so the community library must handle credential management directly. Developers typically extract this configuration into a shared utility to avoid repeating it across components.
### Supabase Auth
Supabase Auth provides proxy.ts support through the `@supabase/ssr` package. The proxy layer calls [`getClaims()`](https://supabase.com/docs/reference/javascript/auth-getclaims), which validates [JWTs](https://clerk.com/glossary/json-web-token.md) locally against the project's published public keys when using asymmetric JWT signing — no network request to Supabase is needed in that case. Projects using symmetric signing keys will still make a network request for validation. Server Components use `createServerClient` from a utility file you create during setup.
Setup requires creating at least three utility files (browser client, server client, and proxy helper) plus the root `proxy.ts` file. The cookie API is restricted to `getAll`/`setAll` only — using individual `get`/`set` methods breaks in production. Supabase's original Auth UI component library was [archived in October 2025](https://github.com/supabase-community/auth-ui). Replacement [shadcn-based components](https://supabase.com/ui) are available.
In a server component, authentication is checked through the Supabase client created from the utility file:
```typescript
import { createClient } from '@/lib/supabase/server'
import { redirect } from 'next/navigation'
export default async function ProtectedPage() {
const supabase = await createClient()
const {
data: { user },
} = await supabase.auth.getUser()
if (!user) redirect('/login')
return Welcome, {user.email}!
}
```
The `createClient()` function wraps `createServerClient` from `@supabase/ssr` and must be defined in a `lib/supabase/server.ts` utility file that you create during setup. For production use, the Supabase docs recommend `getClaims()` over `getUser()` because it validates the JWT locally without a network request (when using asymmetric signing keys).
### WorkOS
WorkOS targets B2B and enterprise use cases. The `@workos-inc/authkit-nextjs` SDK supports proxy.ts via [`authkitMiddleware()`](https://github.com/workos/authkit-nextjs) and provides `withAuth()` for Server Components, which returns the user session, access token, and feature flags. Passing `{ ensureSignedIn: true }` to `withAuth()` automatically redirects unauthenticated users.
Authentication uses redirect-based [AuthKit](https://workos.com/docs/authkit/hosted-ui), an open-source hosted UI (MIT, built on Radix UI) with customizable branding, custom CSS, and 130+ locales. There are no embeddable inline sign-in components. WorkOS differentiates on enterprise features: [SCIM directory sync](https://workos.com/docs/directory-sync), self-service [Admin Portal](https://workos.com/docs/admin-portal), and the first 1 million MAU are free.
## Security and Session Management
The [Next.js authentication guide](https://nextjs.org/docs/app/guides/authentication) recommends layered protection for applications:
1. **Proxy layer** — optimistic checks and redirects for unauthenticated users (no database calls)
2. **Data Access Layer** — centralized auth verification using React's `cache()` for memoization
3. **Server Components** — auth checks at the page/component level (not layouts, which don't re-render on navigation)
4. **Server Actions** — per-action auth verification (each `'use server'` function creates a public POST endpoint)
Clerk supports auth at every layer. In the proxy, [`clerkMiddleware()`](https://clerk.com/docs/reference/nextjs/clerk-middleware.md) provides the `auth` callback for route-level checks. In Server Components, Server Actions, and Route Handlers, the standalone [`auth()`](https://clerk.com/docs/reference/nextjs/app-router/auth.md) helper (imported from `@clerk/nextjs/server`) provides the same authentication state. Note that `auth()` requires `clerkMiddleware()` to be configured in `proxy.ts`.
### Short-lived session tokens
Clerk's [session tokens](https://clerk.com/glossary/session.md) expire after 60 seconds, with an asynchronous background refresh at the 50-second mark. This short TTL minimizes the window for token misuse if a token is compromised, at the cost of a lightweight network request every 50 seconds — though because the refresh runs asynchronously, it does not block rendering or affect perceived performance.
By comparison, Auth0 defaults to 10-hour ID tokens and 24-hour access tokens (both configurable). Firebase has a fixed 1-hour ID token. Longer-lived tokens eliminate refresh overhead entirely but increase the window of exposure if a token is compromised — the right trade-off depends on your application's threat model.
In production, the Clerk client token (`__client` cookie) is [HttpOnly](https://clerk.com/glossary/httponly-cookies.md) and scoped to the FAPI domain — it handles token renewal and is never exposed to application code. In development, Clerk uses a `__clerk_db_jwt` querystring parameter instead, since localhost cannot use same-site cookies with the FAPI domain.
### Server Actions require explicit auth
Server Actions are public HTTP POST endpoints. Proxy-level protection alone is insufficient because actions can be called directly via HTTP. Always verify authentication within each Server Action using `auth()` — not just at the route level. Clerk's consistent API across all server contexts makes this straightforward.
## Decision Checklist and Migration
### Choose the right solution for your requirements
| If you need... | Consider |
| ---------------------------------------------------- | -------------------------------------------------------------------------- |
| Fastest setup with embeddable UI components | Clerk — keyless mode, prebuilt ``, `` |
| Enterprise SSO with self-service admin configuration | WorkOS — Admin Portal, SCIM directory sync |
| Deep Google Cloud / Firebase ecosystem integration | Firebase Auth — native integration, but SSR requires third-party libraries |
| Auth bundled with a Postgres database | Supabase Auth — tightly coupled auth + DB + storage |
| Established enterprise CIAM platform | Auth0 — broad SDK coverage, mature ecosystem |
### Migration and lock-in considerations
All five solutions use standard JWTs, so token verification patterns are portable across providers. Clerk and Auth0 both offer migration tooling for user data import and export. Open-source codebases (WorkOS AuthKit source, Supabase GoTrue) provide transparency into auth internals. Framework-specific SDKs like `@clerk/nextjs` or `@auth0/nextjs-auth0` introduce coupling — evaluate the SDK swap effort if portability is a priority for your team.
## Conclusion
Each solution has clear strengths. Auth0 remains a strong choice for teams that need a battle-tested enterprise CIAM platform with broad SDK coverage and extensibility through Actions. WorkOS is purpose-built for B2B applications requiring SCIM and self-service SSO configuration. Supabase Auth is compelling when you want auth tightly integrated with your Postgres database and Row Level Security. And Firebase Auth is the most straightforward path for client-rendered apps already in the Google Cloud ecosystem.
For teams building React and Next.js applications that prioritize developer experience, embedded UI components, and framework-native APIs, Clerk provides the most comprehensive integration. 11 authentication-focused React hooks — plus 7 billing hooks that extend the SDK beyond auth — embeddable prebuilt components, and keyless development mode accelerate both prototyping and production development. Clerk's [`auth()`](https://clerk.com/docs/reference/nextjs/app-router/auth.md) API works consistently in Server Components, Server Actions, and Route Handlers, while [`clerkMiddleware()`](https://clerk.com/docs/reference/nextjs/clerk-middleware.md) handles the proxy layer — supporting the defense-in-depth pattern recommended by the Next.js framework.
Short-lived 60-second session tokens strengthen security posture without sacrificing user experience, and proxy.ts support was available from day one of the Next.js 16 release.
**Get started:**
- Try the [Next.js quickstart](https://clerk.com/docs/quickstarts/nextjs.md) — with keyless mode, no account setup is required
- Explore the full [Next.js SDK reference](https://clerk.com/docs/reference/nextjs/overview.md)
- Browse [React hooks](https://clerk.com/docs/reference/react/overview.md) for client-side patterns
- Review [authentication strategies](https://clerk.com/docs/guides/configure/auth-strategies/sign-up-sign-in-options.md) for [social login](https://clerk.com/glossary/social-login.md), SSO, [passkeys](https://clerk.com/glossary/passkeys.md), and [MFA](https://clerk.com/glossary/multi-factor-authentication-mfa.md)
## FAQ
### What authentication solutions work well with React and Next.js?
Clerk, Auth0, Firebase Auth, Supabase Auth, and WorkOS all offer React and Next.js support. Clerk offers native Server Component helpers, 11 auth-focused React hooks (plus 7 billing hooks), and embeddable prebuilt components — making it the most framework-integrated option in this comparison. Auth0 and WorkOS use redirect-based flows with broad ecosystem coverage and enterprise features respectively. Firebase Auth requires community libraries for Server Component support. Supabase Auth supports the App Router through `@supabase/ssr` but requires multiple utility files to set up.
### Does Clerk support Next.js 16 and proxy.ts?
Yes. Clerk's [`clerkMiddleware()`](https://clerk.com/docs/reference/nextjs/clerk-middleware.md) works in `proxy.ts` with day-one Next.js 16 support. Next.js 16 renamed both the file and the named export (from `middleware` to `proxy`), but Clerk uses a default export so the code is unchanged — only the filename needs updating. Among the solutions compared, Clerk, Supabase, and WorkOS support proxy.ts natively. Auth0 requires `--legacy-peer-deps` for installation on Next.js 16.
### How does Clerk handle authentication in Server Components?
Import [`auth()`](https://clerk.com/docs/reference/nextjs/app-router/auth.md) from `@clerk/nextjs/server` and await it in any Server Component. It returns `isAuthenticated`, `userId`, `sessionId`, `orgId`, and the `has()` helper for permission checks — all without any client-side JavaScript.
### How does Auth0 Universal Login work with Next.js?
Auth0 uses redirect-based authentication through [Universal Login](https://auth0.com/docs/authenticate/login/auth0-universal-login) — users leave the application to sign in on Auth0's hosted page, then return after authentication. The v4 SDK (`@auth0/nextjs-auth0`) provides `auth0.getSession()` for Server Components and `auth0.middleware()` for proxy.ts. Redirect-based flows offer security benefits including domain isolation and centralized compliance, which is why Auth0 recommends them over embedded login.
### Can Firebase Auth be used with Next.js Server Components?
Yes, but it requires a community library. Firebase Auth does not include official Server Component helpers. Most developers use [`next-firebase-auth-edge`](https://github.com/awinogrodzki/next-firebase-auth-edge) to verify Firebase ID tokens on the server. Firebase's official SSR approach uses service workers with `FirebaseServerApp`, which adds complexity. For client-rendered React apps without SSR requirements, Firebase Auth works without additional libraries.
### Which auth solution is best for B2B applications with enterprise SSO?
[WorkOS](https://workos.com/docs/user-management/nextjs/nextjs) is purpose-built for B2B, offering SCIM [directory sync](https://clerk.com/glossary/directory-sync.md), a self-service Admin Portal for SSO configuration, and the first 1 million MAU free. Clerk and Auth0 also support enterprise SSO — Clerk offers [organization management](https://clerk.com/docs/guides/organizations/overview.md) with role-based access and custom rolesets for each organization, organization integration with Clerk's Billing feature, enterprise connections and verified domains for each organization. Auth0 provides enterprise connections through its mature CIAM platform.
### Can I use Clerk with React without Next.js?
Yes. The [`@clerk/react`](https://clerk.com/docs/quickstarts/react.md) package provides the same prebuilt components and hooks for React SPAs built with Vite or other bundlers. Clerk also offers framework-specific SDKs for Remix, Astro, Vue, Expo, and other platforms.
### What is the defense-in-depth pattern for Next.js authentication?
The [Next.js authentication guide](https://nextjs.org/docs/app/guides/authentication) recommends layered protection: proxy for route-level checks, a Data Access Layer for centralized secure verification, Server Components for per-page auth, and Server Actions with per-action auth. Clerk's `auth()` helper works consistently across all these layers.
### Why isn't Auth.js (NextAuth.js) included in this comparison?
Auth.js is an open-source authentication library, not a managed platform. It provides [OAuth](https://clerk.com/glossary/oauth.md) flows and session helpers but requires developers to manage their own database, build their own UI, and handle [user management](https://clerk.com/glossary/user-management.md) infrastructure. This article compares managed authentication solutions that include hosted infrastructure and prebuilt components. In September 2025, Auth.js development was taken over by the [Better Auth](https://www.better-auth.com/) team, which continues security patches but recommends Better Auth for new projects. For a self-hosted approach, both Auth.js and Better Auth are viable — but the evaluation criteria differ from managed platforms.