Firebase:ID、アクセス権、保存、通知を分けて考える

要点

FirebaseにはSDK、アクセス制御、料金条件が異なるサービスがあります。利用者の識別は全データへの許可ではありません。安全性と費用をサービスごとに評価します。

セキュリティキー2個、白紙のカード、えんじ色の資料がある架空の無人本人確認室
この記事の内容

FirebaseにはSDK、アクセス制御、料金条件が異なるサービスがあります。利用者の識別は全データへの許可ではありません。安全性と費用をサービスごとに評価します。

認証と認可

Firebase Authenticationはログインを管理し、アクセス権は別途定めます。Cloud Firestoreのウェブ・モバイルクライアントはSecurity Rulesを使用します。サーバーライブラリはこれを迂回しIAMを使用するため、一つの制御で両方を覆えると考えないでください。文書化されたウェブMFAにはFirebase Authentication with Identity Platformが必要です。

データとファイル

Cloud FirestoreとRealtime Databaseは別のデータベースサービスで、Cloud Storageはファイルなどのオブジェクトを保存します。共通の単一ルールで保護されるわけではありません。現在のFAQでは既存バケットを含むCloud Storage for Firebaseの利用にBlazeが必要ですが、無料利用枠が残る場合があります。無料と紹介する前に割当量と課金を確認します。

FCM通知

FCM HTTP v1は短期間のOAuth 2.0アクセストークンなどによるサーバー認可を使います。管理用認証情報をクライアントに埋め込まず、信頼できる環境から送信します。端末登録トークンは送信先の識別子であり、ユーザーIDトークンや業務権限ではありません。

セッションと運用

IDトークン、リフレッシュトークン、失効を区別します。暗号学的に有効でも権限の継続は証明できません。必要なログ、保存期間、費用通知、リソース単位の制御を定めます。Firebaseが自動的にGDPR適合を実現するわけではありません。

出典

編集確認日:2026年11月1日。

ID決定をリゾルバに渡す。

サインインが成功しても、グラフ内のすべてのフィールドが承認されるわけではない。各リゾルバに到達するIDコンテキストは、要求されたオブジェクトと機密データに対するチェックをサポートしている必要がある。

  • 複数のロールと所有者の下で同じフィールドをテストする。
  • ネストされたフィールドを計算する前に、オブジェクトへのアクセスを拒否する。
  • ロールの変更またはセッションの取り消し後にリプレイを実行する。

一次資料:OWASP — GraphQL Cheat Sheet. 関連する方法:実践ガイドを読む.

APIページ分割と一貫した出力

変動するデータは出力の欠落や重複を生む場合があります。

  • フィルター、並び順、同値の場合の決定キーを記録します。APIがスナップショットを提供するか、変化する集合を読むか確認します。読取中の作成と削除を試します。カーソルがあるだけでは集合の固定を保証しません。
  • AIP-158では空のnext_page_tokenが終了条件であり、短いページや空の結果ではありません。架空のページ[A,B]と[B,C]は四行ですが、固有識別子は三つです。進捗のない同一カーソルも検出し、実際のAPI契約に従います。
  • バッチを永続保存してから継続状態を確定します。中断したバッチを安定した識別子で再処理し、各要求で権限を確認します。カーソルはアクセス許可ではありません。スナップショット失効時は再開始か明示した照合を行い、異なる状態を黙って結合しません。

再現できる受け入れ事例

架空の例です。顧客や実際の観測結果を示すデータではありません。

事例の入力を見る
{
    "page_1_ids": [
        "A",
        "B"
    ],
    "page_2_ids": [
        "B",
        "C"
    ],
    "next_cursor": "c2",
    "empty_page_has_next_cursor": true
}

期待される判断

Bが重複しています。識別子を確認し、空ページでも次のカーソルがあれば続けます。

検証手順

  1. 条件、安定順序、識別子を定めます。
  2. 重複と次カーソル付き空頁を試験します。
  3. 識別子と実際の終了条件を残します。 受信オブジェクト数と一意の識別子を照合します。カーソルの繰り返しを記録し、続きがある空ページを収集完了と扱わないでください。

Google AIP-158 — Pagination

期待した行数ならエクスポートは完全ですか?

いいえ。欠落と重複が件数上で相殺されることがあります。識別子、範囲、締切を比較し、未解決の差を記録します。

一次資料:Google AIP-158 — Pagination. 関連する方法:実践ガイドを読む.

パスキー:ドメインとRP IDの変更を準備する

アカウント、ウェブのオリジン、RP IDを分け、認証情報を黙って付け替えない移行を計画します。

  • 旧・新のオリジン、RP ID、対応するアカウントを記録します。同じアカウント名でもパスキーが別のRP IDに有効になるわけではありません。WebAuthnの許される組合せと移行中のログイン経路を確認します。
  • 許可されたテスト環境で適切なライブラリを使い、チャレンジ、オリジン、RP ID、アカウントの関連付けを確認します。想定外のオリジンとチャレンジの再利用を試します。RP IDが変わる場合は認証済みの新規登録を準備し、行のコピーを鍵の移行と扱いません。
  • 旧認証情報だけを持つ利用者、復旧、既存セッションを試します。確認した戻し方とともに経路の開設・廃止順を決めます。新ドメインでの登録成功は全旧セッションの失効を証明しません。

再現できる受け入れ事例

架空の例です。顧客や実際の観測結果を示すデータではありません。

事例の入力を見る
{
    "old_origin": "https://login.old.example",
    "old_rp_id": "old.example",
    "new_origin": "https://login.new.example",
    "new_rp_id": "new.example",
    "same_service_account": true,
    "expected": "authenticated_new_registration"
}

期待される判断

架空例:アカウントは同じでもold.exampleから別のRP IDのnew.exampleへ移ります。旧認証情報を黙って付け替えず、新規登録は計画した認証済み経路で行います。

W3C — Web Authentication Level 2

一次資料:W3C — Web Authentication Level 2. 関連する方法:実践ガイドを読む.

ID:認証要素、セッション、復旧

Firebase:短期間のトークンだけではセッション全体は終わらない

文書ではIDトークンの有効期間は1時間で、リフレッシュトークンから新しいトークンを取得できます。リフレッシュトークンの失効とIDトークンの失効検出は別の確認です。

  • 失効処理を対象アカウントに関連付ける。
  • checkRevokedなど、SDKで文書化された失効確認を使う。
  • 保護された各バックエンドで古いトークンと権限を確認する。

ID管理の確認事項を詳しく見る →

出典確認日 · NIST · Authenticator Event Management NIST · Session Management Firebase · Manage User Sessions