スシロー

Posted on Jul 4

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

#saas #devops #tutorial #webdev

結論（おすすめ1つ）

乗り換え先として最初に検討すべきは Clerk。

Next.js / React が主戦場のチームなら、Clerk が現時点で移行コストと開発体験のバランスに最も優れている。理由は3点：SDK がフレームワーク単位で設計されており認証 UI の自前実装がほぼ不要、JWT／セッション管理がデフォルトで安全な構成になっている、Auth0 と同等のソーシャルログイン・MFA をダッシュボード操作だけで完結できる。

ただし、エンタープライズ SSO（SAML／SCIM）が受注条件になっている B2B SaaS チームは WorkOS、既存スタックが Supabase ベースなら Supabase Auth を先に評価すること。

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

項目	Auth0	Clerk	Supabase Auth	WorkOS
無料枠	MAU 上限あり（公式の料金ページで要確認）	MAU 上限あり（公式の料金ページで要確認）	プロジェクト単位（公式の料金ページで要確認）	開発・ステージング向け無料枠あり（公式の料金ページで要確認）
有料時の課金軸	MAU ベース	MAU ベース	プロジェクト数・機能	SSO コネクション単位
移行コスト	―	中（SDK 差替・JWT claims 変更）	中〜高（DB 統合が前提）	高（SSO 設定・ユーザー移行）
主対応言語	多言語（公式 SDK 多数）	JS/TS 中心（React/Next.js 特化）	JS/TS・Python・Go ほか	JS/TS・Python・Go ほか
セルフホスト	不可	不可	可（OSS）	不可
SAML/SCIM	高額プランのみ	有料プラン	限定的	コア機能として標準

移行手順

Auth0 から Clerk への移行を例に、実際に踏んだ手順を示す。

1. Clerk SDK のインストール

npm install @clerk/nextjs

2. 環境変数の差し替え

# .env.local（Auth0 の変数を削除し Clerk の変数に置き換える）

# 削除対象
# AUTH0_SECRET=...
# AUTH0_BASE_URL=...
# AUTH0_ISSUER_BASE_URL=...
# AUTH0_CLIENT_ID=...
# AUTH0_CLIENT_SECRET=...

# 追加
NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_test_xxxx
CLERK_SECRET_KEY=sk_test_xxxx

3. ミドルウェアの設定（Next.js App Router）

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

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

export default clerkMiddleware((auth, req) => {
  if (isProtected(req)) auth().protect()
})

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

4. Auth0 のユーザーデータを取得

# Auth0 Management API でユーザー一覧を JSON に落とす
curl -H "Authorization: Bearer $AUTH0_MGMT_TOKEN" \
  "https://YOUR_DOMAIN.auth0.com/api/v2/users?per_page=100" \
  > auth0_users.json

5. Clerk へユーザーをインポート

// scripts/migrate-users.ts
import { clerkClient } from '@clerk/nextjs/server'
import users from './auth0_users.json'

for (const u of users) {
  await clerkClient.users.createUser({
    emailAddress: [u.email],
    // Auth0 の user_id を externalId として保持しておくと
    // 既存 DB レコードとの突合スクリプトが楽になる
    externalId: u.user_id,
  })
}

パスワードハッシュ（bcrypt）のインポートは Clerk のバルクインポート API が対応しているか事前に公式ドキュメントで確認すること。未対応の場合はパスワードリセットメールをユーザーに送る運用が現実的。

6. JWT Claims の差し替え確認

Auth0 の sub クレームは auth0|xxxxx 形式になっているため、バックエンド側の認証ミドルウェアが期待する形式と一致しなくなる。Clerk では userId を取得して既存の DB レコードと突合する移行スクリプトを本番切り替え前に必ず実行する。

向き不向き

Clerk が向くケース

Next.js / React を主軸にした SaaS でスピード優先
フロントエンド中心のスタートアップ（認証 UI を自前実装したくない）
Auth0 の料金が MAU 増加で無視できなくなってきたチーム

Supabase Auth が向くケース

既に Supabase（PostgreSQL）を使っており DB とユーザー管理を一元化したい
セルフホストが必要なコンプライアンス要件がある
バックエンド中心の構成で Next.js 以外のフレームワークを使っている

WorkOS が向くケース

受注条件に SAML SSO・SCIM プロビジョニングが含まれる B2B SaaS
大企業顧客を相手にする予定があり、監査ログ・ディレクトリ同期が必須
エンタープライズ対応を将来的に見越して最初から設計したい

避けるべきケース

Clerk：Vue・Django・Rails 等が主体の場合、SDK の成熟度に差があり検証コストが増す。React 以外では素直に Supabase Auth か Auth0 を評価し直すほうが早い
Supabase Auth：Auth0 のカスタムアクション（ルールエンジン）を多用しているプロジェクトは機能差を先に精査すること。移植工数が読みにくくなる
WorkOS：コンシューマー向けアプリには過剰スペック。コネクション単位の課金体系は小規模チームや個人開発では割高になる可能性がある

DEV Community