Firebase Authentication は、個人開発や小規模プロダクトの認証を「無料枠の中で実用レベルまで」回せる点が最大の魅力だ。Spark プランで月 50,000 MAU まで無料という枠は、立ち上げ期のサービスにとって実質的にコストゼロで運用できることを意味する。
何ができるか
メール/パスワード、SNS ログイン、電話番号認証、匿名認証といった、個人開発で必要になる認証方式を一通りカバーする。匿名認証は「まず使わせてから後でアカウント登録に昇格させる」モバイルアプリの定番パターンに使え、ユーザー獲得の摩擦を下げられる。
Firebase スタックとの統合
Firestore、Cloud Functions、ストレージといった Firebase の他機能と認証情報がそのまま連携する。セキュリティルールでユーザーごとのデータアクセス制御を宣言的に書けるため、バックエンドを薄く保ったままアプリを組める。プロトタイピングの速度はこの統合に支えられている。
無料枠の内訳に注意
「月 50,000 MAU まで無料」は認証本体の話で、電話番号認証の SMS 送信は別建ての従量課金になる。SMS を多用する設計だと、認証自体は無料枠でも通信費が思わぬコスト源になりうる。また Firestore や Functions と組み合わせて使う以上、認証は無料でも周辺サービスの利用量で課金が発生する。「認証無料」を「Firebase 全体が無料」と読み違えないようにしたい。
限界
エンタープライズ向けの組織管理——企業単位のユーザー区分、企業ごとの SSO 設定、きめ細かいロール管理——は守備範囲外だ。B2B SaaS でこうした要件が出てくると、Firebase Auth では作り込みが厳しくなり、専用の認証基盤への移行を検討することになる。個人開発・モバイルアプリ・プロトタイピングという土俵では、無料枠の広さと統合のしやすさで強い選択肢だ。
セキュリティルールと組み合わせて初めて機能する
Firebase Authentication は「誰がログインしているか」を教えてくれるが、その人が何を読み書きできるかは Firestore や Storage のセキュリティルール側で決める。認証だけ入れてルールをテスト用の全許可のままにしておくと、ログインさえすれば他人のデータも自由に触れる状態になる。認証とルールはセットで設計するものだと理解しておきたい。
開発初期に設定する「全ユーザーが読み書き可能」なルールには有効期限が付きますが、期限を延長して使い続けてしまうケースが後を絶ちません。公開前に必ずルールを見直し、ユーザー自身のデータだけにアクセスが限定されることを実際のアカウントで確認してください。
電話番号認証はコストが別枠で乗る
メールやソーシャルログインが無料枠で回る一方、SMS を使う電話番号認証は送信ごとに費用が発生し、国によって単価も異なる。認証手段として電話番号を選ぶと、無料枠の感覚のままコストが伸びる。加えて、SMS を悪用した課金攻撃（意図的に大量の送信を発生させる手口）への備えも要る。認証手段の選択は、UX だけでなくコストと悪用リスクの両面で判断すべきだ。