Google Cloud Identity Platform / Firebase Authenticationは、アプリやサービスへ顧客向けの認証とユーザー情報の管理を組み込むためのマネージドサービスです。Google Cloudプロジェクト内で有効にし、SDKや用意済みのFirebaseUIを使ってログイン機能を構成できます。
メールアドレスとパスワードによるログインから、OAuth、電話番号、独自認証、OIDC、SAMLまで複数の方式を扱えます。個人利用者向けのB2Cアプリだけでなく、顧客ごとに認証設定を分けるB2Bアプリにも対応します。自社で認証サーバーを運用せず、Google Cloud上で顧客認証を管理したい場合に候補になります。
クライアント向けSDKとFirebaseUIを使い、アプリのサインインフローを構成できます。FirebaseUIは、ログイン画面を一から作らずに利用するための用意済みUIです。メールアドレスとパスワードによるログインは、認証プロバイダーとして有効化できます。
そのほか、メール、電話番号、匿名ユーザー、ソーシャルログイン、OAuth、独自認証を扱えます。企業のID基盤と連携する場合は、OIDCやSAMLも選択肢になります。必要な方式をすべて有効にするのではなく、利用者の種類とアカウント復旧の流れまで含めて選びます。
多要素認証（MFA）とblocking functionsはIdentity Platform固有の機能です。blocking functionsは、ユーザーの登録やログイン処理の途中に独自の確認処理を入れるための仕組みです。Firebase Authenticationの基本機能だけで要件を満たすか、Identity Platform固有機能まで必要かを分けて判断します。
ログインに成功すると、クライアントSDKがIDトークンを取得し、必要に応じて更新します。サーバー側ではトークンを検証し、正しい利用者からのリクエストかを確認します。
ここで、ログイン状態を画面側だけで信頼しないことが重要です。クライアントが保持する情報だけでアクセスを許可せず、サーバーでトークンを検証します。セッションの有効期間や更新時の扱いも、アプリ側の処理と合わせて設計します。
Admin SDKでは、ユーザーの作成、更新、削除、インポートを行えます。Google Cloud ConsoleとAdmin SDKから、プロジェクトまたはテナントごとのユーザーアカウントを管理できます。
custom claimsもAdmin SDKの管理対象です。custom claimsは、利用者の役割など、アプリがアクセス判断に使う情報をトークンへ持たせるための仕組みです。ただし、認証とauthorizationは同じではありません。Identity Platformが誰かを確認した後、どの操作を許可するかは、claimとアプリ側のルールを組み合わせて決めます。
登録時の作成だけでなく、プロフィール変更、権限変更、別システムからの移行、利用終了時の削除までを一連の流れとして考えると、Admin SDKで自動化すべき範囲が見えやすくなります。
Identity Platformのマルチテナント機能では、B2Bアプリの顧客ごとにユーザー、IDプロバイダー、認証方式、監査・IAM、割り当て上限を分離できます。たとえば、顧客Aはメールログイン、顧客Bは企業のOIDCを使うといった構成を分けて管理できます。
ユーザーとテナントは異なる単位です。ユーザーはログインする個人で、テナントは顧客ごとの認証領域です。会社の部署や複雑な組織階層を表す機能と同一視せず、自社サービスで必要な組織、所属、役割をどこで管理するかを決めます。
B2Cでは、プロジェクト単位で個人ユーザーの認証を扱う構成が中心になります。B2Bでは顧客ごとの分離が重要です。また、顧客向け認証と従業員向けの社内ID管理は目的が違います。Identity Platformを評価するときは、アプリを利用する外部ユーザーの要件として整理します。
OIDCとSAMLは、外部のIDプロバイダーを使ってログインするための認証連携に使います。企業向けSSOを実現したい場合は、顧客のID基盤が使う方式に合わせてテナントごとに設定します。
SCIMは、ユーザー情報をシステム間で作成・更新するための仕組みで、SSOとは役割が異なります。OIDCやSAMLに対応していることだけで、SCIMによるユーザー同期まで含まれるとは判断できません。B2BでSCIMが必要な場合は、同期範囲と実現方法を別要件として確認します。
Identity PlatformはGoogle Cloudプロジェクト内で利用するマネージド認証サービスです。自社で認証サーバーを構築するself-host型ではありません。一方で、ログイン方法の有効化、テナントごとの設定、ユーザー管理、サーバーでのトークン検証、custom claimsを使ったアクセス制御は導入側が設計します。
稼働率については99.95%のSLAが掲げられています。可用性の数値だけでなく、自社アプリが認証エラーや一時的な接続問題をどう扱うかも運用計画に含めます。
特定地域へのデータ保管要件がある場合は、Google Cloudプロジェクトの場所だけで判断せず、認証データの取り扱いとアクセス制御が要件に合うかを確認します。提供地域の詳細を推測せず、契約前に対象サービスの条件を確かめることが必要です。
料金は月間アクティブユーザー数（MAU）が基準です。ただし、一般的なログイン方式を含むTier 1と、OIDC/SAMLを使うTier 2では無料枠と超過料金が異なります。両者を同じ無料枠としてまとめず、利用する認証方式ごとに見積もります。
| 費用項目 | 内容 |
|---|---|
| tier1_mau | email、phone、anonymous、socialのTier 1は月50,000 MAUまで無料。 |
| tier2_mau | OIDC/SAMLのTier 2はprojectあたり月50 MAUまで無料。 |
| mau | Tier 2の50 MAU超は1 MAUあたり月0.015米ドル。 |
注意
料金は2026年8月7日に確認したGLOBAL向けの米ドル建て情報です。日本向けの公式ページはありますが、独立した円建て料金は確認できていません。市場、通貨、請求周期、追加機能を契約前に確認してください。
マルチテナント構成では、テナント固有のblocking functionはサポートされません。blocking functionを使う処理が顧客ごとに異なる場合は、要件とのずれがないかを早めに確認します。
アカウントリンクの無効化もサポートされません。複数のログイン方法を同じユーザーへ結び付ける方針に制約があるサービスでは、期待するアカウント管理と一致するかを検証する必要があります。
Google Cloud Identity Platform / Firebase Authenticationは、SDKと用意済みUIを使って顧客認証を組み込みたい場合や、B2B顧客ごとに認証設定を分けたい場合に向いています。MFA、blocking functions、OIDC/SAML、マルチテナントが必要なら、Firebase Authenticationの基本機能との違いを確認したうえで選びます。
Q.Firebase AuthenticationとIdentity Platformは同じ？
A.共通する認証機能がありますが、MFAとblocking functionsはIdentity Platform固有です。必要な機能を基準に、どちらの範囲で構成するかを判断します。
Q.OIDCやSAMLは無料で使える？
A.Tier 2として、プロジェクトあたり月50 MAUまで無料です。50 MAUを超える分は、1 MAUあたり月額0.015米ドルです。
Q.B2Bアプリにも使える？
A.はい。マルチテナント機能で、顧客ごとにユーザー、IDプロバイダー、認証方式、監査・IAM、割り当て上限を分けられます。組織階層や業務上の役割は別に設計します。
確認日: 2026-08-07（記載の各公式ページで確認。価格などは変わることがあります）
Google Cloud Identity Platform / Firebase Authentication