Firebase Authentication

解決する課題

スマホアプリや Web アプリのログイン機能を、自前で作らずに任せたいときに使います。Cloud IAM が「Google Cloud のリソースに誰がアクセスできるか」を制御するのに対し、Firebase Authentication が扱うのは「あなたのアプリにログインするのは誰か」、つまりエンドユーザーの認証です。

• パスワードのハッシュ保存・リセットメール・ログイン状態の保持などを自作すると、バグや脆弱性の温床になる → マネージドな認証基盤に任せたい
• Google・Apple ログインや、メールアドレス・電話番号（SMS）など複数のサインイン方法をまとめて用意したい
• フロントエンドにすぐ組み込めるログイン UI と SDK（Web・iOS・Android）が欲しい
• ログイン後にバックエンド API を保護したい → **検証できる ID トークン（JWT）**で認証状態を引き回したい

対応する AWS のサービスは **Amazon Cognito（ユーザープール）**です。Firebase Authentication は Identity Platform と認証基盤を共有しており、SAML/OIDC・多要素認証・マルチテナント・監査ログ・SLA といったエンタープライズ機能が必要になった場合は、上位版の Identity Platform へ移行する形になります。

主要概念と用語

• エンドユーザー: アプリにサインインする一般利用者。Google Cloud にログインする管理者やサービスアカウントとは別物
• サインインプロバイダー: 認証の出どころ。メール／パスワード、電話番号（SMS）、Google・Apple・Facebook・GitHub などの OAuth、ゲスト用の匿名認証などから選んで有効化する
• ID トークン: 認証成功時に発行される署名付き JWT。uid・メール・プロバイダー情報などを含み、バックエンドはこれを検証してユーザーを識別する
• リフレッシュトークン: 期限切れの ID トークンを再発行するための長期トークン。SDK が裏側で使い、ログインを維持する
• カスタムクレーム: ID トークンに付与できる任意の属性。role などを入れて**認可（権限）**の判断に使う
• FirebaseUI / Authentication SDK: ログイン画面や認証処理をすぐ実装できる UI ライブラリとクライアント SDK
• Admin SDK: サーバー側でトークンを検証したり、ユーザーの作成・削除・クレーム付与を行うための管理用ライブラリ
• セキュリティルール連携: Firestore や Cloud Storage（Firebase）のルールから、ログイン中のユーザー情報を参照してアクセス可否を判定できる

仕様・制限・クォータ

• グローバルサービスで、ユーザーディレクトリはプロジェクトに紐づく。料金・運用は基本的にリージョンに依存しないが、SMS など一部機能の挙動は地域要因を受ける
• ID トークンは短命（標準で 1 時間程度）。アプリは SDK 経由でリフレッシュトークンを使い自動更新するのが前提
• 無料枠が広く、メール／パスワードや OAuth 系プロバイダーは無料の範囲で使えることが多い。一方で**電話認証（SMS）**は送信ごとに外部コストが伴う
• フェデレーション系プロバイダー（Google・Apple 等）は、各プロバイダー側の設定・審査・ポリシーに従う必要がある
• SAML/OIDC・多要素認証・マルチテナント・監査ログ・SLA が必要な場合は、Firebase Authentication ではなく上位版の Identity Platform を使う
• クォータや具体的な料金・トークン有効期限の数値は変動するため、本番設計時は公式ドキュメントで最新値を確認すること

内部の仕組み

クライアント（Web・iOS・Android）が SDK でサインインを行うと、Firebase Authentication がサインインプロバイダーとの認証フローを仲介し、成功すると署名付き ID トークン（JWT）とリフレッシュトークンを返します。

1. クライアントが選んだプロバイダーで認証（パスワード照合、OAuth リダイレクト、SMS コード検証など）
2. 成功すると Firebase Authentication がユーザーレコードを作成・更新し、uid を確定
3. **ID トークン（JWT）**を発行。クライアントはこれを API 呼び出しの Authorization ヘッダに載せる
4. バックエンドは Admin SDK 等でトークンの署名と有効期限を検証し、uid やカスタムクレームから認可を判断
5. トークンが切れたら SDK がリフレッシュトークンで自動再発行（再ログイン不要）

設計パターン / ベストプラクティス

• トークンはサーバー側で必ず検証する: クライアントから来た JWT は Admin SDK で署名・期限・発行者を検証してから信頼する
• 認可はカスタムクレームで: ロールなどをカスタムクレームに入れ、API 側はクレームを見て権限を判定する。クレーム付与は信頼できるサーバー側で行う
• クライアント直結 DB はセキュリティルールで守る: Firestore や Cloud Storage に直接アクセスする構成では、ルールからログインユーザーの uid を参照して所有者チェックを書く
• メール確認を必須にする: 未確認アドレスのまま重要操作を許さないよう、確認状態を条件に組み込む
• 匿名認証からの昇格: まず匿名で使い始め、後からメールや SNS アカウントへリンクしてデータを引き継ぐ導線を設ける
• 企業要件が出たら Identity Platform へ: SAML/OIDC・MFA・マルチテナント・監査ログが必要になったら上位版へ切り替える

運用・監視

• Firebase コンソールのユーザー管理画面でユーザーの一覧・無効化・削除、サインイン方法やメールテンプレート（確認・リセット）の設定を行う
• 登録ユーザー数やサインインの推移を監視し、急増（攻撃や bot 登録）やコスト増を早期に検知する
• SMS 送信は到達性・コストの観点で監視対象。電話認証は乱用（課金狙いの大量送信）に注意する
• ユーザーデータのエクスポート / インポート機能で、移行やバックアップ、他環境への複製を行う
• 監査ログや MFA・マルチテナントなどより厳密な運用が必要になったら Identity Platform へアップグレードする

コスト

メール／パスワードや Google・Apple などの OAuth 系プロバイダーは無料枠が広く、多くの小〜中規模アプリは無料の範囲で運用できます。コストが発生しやすいのは主に**電話認証（SMS）**で、送信ごとに料金がかかり、地域差や乱用対策の影響を受けます。エンタープライズ機能を使う場合は Identity Platform 側の従量課金（月間アクティブユーザー基準）になります。

セキュリティ

• メール確認を必須化し、未確認アドレスでの重要操作を制限する
• 乱用対策: 電話認証の悪用（課金狙いの大量 SMS）や bot による大量サインアップに備え、reCAPTCHA などの保護を組み合わせる
• トークンの取り扱い: ID トークンとリフレッシュトークンを安全に保管し、ログアウト時や侵害時はトークンを失効させる
• 最小権限: カスタムクレームに過剰な権限を埋め込まず、認可の最終判断はサーバー側のロジックで行う
• より強い保護が必要なら Identity Platform: 多要素認証（MFA）やリスクベースの保護、監査ログが要件なら上位版を選ぶ

関連サービス・比較

ハンズオン / CLI例

# Firebase CLI でログインし、プロジェクトを確認
firebase login
firebase projects:list

# 既存の Google Cloud プロジェクトに Firebase を追加
firebase projects:addfirebase my-project

# Identity Toolkit API を有効化（認証基盤の API）
gcloud services enable identitytoolkit.googleapis.com --project=my-project

# Admin SDK でサーバー側からトークン検証やユーザー管理を行うため、
# サービスアカウントキーの代わりにアプリケーションのデフォルト認証情報を設定
gcloud auth application-default login