結論（おすすめ1つ）
Next.js / React を使うスタートアップ・個人開発者なら Clerk に乗り換えるべき。
Auth0 は機能的に成熟しているが、価格体系が複雑で MAU 課金のスケールに悲鳴を上げるタイミングが早い。Clerk は UI コンポーネント込みで認証が10分で動き、ローカル開発体験が別次元に良い。価格モデルも透明で、無料枠のまま本番ローンチできる規模感がある。エンタープライズ SSO が最優先なら WorkOS、自前 Postgres で全制御したいなら Supabase Auth を選ぶ。
比較表（料金/無料枠/移行コスト/対応言語）
| 項目 | Auth0 | Clerk | Supabase Auth | WorkOS |
|---|---|---|---|---|
| 料金モデル | MAU 従量 | MAU 従量 | Supabase プラン内包 | B2B 接続数従量 |
| 無料枠 | 公式の料金ページで要確認 | 公式の料金ページで要確認 | 公式の料金ページで要確認 | 公式の料金ページで要確認 |
| 移行コスト | ― | 中（JWT 発行元変更・UI 差し替え） | 高（DB 移行・Row Level Security 設計） | 中〜高（Enterprise SSO 設定が複雑） |
| SDK | Node / Go / Python / Java 等 | JS/TS 専用色が強い（公式 SDK: React, Next.js, Expo 等） | 公式 JS/Dart SDK、非公式で他言語 | Node / Python / Ruby / Go 等 |
| セルフホスト | 不可（Okta SaaS） | 不可 | 可（Supabase OSS） | 不可 |
| SAML/SCIM | Enterprise プランのみ | Add-on あり | 限定的 | コア機能 |
| MFA | あり | あり | あり | あり |
| ソーシャルログイン | 多数 | 多数 | 主要プロバイダ | 企業 IdP 中心 |
移行手順
ここでは Auth0 → Clerk への移行を想定する。
1. Clerk アカウント・アプリ作成
npm install @clerk/nextjs
dashboard.clerk.com でアプリを作成し、.env.local に鍵を設定。
NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_test_xxxx
CLERK_SECRET_KEY=sk_test_xxxx
2. ミドルウェア設定（Next.js App Router）
// middleware.ts
import { clerkMiddleware, createRouteMatcher } from '@clerk/nextjs/server';
const isPublic = createRouteMatcher(['/sign-in(.*)', '/sign-up(.*)', '/api/public(.*)']);
export default clerkMiddleware((auth, req) => {
if (!isPublic(req)) auth().protect();
});
export const config = { matcher: ['/((?!_next|.*\\..*).*)'] };
3. Auth0 JWT → Clerk JWT の切り替え
Auth0 発行の既存セッションは即時無効になる。ユーザーに再ログインを要求するメンテナンス告知を事前に出すこと。ユーザーデータの移行は Auth0 Management API でエクスポートし、Clerk の Backend API /v1/users に POST する。
# Auth0 からユーザー一括エクスポート（Auth0 CLI）
auth0 users export --format json --fields email,name > users.json
# Clerk へインポート（パスワードなし→初回メールで再設定）
node scripts/import_to_clerk.js
// scripts/import_to_clerk.js
const { clerkClient } = require('@clerk/nextjs/server');
const users = require('./users.json');
for (const u of users) {
await clerkClient.users.createUser({
emailAddress: [u.email],
firstName: u.name?.split(' ')[0] ?? '',
skipPasswordRequirement: true,
});
}
4. API ルートでのセッション検証を差し替え
// Before (Auth0)
import { getSession } from '@auth0/nextjs-auth0';
// After (Clerk)
import { auth } from '@clerk/nextjs/server';
export async function GET() {
const { userId } = await auth();
if (!userId) return new Response('Unauthorized', { status: 401 });
// ...
}
5. ソーシャルプロバイダ再設定
Clerk ダッシュボードで Google / GitHub 等の OAuth アプリを新規登録し直す。Auth0 で使っていた Client ID/Secret はそのまま使えないため、各プロバイダで別アプリとして作成すること。
向き不向き
Clerk が向く
-
Next.js / React 中心のスタートアップ：
<SignIn />コンポーネント1行で認証 UI が完結し、開発速度が最大化される - 小〜中規模（MAU 数千〜数万）：無料枠内またはコスパの良い価格帯で収まりやすい（公式料金ページで要確認）
- デザインにこだわりたいチーム：Appearance API でコンポーネントの見た目を CSS 変数で細かく制御できる
Supabase Auth が向く
- バックエンドも Supabase で統一するチーム：RLS と組み合わせることで DB レベルのアクセス制御が完結する
- OSS でセルフホストしたい：GDPR 対応やデータ居住地要件が厳しい場合に有効
- Postgres を既に使っている：ユーザーテーブルが同一 DB に入るためクエリが単純になる
WorkOS が向く
- B2B SaaS で大企業顧客を狙うプロダクト：SAML SSO / SCIM プロビジョニングが最短で繋がる
- IT 管理者が IdP 設定を求めてくる企業向け販売：Okta / Azure AD との接続実績が豊富
避けるべきケース
- Clerk：モバイルアプリ（iOS/Android ネイティブ）がメインの場合、SDK の充実度で Auth0 や Firebase Auth に劣る場面がある
- Supabase Auth：認証だけ切り出して使いたい場合は Supabase 全体への依存を負うため過剰になりがち
- WorkOS：コンシューマー向け（BtoC）サービスには過剰設計かつ費用対効果が合わない
- 共通：既存の Auth0 カスタムルール・Hooks が複雑に絡んでいる場合は、どのツールへ移行しても追加工数が大きくなる。移行前に Auth0 側のカスタムロジックをすべて棚卸しすること。
If you found this useful: I packaged 50 copy-paste AI debugging prompts + drop-in Claude Code config templates (CLAUDE.md, settings.json, MCP) into a small kit.
Launch deal: code START50 = 50% off → 50 AI Debugging Prompts + Claude Code Config Pack (about $6, 50% off applied)
New: my 10-chapter ebook Practical Claude Code — automation & unattended operation (about $9, 50% off applied)
Top comments (0)