moai-platform-auth

認証プラットフォームの専門ガイド

3つの主要プラットフォーム、Auth0（エンタープライズセキュリティ）、Clerk（モダンなUX）、Firebase Auth（モバイルファースト）を対象に、認証と認可に関する包括的なガイダンスを提供します。

プラットフォームのクイック選択

Auth0 - エンタープライズセキュリティ

セキュリティコンプライアンスと攻撃対策に特化した、エンタープライズグレードのIDプラットフォームです。

最適な用途：強固なコンプライアンス（FAPI、GDPR、HIPAA）、高度な攻撃対策、送信者制約（DPoP/mTLS）によるトークンセキュリティ、マルチテナント型B2B SaaSを必要とするエンタープライズアプリケーション。

主な強み：高度な攻撃対策（ボット検出、漏えいパスワード、ブルートフォース攻撃）、アダプティブMFA、コンプライアンス認証（ISO 27001、SOC 2、FAPI）、トークンセキュリティ（DPoP、mTLS）、広範なセキュリティ監視。

料金モデル：月間アクティブユーザー数に応じた料金で、エンタープライズ機能は上位プランで利用できます。

Context7 ライブラリ：/auth0/docs

Clerk - モダンなユーザーエクスペリエンス

美しい組み込みUIコンポーネントとWebAuthnに対応した、モダンな認証サービスです。

最適な用途：開発者エクスペリエンスとユーザーエクスペリエンスを重視するモダンなWebアプリケーション、Next.jsアプリケーション、最小限の設定でソーシャルログインを実装するアプリケーション、パスワードレス認証。

主な強み：美しいUIを備えたReact用の組み込みコンポーネント、WebAuthnとパスキーへの対応、Next.jsとのシームレスな統合、組織管理、優れたDXを実現するシンプルなAPI。

料金モデル：無料プランがあり、月間アクティブユーザー数に応じた料金で、余裕のある利用上限が設定されています。

Context7 ライブラリ：/clerk/clerk-docs

Firebase Auth - モバイルファーストの統合

Firebaseサービスとシームレスに統合できる、Googleエコシステムの認証サービスです。

最適な用途：モバイルアプリケーション（iOS、Android、Flutter）、Googleエコシステムとの統合、サーバーレスのCloud Functions、匿名認証からアップグレードする必要があるアプリケーション、小規模から中規模のWebアプリケーション。

主な強み：iOS/Android/Flutter向けのネイティブモバイルSDK、Google Sign-Inとの統合、Firebaseサービス（Firestore、Storage、Cloud Functions）との統合、電話番号認証、余裕のある無料プラン。

料金モデル：余裕のある無料プランがあり、利用量が多い場合は従量課金です。

Context7 ライブラリ：/firebase/firebase-docs

クイック判断ガイド

次の場合はAuth0を選択してください：

• エンタープライズのセキュリティとコンプライアンス要件が重要な場合
• 高度な攻撃対策とセキュリティ監視が必要な場合
• 送信者制約付きトークン（DPoP、mTLS）を実装する場合
• 複雑なB2Bマルチテナントのシナリオに対応する場合
• FAPI、GDPR、HIPAA、またはPCI DSSへの準拠が必要な場合

次の場合はClerkを選択してください：

• モダンなNext.jsまたはReactアプリケーションを構築する場合
• 開発者エクスペリエンスと美しいUIを重視する場合
• パスワードレス認証またはWebAuthn認証をすばやく実装する必要がある場合
• アプリケーション内の認証コードを最小限に抑えたい場合
• ロールベースのアクセス制御を伴う組織管理が必要な場合

次の場合はFirebase Authを選択してください：

• モバイルファーストのアプリケーションを構築する場合
• すでにFirebaseエコシステム（Firestore、Storage、Functions）を利用している場合
• Google Sign-InまたはGoogleエコシステムとの統合が必要な場合
• 匿名認証からアップグレードできる構成が必要な場合
• Cloud Functionsを使うサーバーレスアーキテクチャを優先する場合

共通の認証パターン

共通パターン

これらのパターンは、プラットフォーム固有の実装を除き、3 つすべてのプラットフォームに共通して適用されます。

セッション管理：

すべてのプラットフォームが、セッションの永続化、リフレッシュトークン、セッションの無効化に対応しています。Auth0 はリフレッシュトークンのローテーションを使用し、Clerk は自動更新機能付きのセッショントークンを使用し、Firebase はカスタムクレームを含む ID トークンの更新を使用します。

多要素認証：

すべてのプラットフォームが、TOTP、SMS、プッシュ通知など、複数の MFA 要素に対応しています。Auth0 は WebAuthn と適応型 MFA を提供し、Clerk はパスキー対応の WebAuthn を提供し、Firebase は電話番号認証とカスタム MFA を提供します。

ソーシャル認証：

すべてのプラットフォームが、主要なソーシャルプロバイダー（Google、Facebook、GitHub、Apple）に対応しています。Auth0 ではプロバイダーごとに接続設定が必要で、Clerk は事前設定済みのソーシャルログインボタンを提供し、Firebase では OAuth の設定と SDK のセットアップが必要です。

ロールベースのアクセス制御：

すべてのプラットフォームが、認可にカスタムクレームまたはメタデータを使用できます。Auth0 は Actions を使用して JWT トークンにカスタムクレームを追加し、Clerk は組織のロールとメタデータを使用し、Firebase は Admin SDK でカスタムクレームを使用します。

トークン管理：

すべてのプラットフォームが、API 認可用の JWT トークンを発行します。Auth0 はスコープ付きのアクセストークンとリフレッシュトークンを提供し、Clerk は getToken() によるセッショントークンを提供し、Firebase はカスタムクレームを含む ID トークンを提供します。

セキュリティのベストプラクティス

すべてのプラットフォームに適用されます。

トークンの保存：

• Web ではトークンを localStorage に保存しないでください（XSS の脆弱性があります）。
• 可能であれば httpOnly Cookie を使用してください。
• SPA では、リフレッシュトークンのローテーションを併用したメモリ内保存を使用してください。
• モバイルアプリでは安全なストレージ（Keychain、Keystore）を使用してください。

HTTPS の適用：

• 本番環境では必ず HTTPS を使用してください。
• 安全なリダイレクト URI を設定してください。
• HSTS ヘッダーを有効にしてください。

トークンの検証：

• 必ずトークンの署名を検証してください。
• トークンのオーディエンス（aud クレーム）を確認してください。
• トークンの有効期限（exp クレーム）を確認してください。
• 発行者（iss クレーム）を検証してください。

パスワードポリシー：

• 強力なパスワード要件を適用してください。
• 漏えいしたパスワードの検出を有効にしてください。
• ログイン失敗後にアカウントをロックする仕組みを実装してください。
• パスワード強度のインジケーターを使用してください。

API セキュリティ：

• 保護されたすべてのエンドポイントで認証を必須にしてください。
• レート制限を実装してください。
• 認可にはスコープまたは権限を使用してください。
• 認証および認可のイベントをログに記録してください。

プラットフォーム固有の実装

プラットフォーム固有の実装に関する詳しいガイダンスについては、次のリファレンスファイルを参照してください。

Auth0 の実装

ファイル：reference/auth0.md

攻撃防止の設定、WebAuthn と適応型ポリシーによる MFA のセットアップ、DPoP と mTLS による送信者制約を用いたトークンセキュリティ、FAPI／GDPR／HIPAA 向けのコンプライアンス機能、Security Center の監視、継続的なセッション保護について説明します。

主なセクション：ダッシュボードのナビゲーション、ボット検出の設定、漏えいしたパスワードの検出、ブルートフォース攻撃の防止、WebAuthn のセットアップ、トークンの検証、DPoP の実装、mTLS 証明書のバインディング、コンプライアンス認証。

Clerk の実装

ファイル：reference/clerk.md

Next.js 向けの ClerkProvider のセットアップ、認証コンポーネント（SignIn、SignUp、UserButton）、ミドルウェアによるルート保護、useAuth と useUser フック、サーバーサイド認証、組織管理、Core 2 への移行について説明します。

主なセクション：環境変数、ミドルウェアの設定、ルートの保護、ユーザーデータへのアクセス、組織の切り替え、カスタム認証フロー、Webhook の統合。

Firebase Auth の実装

ファイル：reference/firebase-auth.md

各プラットフォーム（Web、Flutter、iOS、Android）での Firebase SDK の初期化、ソーシャル認証のセットアップ、SMS 認証による電話認証、アカウントのリンクを伴う匿名認証、RBAC 向けのカスタムクレーム、Security Rules との統合について説明します。

主なセクション：プロジェクトのセットアップ、SDK の初期化、Google サインイン、Facebook ログイン、電話番号認証、カスタムクレームの管理、Firestore と Storage のルール、Cloud Functions のトリガー。

プラットフォームの比較

ファイル：reference/comparison.md

機能、料金、ユースケース、移行時の考慮事項、統合の複雑さを網羅した詳細な比較表を提供します。

主なセクション：機能比較表、料金の内訳、ユースケースの選択マトリクス、プラットフォーム移行戦略、エコシステム統合、開発者エクスペリエンスの比較。

ナビゲーションガイド

認証機能を使用する場合：

1. プラットフォームを選択する場合は、まず「プラットフォームのクイック選択」（上記）を確認します
2. 共通の認証パターンを確認して、共通の概念を把握します
3. 実装の詳細については、プラットフォーム固有のリファレンスファイルを開きます
4. 複数のプラットフォームを評価する場合は、comparison.md を参照します
5. Context7 ツールを使用して、最新のプラットフォームドキュメントにアクセスします

Context7 によるドキュメントへのアクセス

Context7 MCP を使用して、最新のプラットフォームドキュメントにアクセスします。

Auth0：

• resolve-library-id に "auth0" を指定して、ライブラリ ID を取得します
• get-library-docs にトピック "attack-protection"、"mfa"、"tokens"、"compliance" を指定します

Clerk：

• resolve-library-id に "clerk" を指定して、ライブラリ ID を取得します
• get-library-docs にトピック "nextjs"、"react"、"authentication" を指定します

Firebase Auth：

• resolve-library-id に "firebase" を指定して、ライブラリ ID を取得します
• get-library-docs にトピック "authentication"、"security-rules" を指定します

相性の良いもの

• moai-platform-supabase：認証と統合されたデータベース
• moai-platform-vercel：エッジ認証を使用したデプロイ
• .claude/rules/moai/languages/typescript.md：認証 SDK 向けの TypeScript パターン（paths frontmatter により自動読み込み）
• moai-domain-backend：認証を備えたバックエンドアーキテクチャ
• moai-domain-frontend：React/Next.js フロントエンド統合
• moai-expert-security：セキュリティ監査と脅威モデリング

---

ステータス：Active バージョン：2.0.0 (Consolidated Platform Coverage) 最終更新日：2026-02-09 プラットフォーム：Auth0、Clerk、Firebase Auth

よくある誤った合理化

誤った合理化	実態
"社内ツールならパスワードのみの認証で十分だ"	社内ツールも認証情報の詰め込み攻撃によって侵害されます。本番データにアクセスできるツールでは、MFA が最低限必要です。
"ベンダーロックインを避けるため、認証を一から実装する"	カスタム認証の実装は、セキュリティ脆弱性の主な原因です。実績のあるプロバイダーを使い、インターフェースを抽象化してください。
"ユーザーは再ログインを嫌うので、セッションの有効期限は長くできる"	セッションが長いと、盗まれたトークンを悪用できる時間が延びます。短いセッションを設定し、サイレントリフレッシュを使用してください。
"ソーシャルログインは単なる利便性機能だ"	ソーシャルログインでは、ID プロバイダーに本人確認を委ねます。パスワードを保存する際の攻撃対象領域を縮小できます。
"WebAuthn/パスキーは新しすぎて導入できない"	パスキーは主要なブラウザーとプラットフォームすべてでサポートされています。最も一般的な攻撃手法であるフィッシングを防止できます。

危険信号

• 認証トークンが httpOnly Cookie ではなく localStorage に保存されている
• 権限の高いアカウントで MFA を利用できない
• セッショントークンに有効期限やリフレッシュ機構がない
• パスワードリセット後も既存のセッションが無効化されない
• OAuth のリダイレクト URI でワイルドカードや未検証の値が許可されている

検証

• トークンが httpOnly、Secure、SameSite Cookie に保存されている（localStorage ではない）
• すべてのユーザーアカウントで MFA が有効、または利用可能である
• 自動リフレッシュ機構を備えたセッション有効期限が設定されている
• パスワードリセットにより、アカウントの既存セッションがすべて無効化される
• OAuth リダイレクト URI が完全一致で検証される（ワイルドカードなし）
• 認証プロバイダー SDK のバージョンが最新である（依存関係のバージョンを提示）

リファクタリングに関する注記

R4 監査判定（2026-04-23）：リファクタリング — 3社（Clerk、Auth.js、Supabase Auth）の対象範囲を維持し、ベンダーごとのガイダンスをより絞り込みます SPEC：SPEC-V3R2-WF-001 §6.2 272行目 リファクタリングの対象範囲（今後のサブSPECに延期）：

• ベンダーごとのガイダンス（Clerk、Auth.js、Supabase Auth）をより絞り込み、実行しやすい内容にします
• ベンダー選定のための実装パターン比較表を追加します
• OWASP 認証チェックリストへの参照を moai-ref-owasp-checklist に切り出します

このスキルは v3.0 で維持されますが、本文は後続の SPEC で再構成される予定です。