スシロー

Posted on Jul 1

【2026】Auth0 代替 (Clerk/Supabase Auth/WorkOS)：料金・移行コストで選ぶ

#saas #devops #tutorial #webdev

結論（おすすめ1つ）

移行先は Clerk を推奨する。
理由は3点：SDK の完成度が高くフロントエンド統合が最速、React/Next.js プロジェクトであれば既存の Auth0 コードを最小の書き換えで置き換えられる、そしてコンポーネントベースの UI が提供されているためデザイン工数を削減できる。Supabase Auth はデータベースと一体化したいチーム向け、WorkOS は Enterprise SSO が必須な B2B SaaS 向けのニッチな選択肢と位置づけると判断しやすい。

比較表（料金/無料枠/移行コスト/対応言語）

項目	Auth0	Clerk	Supabase Auth	WorkOS
無料枠	公式の料金ページで要確認	公式の料金ページで要確認	公式の料金ページで要確認	公式の料金ページで要確認
有料プラン開始	公式の料金ページで要確認	公式の料金ページで要確認	公式の料金ページで要確認	公式の料金ページで要確認
移行コスト（相対）	基準	低〜中	中（DB 統合が前提）	高（SAML/SCIMの理解が必要）
公式 SDK	Node/Python/Go/Java 他	React/Next.js/Remix 中心	JS/Flutter/Python 他	Node/Python/Ruby 他
MFA 対応	○	○	○	○
Enterprise SSO (SAML)	○	○（高価格帯）	△（外部プロバイダ経由）	◎（コア機能）
セルフホスト	×	×	○	×
JWT カスタマイズ	○	○	○	○

料金は頻繁に改定される。導入前に必ず各社の公式料金ページを確認すること。

移行手順

Auth0 → Clerk への移行を例に、Next.js App Router プロジェクトを想定した手順を示す。

1. Clerk パッケージのインストール

npm install @clerk/nextjs

2. 環境変数の設定

# .env.local
NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_test_xxxx
CLERK_SECRET_KEY=sk_test_xxxx

# Auth0 の既存変数は削除またはコメントアウト
# AUTH0_SECRET=...
# AUTH0_BASE_URL=...

3. ClerkProvider でアプリをラップ

// app/layout.tsx
import { ClerkProvider } from '@clerk/nextjs'

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <ClerkProvider>
      <html lang="ja">
        <body>{children}</body>
      </html>
    </ClerkProvider>
  )
}

4. ミドルウェアによるルート保護

// middleware.ts
import { clerkMiddleware, createRouteMatcher } from '@clerk/nextjs/server'

const isProtectedRoute = createRouteMatcher(['/dashboard(.*)'])

export default clerkMiddleware(async (auth, req) => {
  if (isProtectedRoute(req)) await auth.protect()
})

export const config = {
  matcher: ['/((?!_next|.*\\..*).*)'],
}

5. ユーザー情報の取得（サーバーサイド）

// app/dashboard/page.tsx
import { auth, currentUser } from '@clerk/nextjs/server'

export default async function Dashboard() {
  const { userId } = await auth()
  const user = await currentUser()

  if (!userId) return <p>未認証</p>
  return <p>こんにちは、{user?.firstName} さん</p>
}

6. Auth0 のユーザーデータ移行

Auth0 Management API でユーザーをエクスポートし、Clerk の Backend API または CSV インポート機能で取り込む。パスワードハッシュは Auth0 → Clerk 間で直接移行できないため、初回ログイン時のパスワードリセットフローを必ずユーザーに案内すること。

# Auth0 Management API でユーザーエクスポート（jobs/users-exports エンドポイント）
curl -X POST https://YOUR_DOMAIN.auth0.com/api/v2/jobs/users-exports \
  -H "Authorization: Bearer $AUTH0_MGMT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"connection_id":"con_xxxx","format":"json","fields":[{"name":"email"},{"name":"user_id"}]}'

向き不向き

Clerk が向くケース

React / Next.js / Remix を主戦場とするフロントエンド寄りのチーム
認証 UI を自前実装したくない小〜中規模スタートアップ
Auth0 のコスト削減を最優先に、かつ移行工数を最小化したい場合

Supabase Auth が向くケース

すでに Supabase（PostgreSQL）をデータベースとして採用しているプロジェクト
セルフホストやオープンソースを前提としたい組織
認証とデータアクセス制御（Row Level Security）を一体管理したいチーム

WorkOS が向くケース

顧客企業ごとに SAML SSO や SCIM プロビジョニングを提供しなければならない B2B SaaS
HR システムとのディレクトリ同期が必須な Enterprise 向け製品

避けるべきケース

Clerk: モバイルネイティブ（iOS/Android）がメインのプロジェクト。SDK のカバレッジが Web 中心のため、追加実装コストが生じる
Supabase Auth: Auth 機能だけを切り出して使いたい場合。Supabase スタック全体への依存が発生するため、既存 DB 構成との兼ね合いを先に検証すること
WorkOS: エンドユーザー向け B2C アプリには過剰。Enterprise 機能に特化した設計のため、一般的な SNS ログインや MFA 程度の要件では費用対効果が低い

DEV Community