コラム / 認証 / セキュリティ /
Auth0 / Clerk / Supabase Auth ─ B2B SaaS で本当に選ぶべき認証基盤の比較
📖 約7分 / 公開日: 2026/05/21
認証基盤を自前で実装する判断は、ほぼ常に間違いです。パスワードハッシュ、セッション管理、メール確認、リセットトークン、レート制限、IP ロック、デバイス記憶、MFA、SSO、SAML、SCIM、監査ログ。これだけの機能を 2026 年の水準で揃えるなら、専任エンジニア 2 人で半年かけても怪しい。だから外部の認証基盤を使う。問題は「どれを」です。
Auth0、Clerk、Supabase Auth を、過去 2 年で導入・移行・撤退まで含めて触った実プロジェクトの記録から比較します。料金、機能、開発体験、運用負担、そして後で乗り換える時の脱出コストという観点で、それぞれが向く局面と地雷を整理します。
## 月額費用の差は想像より大きい
B2B SaaS で MAU 5,000、組織数 200、SSO 接続 30、SAML 接続 5 という構成で実費を比べます。
Auth0 は B2B プランで月額 1,800 ドル前後。SSO の外部接続を有効にした瞬間に Enterprise プランへ強制され、最低でも年間契約 24,000 ドルから。営業対応必須で、月単位の柔軟性はありません。
Clerk は同等構成で月額 700 ドル前後。Pro プランの段階課金で、組織数と MAU の超過分のみが加算されます。SSO 接続は 1 つあたり月額 50 ドルと明朗。
Supabase Auth は単独サービスというより、Supabase プラットフォーム全体の月額 25〜599 ドルの中に含まれている。MAU 100,000 まで Pro プラン(月額 25 ドル)で収まります。ただし SAML / SCIM は Team プラン以上(月額 599 ドルから)に押し込まれている。
年間ベースで Auth0 が約 30,000 ドル、Clerk が約 9,000 ドル、Supabase Auth が約 7,000 ドル。同じ「認証」と思って比較するから揺らぐのです。
## 額面通りに見てはいけない
Auth0 の高さには理由があります。Action(旧 Rules / Hooks)による拡張性、Organizations API の成熟、SCIM 2.0 の標準対応、Universal Login のローカライズ。これらを個別に作れば軽く 2,000 人日が消える機能群です。Salesforce や ServiceNow のような大企業向け SaaS との SSO 接続を、営業が顧客に約束してしまった案件で、Auth0 以外を選ぶと地獄を見ます。
Clerk は完成度が突出しています。React コンポーネントの <SignIn />、<UserButton />、<OrganizationSwitcher /> が業務品質で、UI ローカライズも 30 言語超。Next.js との統合は他の追随を許さない。一方で React 以外の枠組み(Vue、Svelte、モバイル)では機能の半分が使えません。SAML 接続は 2024 年に追加されたばかりで、まだ枯れていない。
Supabase Auth は PostgreSQL のテーブルに直接ユーザー情報が入る思想で、Row Level Security と組み合わせた時の表現力は他を圧倒します。半面、認証専用機能としての成熟度は最も低い。Magic Link の到達率(Resend 経由で 92% 程度)、MFA は TOTP のみ対応、組織管理機能は皆無。アプリのコアテーブルと同じ DB に乗ることのトレードオフを許容できるかが鍵です。
## SAML / SCIM の壁
B2B SaaS の現場で最大の論点は SAML と SCIM です。エンタープライズ顧客は Okta や Microsoft Entra ID 連携を要求します。提案書に「SSO 対応」と書いた瞬間、これは事実上の要件になります。
Auth0 は SAML が標準機能。設定画面で IdP メタデータ XML を貼るだけで動く。SCIM 2.0 もネイティブ対応で、Okta のグループ同期がそのまま流れます。これが Enterprise プランの厚みです。
Clerk の SAML は Pro プランから利用可能で、設定 UI も洗練されている。SCIM は 2025 年に登場した Connections SCIM 機能で対応。ただし Okta テンプレートの公式提供は遅れていて、カスタム SCIM 設定が必要なケースが残ります。
Supabase Auth の SAML は GoTrue というオープンソースの認証コンポーネント経由で「設定ファイルで定義する」スタイル。GUI なし。SCIM は事実上未対応で、自前で実装するしかありません。SaaS の顧客折衝担当者にこれを説明すると、十中八九「他のものに替えてほしい」と返ってきます。
## 開発体験は無視できない差を生む
コードを書く側からの体感差は大きい。
Clerk は <SignIn /> を貼った 10 分後にログインフォームが動きます。Webhook で Stripe との同期を仕込むのも 30 分。UI の見た目を変えるための CSS 変数も整っている。Next.js App Router の middleware.ts に 4 行追加すれば認証ガードが完成する。開発初期のスピードでは他を寄せ付けません。
Auth0 はやや古い世代の SDK で、@auth0/nextjs-auth0 が v3 まで来てやっと App Router がまともに動くようになりました。Universal Login のテーマカスタマイズは制約が多く、デザイナーから不評を買いやすい。
Supabase Auth は @supabase/auth-helpers が刷新されて @supabase/ssr へ移行中で、ドキュメントが追いついていない時期がありました。コードは少なく済みますが、Magic Link の到達率を上げるための SPF / DKIM / DMARC 設定は自分でやる必要がある。全部自分で見られるのが利点であり欠点。
## 移行の難易度こそ最後に効く
これが最も見落とされる観点です。後で他のサービスに乗り換える時の脱出コストが、3 者で大きく違います。
Auth0 はユーザーエクスポート機能で bcrypt ハッシュごとパスワードを取り出せる。これにより無停止で他社へ移行できます。実案件で Auth0 → Clerk への移行を行ったが、ユーザーに再ログインを要求せずに完了しました。
Clerk のパスワードエクスポートは 2024 年後半に追加されたばかりで、bcrypt ハッシュ取り出しに対応。ただし MFA シードや TOTP の移行はサポート経由で手動。
Supabase Auth は PostgreSQL のテーブル(auth.users)に直接アクセスできるため、技術的にはエクスポートが最も柔軟。半面、Magic Link 派の運用だとパスワードハッシュ自体が存在しないユーザーが多数いて、移行先で全員に再登録を要求することになります。
## 要件で割り切るのが速い
B2B SaaS で SAML / SCIM / 大企業 SSO が確実に来るなら Auth0 一択。月 1,800 ドルは安心料です。Okta との連携で躓いた時に同社のエンジニアが出てくる安心感は他にない。
B2C 寄り、または B2B でも初期は中小企業中心、Next.js を採用、開発スピード優先なら Clerk。Pro プランで足りる規模ならコストパフォーマンスが最も高い。
社内向け業務システム、または PostgreSQL を既に深く使うアプリケーションなら Supabase Auth。Row Level Security との組み合わせで複雑な権限要件を簡潔に表現できます。
## 選んではいけない局面
避けるべき組み合わせも明確です。
Auth0 を MAU 1,000 未満の社内ツールで使うのは予算の無駄。月額 23 ドルの Essential プランは SSO 1 接続のみで、現実的に足りません。
Clerk を大企業向け B2B SaaS のメイン認証に据えるのは、SAML の成熟度の点でまだ早い。2026 年後半に再評価すべき判断です。
Supabase Auth を顧客向け SaaS の認証基盤として、特に SOC2 や ISMS の認証取得を控えるプロジェクトで採用すると、監査ログ機能の薄さで苦戦します。FedRAMP 系の要件には完全に不向き。
## 二段構えという戦略
認証基盤は「替えやすさ」を含めて選ぶべきです。最初に Clerk で立ち上げ、SAML / SCIM が必要になった時点で Auth0 へ移行する二段構え。これが B2B SaaS のスタートアップにとって最も合理的な選択になります。Clerk から Auth0 への移行は、パスワードハッシュのエクスポート機能を使えば数日仕事です。逆方向は MFA シードの移行で苦労する可能性があります。
最初から Auth0 を選ぶと、初期開発コストが膨らみ、PMF 前にランニングコストで苦しみます。最初から Supabase Auth を選ぶと、エンタープライズ案件が来た時に書き換えコストで苦しみます。Clerk から始めるのは、その中間点として実務的に最も正しい。
サブスクリプション SaaS の出口戦略まで考えたら、認証基盤の選定はビジネスモデルの選定と一体です。技術選定の問題ではなく経営判断の問題、と言い切ってしまった方が話が早い。
Auth0、Clerk、Supabase Auth を、過去 2 年で導入・移行・撤退まで含めて触った実プロジェクトの記録から比較します。料金、機能、開発体験、運用負担、そして後で乗り換える時の脱出コストという観点で、それぞれが向く局面と地雷を整理します。
## 月額費用の差は想像より大きい
B2B SaaS で MAU 5,000、組織数 200、SSO 接続 30、SAML 接続 5 という構成で実費を比べます。
Auth0 は B2B プランで月額 1,800 ドル前後。SSO の外部接続を有効にした瞬間に Enterprise プランへ強制され、最低でも年間契約 24,000 ドルから。営業対応必須で、月単位の柔軟性はありません。
Clerk は同等構成で月額 700 ドル前後。Pro プランの段階課金で、組織数と MAU の超過分のみが加算されます。SSO 接続は 1 つあたり月額 50 ドルと明朗。
Supabase Auth は単独サービスというより、Supabase プラットフォーム全体の月額 25〜599 ドルの中に含まれている。MAU 100,000 まで Pro プラン(月額 25 ドル)で収まります。ただし SAML / SCIM は Team プラン以上(月額 599 ドルから)に押し込まれている。
年間ベースで Auth0 が約 30,000 ドル、Clerk が約 9,000 ドル、Supabase Auth が約 7,000 ドル。同じ「認証」と思って比較するから揺らぐのです。
## 額面通りに見てはいけない
Auth0 の高さには理由があります。Action(旧 Rules / Hooks)による拡張性、Organizations API の成熟、SCIM 2.0 の標準対応、Universal Login のローカライズ。これらを個別に作れば軽く 2,000 人日が消える機能群です。Salesforce や ServiceNow のような大企業向け SaaS との SSO 接続を、営業が顧客に約束してしまった案件で、Auth0 以外を選ぶと地獄を見ます。
Clerk は完成度が突出しています。React コンポーネントの <SignIn />、<UserButton />、<OrganizationSwitcher /> が業務品質で、UI ローカライズも 30 言語超。Next.js との統合は他の追随を許さない。一方で React 以外の枠組み(Vue、Svelte、モバイル)では機能の半分が使えません。SAML 接続は 2024 年に追加されたばかりで、まだ枯れていない。
Supabase Auth は PostgreSQL のテーブルに直接ユーザー情報が入る思想で、Row Level Security と組み合わせた時の表現力は他を圧倒します。半面、認証専用機能としての成熟度は最も低い。Magic Link の到達率(Resend 経由で 92% 程度)、MFA は TOTP のみ対応、組織管理機能は皆無。アプリのコアテーブルと同じ DB に乗ることのトレードオフを許容できるかが鍵です。
## SAML / SCIM の壁
B2B SaaS の現場で最大の論点は SAML と SCIM です。エンタープライズ顧客は Okta や Microsoft Entra ID 連携を要求します。提案書に「SSO 対応」と書いた瞬間、これは事実上の要件になります。
Auth0 は SAML が標準機能。設定画面で IdP メタデータ XML を貼るだけで動く。SCIM 2.0 もネイティブ対応で、Okta のグループ同期がそのまま流れます。これが Enterprise プランの厚みです。
Clerk の SAML は Pro プランから利用可能で、設定 UI も洗練されている。SCIM は 2025 年に登場した Connections SCIM 機能で対応。ただし Okta テンプレートの公式提供は遅れていて、カスタム SCIM 設定が必要なケースが残ります。
Supabase Auth の SAML は GoTrue というオープンソースの認証コンポーネント経由で「設定ファイルで定義する」スタイル。GUI なし。SCIM は事実上未対応で、自前で実装するしかありません。SaaS の顧客折衝担当者にこれを説明すると、十中八九「他のものに替えてほしい」と返ってきます。
## 開発体験は無視できない差を生む
コードを書く側からの体感差は大きい。
Clerk は <SignIn /> を貼った 10 分後にログインフォームが動きます。Webhook で Stripe との同期を仕込むのも 30 分。UI の見た目を変えるための CSS 変数も整っている。Next.js App Router の middleware.ts に 4 行追加すれば認証ガードが完成する。開発初期のスピードでは他を寄せ付けません。
Auth0 はやや古い世代の SDK で、@auth0/nextjs-auth0 が v3 まで来てやっと App Router がまともに動くようになりました。Universal Login のテーマカスタマイズは制約が多く、デザイナーから不評を買いやすい。
Supabase Auth は @supabase/auth-helpers が刷新されて @supabase/ssr へ移行中で、ドキュメントが追いついていない時期がありました。コードは少なく済みますが、Magic Link の到達率を上げるための SPF / DKIM / DMARC 設定は自分でやる必要がある。全部自分で見られるのが利点であり欠点。
## 移行の難易度こそ最後に効く
これが最も見落とされる観点です。後で他のサービスに乗り換える時の脱出コストが、3 者で大きく違います。
Auth0 はユーザーエクスポート機能で bcrypt ハッシュごとパスワードを取り出せる。これにより無停止で他社へ移行できます。実案件で Auth0 → Clerk への移行を行ったが、ユーザーに再ログインを要求せずに完了しました。
Clerk のパスワードエクスポートは 2024 年後半に追加されたばかりで、bcrypt ハッシュ取り出しに対応。ただし MFA シードや TOTP の移行はサポート経由で手動。
Supabase Auth は PostgreSQL のテーブル(auth.users)に直接アクセスできるため、技術的にはエクスポートが最も柔軟。半面、Magic Link 派の運用だとパスワードハッシュ自体が存在しないユーザーが多数いて、移行先で全員に再登録を要求することになります。
## 要件で割り切るのが速い
B2B SaaS で SAML / SCIM / 大企業 SSO が確実に来るなら Auth0 一択。月 1,800 ドルは安心料です。Okta との連携で躓いた時に同社のエンジニアが出てくる安心感は他にない。
B2C 寄り、または B2B でも初期は中小企業中心、Next.js を採用、開発スピード優先なら Clerk。Pro プランで足りる規模ならコストパフォーマンスが最も高い。
社内向け業務システム、または PostgreSQL を既に深く使うアプリケーションなら Supabase Auth。Row Level Security との組み合わせで複雑な権限要件を簡潔に表現できます。
## 選んではいけない局面
避けるべき組み合わせも明確です。
Auth0 を MAU 1,000 未満の社内ツールで使うのは予算の無駄。月額 23 ドルの Essential プランは SSO 1 接続のみで、現実的に足りません。
Clerk を大企業向け B2B SaaS のメイン認証に据えるのは、SAML の成熟度の点でまだ早い。2026 年後半に再評価すべき判断です。
Supabase Auth を顧客向け SaaS の認証基盤として、特に SOC2 や ISMS の認証取得を控えるプロジェクトで採用すると、監査ログ機能の薄さで苦戦します。FedRAMP 系の要件には完全に不向き。
## 二段構えという戦略
認証基盤は「替えやすさ」を含めて選ぶべきです。最初に Clerk で立ち上げ、SAML / SCIM が必要になった時点で Auth0 へ移行する二段構え。これが B2B SaaS のスタートアップにとって最も合理的な選択になります。Clerk から Auth0 への移行は、パスワードハッシュのエクスポート機能を使えば数日仕事です。逆方向は MFA シードの移行で苦労する可能性があります。
最初から Auth0 を選ぶと、初期開発コストが膨らみ、PMF 前にランニングコストで苦しみます。最初から Supabase Auth を選ぶと、エンタープライズ案件が来た時に書き換えコストで苦しみます。Clerk から始めるのは、その中間点として実務的に最も正しい。
サブスクリプション SaaS の出口戦略まで考えたら、認証基盤の選定はビジネスモデルの選定と一体です。技術選定の問題ではなく経営判断の問題、と言い切ってしまった方が話が早い。