Identity Platform

解決する課題

自社アプリやサービスのエンドユーザー認証を、自前で作らずに任せたいときに使います。Cloud IAM が「Google Cloud のリソースに誰がアクセスできるか」を制御するのに対し、Identity Platform は「あなたのアプリにログインするのは誰か」を扱う、いわゆる CIAM（顧客 ID とアクセス管理）です。

• パスワードのハッシュ保存・リセット・ブルートフォース対策などを自作するとバグと脆弱性の温床になる → マネージドな認証基盤に任せたい
• Google・Apple・Facebook ログインや、メール・電話番号（SMS）など多様なサインイン方法をまとめて提供したい
• ログイン後にバックエンド API を保護したい → 検証可能な ID トークン（JWT）で認証状態を引き回したい
• 金融・行政系などで多要素認証（MFA）やリスクベースの保護を後付けで足したい

対応する AWS のサービスは Amazon Cognito（ユーザープール）です。Firebase Authentication と中身を共有しており、Identity Platform はそこにエンタープライズ向け機能（SAML/OIDC、MFA、マルチテナント、監査ログ等）と SLA を加えた上位版にあたります。

主要概念と用語

• ユーザー（エンドユーザー）: アプリにサインインする一般利用者。Google Cloud にログインする管理者やサービスアカウントとは別物
• アイデンティティプロバイダー（IdP）: 認証の出どころ。メール／パスワード、電話番号（SMS）、フェデレーション系（Google・Apple・Facebook・GitHub 等の OAuth）、企業向けの SAML / OIDC、ゲスト用の匿名認証など
• ID トークン: 認証成功時に発行される署名付き JWT。uid・メール・プロバイダー情報などを含み、バックエンドはこれを検証してユーザーを識別する
• リフレッシュトークン: 期限切れの ID トークンを再発行するための長期トークン
• カスタムクレーム: ID トークンに付与できる任意の属性。role や tenant などを入れて認可（権限）に使う
• 多要素認証（MFA）: パスワードに加え SMS や TOTP など第二要素を要求する仕組み
• マルチテナンシー（テナント）: 1 プロジェクト内にユーザー集合を論理分割する単位。SaaS で顧客企業ごとにユーザーを分離する用途
• ブロッキング関数（Blocking Functions）: サインアップ／サインイン時に Cloud Functions を割り込ませ、登録の拒否やクレーム付与を行う拡張点

仕様・制限・クォータ

• グローバルサービスで、ユーザーディレクトリはプロジェクトに紐づく。料金・運用はリージョンに依存しないが、SMS など一部機能の挙動は地域要因を受ける
• ID トークンは短命（標準で 1 時間程度）。アプリは SDK 経由でリフレッシュトークンを使い自動更新するのが前提
• 無料枠と上限が用意され、月間アクティブユーザー（MAU）を基準に課金される。SMS（電話認証）など外部コストが伴う機能は別建て課金になりやすい
• フェデレーション系プロバイダー（Google・Apple 等）は各プロバイダー側の設定・審査・ポリシーに従う必要がある
• クォータや具体的な料金・トークン有効期限の数値は変動するため、本番設計時は公式ドキュメントで最新値を確認すること

内部の仕組み

横にスクロール

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

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

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

• トークンはサーバー側で必ず検証する: クライアントから来た JWT は Admin SDK で署名・期限・発行者を検証してから信頼する
• 認可はカスタムクレームで: ロールやテナント ID をカスタムクレームに入れ、API 側はクレームを見て権限を判定する。クレーム付与は信頼できるサーバー側（または ブロッキング関数）で行う
• SaaS はマルチテナンシーを活用: 顧客企業ごとにテナントを分け、ユーザーや IdP 設定を分離する
• 企業顧客には SAML / OIDC: 取引先の既存 IdP（社内 SSO）とフェデレーションし、パスワードを自社で持たない
• 登録時の制御はブロッキング関数で: 許可ドメインのみ登録可にする、初期クレームを付ける、不正登録を弾く、といった処理を割り込ませる
• 最終的なリソース権限は Cloud IAM 側で: エンドユーザー認証は Identity Platform、Google Cloud リソースの権限は IAM、と役割を分ける

運用・監視

• Cloud Audit Logs と連携し、ユーザー作成・削除・設定変更などの管理操作を監査できる
• コンソールのユーザー管理画面でユーザーの一覧・無効化・削除、サインイン方法やテンプレート（確認メール等）の設定を行う
• 使用量（MAU）を監視し、急増（攻撃や bot 登録）やコスト増を早期に検知する
• SMS 送信は到達性・コストの観点で監視対象。電話認証は乱用（課金狙いの大量送信）に注意する
• ユーザーデータのエクスポート / インポート機能で、移行やバックアップ、他環境への複製を行う

コスト

課金は主に月間アクティブユーザー（MAU）ベースで、認証したユーザー数に応じた従量制です。無料枠を超えた分が課金対象となり、料金体系はプロバイダー種別（標準の認証か、フェデレーション/エンタープライズ機能か）で異なる場合があります。

セキュリティ

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

Well-Architected の観点

• セキュリティ: 認証の難所（パスワード保管・MFA・トークン署名と検証）をマネージドに委ね、攻撃面を減らせる。フェデレーションで自社にパスワードを持たない構成も取れる
• 運用: ユーザー管理・監査ログ・テンプレート管理がコンソールと API で完結し、運用負荷が低い
• 信頼性: フルマネージドで SLA が提供され、スケールはプラットフォーム側が吸収する
• コスト: MAU 従量で初期費用が小さく、利用量に比例。ただし SMS など外部コストは別管理が必要

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# プロジェクトで Identity Platform API を有効化
gcloud services enable identitytoolkit.googleapis.com --project=my-project

# メール/パスワード認証を設定するための既定テナント構成を確認
gcloud identity-platform config get --project=my-project

# マルチテナンシー用のテナントを作成（SaaS で顧客ごとに分離する例）
gcloud identity-platform tenants create \
  --display-name="customer-acme" \
  --project=my-project

# 作成済みテナントの一覧を確認
gcloud identity-platform tenants list --project=my-project