プロジェクトにおける Identity Platform ユーザー

Identity Platform のユーザー オブジェクトは、 Google Cloudプロジェクトのアプリに登録したユーザー アカウントを表します。アプリには通常、多くのユーザーが登録されていて、 Google Cloudプロジェクトの各アプリはユーザー データベースを共有しています。

ユーザー インスタンスは Identity Platform インスタンスから独立しているので、同じコンテキストで異なるユーザーを別々に参照しながら、各ユーザーのメソッドをどれでも呼び出すことができます。

ユーザー プロパティ

Identity Platform ユーザーは、一連の固定プロパティ（一意の ID、メインのメールアドレス、名前、写真の URL など）がプロジェクトのユーザー データベースに保存され、ユーザーによる更新が可能です（iOS、Android、ウェブ）。ユーザー オブジェクトに他のプロパティを直接追加することはできません。代わりに、Google Cloud Firestore などの他のストレージ サービスに追加プロパティを格納できます。

ユーザーが初めてアプリに登録するときに、利用可能な情報を使用してユーザーのプロフィール データが設定されます。

  • ユーザーがメールアドレスとパスワードを使用して登録した場合は、メインのメールアドレスのプロパティのみが設定されます。
  • ユーザーがフェデレーション ID プロバイダ（Google や Facebook など）を使用して登録した場合は、そのプロバイダから提供されるアカウント情報を使用してユーザーのプロフィールが設定されます。
  • ユーザーがカスタム認証システムで登録した場合は、設定する情報を明示的にユーザーのプロフィールに追加する必要があります。

ユーザー アカウントを作成したら、ユーザーの情報を再読み込みすることによって、ユーザーが別のデバイスで変更した情報を取り込むことができます。

ログイン プロバイダ

アプリでは、メールアドレスとパスワード、フェデレーション ID プロバイダ、カスタム認証システムなど、複数の方法でユーザーのログインを行うことができます。また、ユーザーには複数のログイン方法を関連付けることができます。たとえば、ユーザーがメールアドレスとパスワード、または Google ログインを使って同じアカウントにログインするといったことができます。

ユーザー インスタンスは、ユーザーにリンクされたすべてのプロバイダを追跡します。そのため、プロバイダから提供された情報を使用して、空のプロフィールのプロパティを更新することができます。ユーザーの管理についての記事（iOS、Android、ウェブ）をご覧ください。

現在ログインしているユーザー

登録またはログインすると、そのユーザーは Auth インスタンスの現在ログインしているユーザーになります。インスタンスはユーザーの状態を保持するため、ブラウザページの更新やアプリの再起動を行っても、ユーザー情報は失われません。

ユーザーがログアウトすると、Auth インスタンスはユーザー オブジェクトへの参照を停止し、状態の保持も停止します。これにより、現在ログインしているユーザーはいなくなります。ただし、ユーザー インスタンスは引き続き完全に機能します。ユーザー インスタンスに対する参照を保持すると、引き続きユーザーのデータにアクセスして更新できます。

ユーザーのライフサイクル

Auth インスタンスの現在の状態を追跡するために推奨される方法は、リスナー（JavaScript では「オブザーバー」と呼ばれます）を使用することです。Auth オブジェクトに関連があることが発生すると、Auth リスナーに通知が届きます。ユーザーの管理についての記事（iOS、Android、ウェブ）をご覧ください。

Auth リスナーは次の場合に通知を受け取ります。

  • Auth オブジェクトの初期化が終了し、ユーザーが前のセッションですでにログイン済みか、または ID プロバイダのログインフローからリダイレクトされたとき。
  • ユーザーがログインしたとき（現在ログインしているユーザーとして設定）。
  • ユーザーがログアウトしたとき（現在ログインしているユーザーが null になる）。
  • 現在ログインしているユーザーのアクセス トークンが更新されたとき。これは、次の状態のときに発生します。
    • アクセス トークンの有効期限が切れたとき。これはよくある状況です。更新トークンは、新しい有効なトークンのセットを取得するために使用されます。
    • ユーザーがパスワードを変更したとき。Identity Platform により新しいアクセス トークンと更新トークンが発行され、古いトークンを期限切れにします。セキュリティ上の理由で、ユーザーのトークンは自動的に有効期限切れになるか、ユーザーはすべてのデバイスから自動的にログアウトされます。
    • ユーザーが再認証されたとき。一部のアクション（アカウントの削除、メインのメールアドレスの設定、パスワードの変更など）では、ユーザーの認証情報が最近発行されたものである必要があります。ユーザーをログアウトして再度ログインしてもらう代わりに、ユーザーから新しい認証情報を取得してユーザー オブジェクトの再認証メソッドに渡します。

ユーザーのセルフサービス

Identity Platform を使用すると、デフォルトでは、管理者による仲介がなくても、ユーザーは自身のアカウントの登録と削除ができます。多くの場合、この機能によりエンドユーザーはアプリケーションやサービスを見つけて、最小限の手間でオンボード（またはオフボード）できます。

しかし、Admin SDK またはGoogle Cloud コンソールのいずれかを使用して、管理者が手動またはプログラムでユーザーを作成する場合もあります。そのような場合は、Identity Platform の設定ページから、ユーザーの操作を無効にして、エンドユーザーによるアカウントの作成や削除をさせないことも可能です。マルチテナンシーを使用する場合は、HTTP リクエストを送信して、テナントごとにこれらの機能を無効にする必要があります。

エンドユーザーがシステム内でアカウントを作成または削除しようとすると、Identity Platform サービスはエラーコード（Web API 呼び出しの場合は auth/admin-restricted-operation、Android と iOS の場合は ERROR_ADMIN_RESTRICTED_OPERATION）を返します。サービスに対して適切な操作を行うようにユーザーに依頼することで、フロントエンドでのエラーを正常に処理します。

認証トークン

Identity Platform での認証を行うとき、次の 3 種類の認証トークンが使用されます。

Identity Platform の ID トークン ユーザーがアプリにログインすると、Identity Platform によって作成されます。これらのトークンは、 Google Cloudプロジェクトのユーザーを安全に識別する署名済みの JWT です。このトークンには、 Google Cloudプロジェクト内で一意のユーザー ID 文字列など、ユーザーの基本的なプロフィール情報が格納されています。ID トークンの整合性は検証可能なため、ID トークンをバックエンド サーバーに送信して、現在ログインしているユーザーを識別できます。
ID プロバイダ トークン Google や Facebook などのフェデレーション ID プロバイダによって作成されます。 形式が異なることもありますが、多くは OAuth 2.0 アクセス トークンです。アプリはこれらのトークンを使用して、ユーザーが ID プロバイダによって正常に認証されたかどうかを確認し、Identity Platform サービスで使用可能な認証情報に変換します。
Identity Platform のカスタム トークン ユーザーが認証システムを使用してアプリにログインできるようにするため、カスタム認証システムによって作成されます。カスタム トークンは、サービス アカウントの秘密鍵を使って署名された JWT です。アプリは、フェデレーション ID プロバイダから返されたトークンと同じように Firebase カスタム トークンを使用します。

確認済みメールアドレス

Identity Platform では、メールが 2 つの条件を満たしている場合に確認済みと見なされます。

  1. ユーザーが Identity Platform の確認フローを完了済み。
  2. メールアドレスが、信頼できる ID プロバイダ（IdP）によって確認済み。

IdP が、メールアドレスを一度だけ確認してから、ユーザーが再確認なしでメールアドレスを変更できるようにすると、信頼済みとなりません。ドメインを所有する IdP または常に確認を必要とする IdP は、信頼できる IdP とみなされます。

信頼できるプロバイダ:

  • Google（@gmail.com のアドレス）
  • Yahoo（@yahoo.com のアドレス）
  • Microsoft（@outlook.com と @hotmail.com のアドレス）
  • Apple（アカウントは常に検証され、多要素認証されるため、常に確認済み）

信頼できないプロバイダ:

  • Facebook
  • Twitter
  • GitHub
  • ID プロバイダによって発行されていないドメインに対する Google、Yahoo、Microsoft
  • メール確認なしのメールアドレス / パスワード

Identity Platform では、同じメールアドレスを使用してユーザーが複数のプロバイダにログインすると、アカウントが自動的にリンクされることがあります。ただし、このエラーが発生するのは特定の条件を満たす場合のみです。たとえば、ユーザーが @gmail.com アカウントで Google を使用してログインし、悪意のある人物が同じ @gmail.com アドレスを使用してアカウントを作成し、Facebook 経由でログインする場合を考えてみます。これら 2 つのアカウントが自動的にリンクされると、悪意のある人物がユーザーのアカウントにアクセスできるようになります。

以下の例は、アカウントが自動的にリンクされる場合と、ユーザーやデベロッパーによる対応が必要となるエラーがスローされる場合を示しています。

  • ユーザーが信頼されていないプロバイダでログインし、同じメールアドレスで別の信頼されていないプロバイダを使用してログインする（たとえば Facebook に続いて GitHub など）。その場合、アカウントのリンクが必要となるエラーが発生します。
  • ユーザーが信頼済みのプロバイダでログインした後、同じメールアドレスで信頼されていないプロバイダでログインする（たとえば、Google に続いて Facebook など）。その場合、アカウントのリンクが必要となるエラーが発生します。
  • ユーザーが信頼されていないプロバイダでログインし、同じメールアドレスで信頼済みのプロバイダを使用してログインする（たとえば Facebook に続いて Google など）。信頼済みプロバイダによって、信頼されていないプロバイダが上書きされます。ユーザーが Facebook でもう一度ログインしようとすると、アカウント リンクを要求するエラーが発生します。
  • ユーザーが信頼済みのプロバイダでログインした後、同じメールアドレスで別の信頼済みのプロバイダでログインする（たとえば、Apple に続いて Google など）。両方のプロバイダはエラーなしでリンクされます。

Admin SDK を使用して手動でメールアドレスを確認済みとして設定することもできますが、ユーザーが実際にそのメールアドレスを所有していることがわかっている場合にのみ行うようにしてください。