このガイドのゴール
- 認証機能を「SaaS で導入」するか「自前実装」するかの判断基準を理解する
- Auth0 と Firebase Authentication の特性・コスト構造・制約を比較する
- ソーシャルログイン・MFA・B2B マルチテナントの実装パターンを把握する
認証はセキュリティの根幹であり、自前実装のリスクは高い領域です。一方で SaaS に依存するとベンダーロックインや料金の問題が生じます。トレードオフを正しく理解したうえで選択してください。
🧩 このガイドで使うリソース
プロダクトの規模と要件で選ぶ
🏢 B2B / エンタープライズ
Auth0
Organizations 機能で B2B マルチテナント対応。SAML / LDAP 連携。ロールベースアクセス制御（RBAC）が標準装備。
🚀 スタートアップ / MVP
Firebase Authentication
無料枠が広い（MAU 5 万まで無料）。Google / Apple / LINE ログインの設定が数分で完了。Firebase 他サービスとの連携が自然。
Buy vs Build: SaaS 認証か自前実装か
SaaS 認証を選ぶべきケース
- 認証がプロダクトのコア機能ではない — 認証に開発リソースを割くより機能開発に集中したい
- MFA・ソーシャルログインが必要 — 自前で Google / Apple / LINE 連携を実装・保守するコストは大きい
- セキュリティ監査の要件がある — Auth0 は SOC 2 / ISO 27001 取得済み。自前実装でこれを満たすのは現実的ではない
自前実装を選ぶべきケース
- ユーザー数が非常に多い — MAU 10 万超では SaaS の月額が数十万円に達する
- 認証フローを完全にカスタマイズしたい — SaaS のログイン画面ではブランド体験を損なう場合
- 特定のフレームワークに認証機能が組み込まれている — Laravel Breeze / Next-Auth など、フレームワーク標準で十分な場合
自前実装を選ぶ場合のリスク
パスワードハッシュ（bcrypt / Argon2）、CSRF 対策、セッション管理、ブルートフォース防止、パスワードリセットのトークン管理など、見落としやすいセキュリティ要件が多数あります。フレームワークの標準機能を使い、独自の暗号処理は書かないでください。
Auth0 vs Firebase Authentication 比較
| 観点 | Auth0 | Firebase Authentication |
|---|---|---|
| 無料枠 | MAU 25,000 まで | MAU 50,000 まで（電話認証は別枠） |
| ソーシャルログイン | Google / Apple / Facebook / LINE / GitHub 他多数 | Google / Apple / Facebook / GitHub / Twitter / LINE |
| MFA | 標準プランから利用可。SMS / TOTP / Push | 有料プラン（Identity Platform）で利用可 |
| B2B マルチテナント | Organizations 機能で対応 | マルチテナント機能あり（Identity Platform） |
| SAML / LDAP | 対応（エンタープライズプラン） | SAML 対応（Identity Platform） |
| カスタム UI | Universal Login（カスタマイズ可）or Lock.js | FirebaseUI or 完全カスタム |
| SDK | SPA / Native / サーバ向けに充実 | Web / iOS / Android / Flutter |
| ユーザー管理画面 | Dashboard で管理可能 | Firebase Console で管理 |
アーキテクチャ: SaaS 認証の統合パターン
🔧 SaaS 認証の統合フロー
フロントエンドで認証し、バックエンドで JWT を検証する構成
ソーシャルログインの実装
対応すべきプロバイダの優先度（日本市場）
- Google — Android ユーザーは必ずアカウントを持っている。設定も最も簡単
- Apple — iOS アプリで他のソーシャルログインを提供する場合、Apple ログインは App Store 審査の必須要件
- LINE — 日本国内では月間ユーザー数が最多の SNS。toC サービスでは有力
- GitHub — 開発者向けサービスでは定番
Apple ログインは iOS アプリでは実質必須
App Store のガイドラインでは、サードパーティのソーシャルログインを提供するアプリは Apple でのサインインも提供する必要があります。Web アプリのみの場合は任意です。
MFA（多要素認証）
MFA はセキュリティ強度を大幅に上げますが、ユーザー体験とのトレードオフがあります。
| 方式 | セキュリティ | UX | 導入コスト |
|---|---|---|---|
| SMS | 中（SIM スワップ攻撃のリスク） | 良い（追加アプリ不要） | SMS 送信料が発生 |
| TOTP（Authenticator） | 高 | 中（アプリのインストールが必要） | 無料 |
| パスキー（WebAuthn） | 最高 | 良い（生体認証で完結） | 実装コスト中 |
| Push 通知 | 高 | 良い（ワンタップ） | Auth0 Guardian で利用可 |
2026 年のトレンド: パスキーへの移行
Google / Apple / Microsoft がパスキーを標準化しており、パスワードレス認証が主流になりつつあります。新規プロダクトではパスキー対応を優先的に検討してください。Auth0 は Actions で WebAuthn を統合可能、Firebase は Identity Platform でパスキー対応しています。
B2B マルチテナント
SaaS を企業向けに提供する場合、「組織ごとにメンバー管理・権限設定を分離する」機能が必要になります。
Auth0 Organizations
- 組織ごとにログイン方式を設定可能（A 社は Google SSO、B 社は SAML）
- 組織管理者がメンバーを招待・削除
- RBAC（ロールベースアクセス制御）を組織単位で設定
Firebase のマルチテナント
- Identity Platform でテナント分離が可能
- テナントごとに認証プロバイダを設定
- ただし Auth0 の Organizations ほど機能は充実していない
セキュリティチェックリスト
- パスワードは bcrypt / Argon2 でハッシュ化（SaaS 利用時は自動）
- CSRF トークン をログインフォームに埋め込み
- ログイン試行回数の レート制限（5 回失敗でロック等）
- パスワードリセットトークンの 有効期限 を設定（30 分以内）
- JWT の 有効期限 を短く設定（15 分〜1 時間）＋ リフレッシュトークン
- HTTPS を 強制
- セッション固定攻撃 への対策（ログイン時にセッション ID を再生成）
まとめ
- B2B SaaS / エンタープライズ要件 → Auth0（Organizations + SAML + RBAC）
- MVP / 個人開発 / Firebase エコシステム → Firebase Authentication（無料枠が広い）
- フレームワーク標準で十分な場合 → 自前実装（Laravel Breeze / Next-Auth 等）
- MFA は パスキー優先 で検討（2026 年の標準になりつつある）
- 自前実装する場合は フレームワークの認証機能を使い、独自の暗号処理は書かない
この記事の情報は 2026 年 4 月時点のものです。各サービスの料金体系や機能は変更される可能性があります。