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 が必要になった場合は、Firebase Authentication with Identity Platform へアップグレードします。データ移行は不要で、既存のクライアント SDK と Admin SDK を継続利用できます。

主要概念と用語

• エンドユーザー: アプリにサインインする一般利用者。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 系プロバイダーには広い無料枠がある。電話認証は Blaze プランが必要で、SMS は送信先の国・地域に応じて課金される
• フェデレーション系プロバイダー（Google・Apple 等）は、各プロバイダー側の設定・審査・ポリシーに従う必要がある
• SAML/OIDC・多要素認証・マルチテナント・監査ログ・SLA が必要な場合は、Firebase Authentication with Identity Platform へアップグレードする
• アップグレード後の Spark は、メール・SNS・匿名・カスタム認証が 3,000 DAU / 日、SAML / OIDC が 2 DAU / 日。Blaze は一般プロバイダーの最初の 50,000 MAU、SAML / OIDC の最初の 50 MAUが無償
• クォータや具体的な料金・トークン有効期限の数値は変動するため、本番設計時は公式ドキュメントで最新値を確認すること

内部の仕組み

横にスクロール

クライアント（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 などは無料枠が広く、電話認証は Blaze プランで SMS 送信ごとに課金されます。Identity Platform へアップグレードすると、一般プロバイダーは Blaze の最初の 50,000 MAU、SAML / OIDC は最初の 50 MAU が無償で、超過分は月間アクティブユーザー単位です。

セキュリティ

• メール確認を必須化し、未確認アドレスでの重要操作を制限する
• 乱用対策: 電話認証の悪用（課金狙いの大量 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