Firebase プロジェクトのユーザー

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

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

ユーザープロパティ

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

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

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

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

認証トークン

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

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

確認済みメールアドレス

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

ユーザーが Firebase の確認フローを完了済み。
メールアドレスが、信頼できる 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
メール確認なしのメールアドレス / パスワード

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

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

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

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