Firebase Summit で発表されたすべての情報をご覧ください。Firebase を使用してアプリ開発を加速し、自信を持ってアプリを実行する方法を紹介しています。詳細

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

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

Firebaseユーザーオブジェクトは、プロジェクト内のアプリにサインアップしたユーザー アカウントを表します。通常、アプリには多くの登録ユーザーがおり、プロジェクト内のすべてのアプリはユーザー データベースを共有します。

ユーザー インスタンスは Firebase Authentication インスタンスから独立しているため、同じコンテキスト内で異なるユーザーへの複数の参照を持ち、それらのメソッドを呼び出すことができます。

ユーザー プロパティ

Firebase ユーザーには、プロジェクトのユーザー データベースに保存された固定の基本プロパティ セット (一意の ID、プライマリ メール アドレス、名前、写真の URL) があり、ユーザー ( iOSAndroidweb ) が更新できます。他のプロパティをユーザー オブジェクトに直接追加することはできません。代わりに、追加のプロパティを Google Cloud Firestore などの他のストレージ サービスに保存できます。

ユーザーがアプリに初めてサインアップすると、利用可能な情報を使用してユーザーのプロファイル データが入力されます。

  • ユーザーが電子メール アドレスとパスワードでサインアップした場合、プライマリ電子メール アドレス プロパティのみが入力されます。
  • ユーザーが Google や Facebook などのフェデレーション ID プロバイダーにサインアップした場合、プロバイダーによって提供されたアカウント情報は、ユーザーのプロファイルを入力するために使用されます。
  • ユーザーがカスタム認証システムにサインアップした場合は、ユーザーのプロファイルに必要な情報を明示的に追加する必要があります

ユーザー アカウントが作成されたら、ユーザーの情報を再読み込みして、ユーザーが別のデバイスで行った可能性のある変更を組み込むことができます。

サインイン プロバイダー

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

ユーザー インスタンスは、ユーザーにリンクされたすべてのプロバイダーを追跡します。これにより、プロバイダーから提供された情報を使用して、空のプロファイルのプロパティを更新できます。ユーザーの管理 ( iOSAndroidweb ) を参照してください。

現在のユーザー

ユーザーがサインアップまたはサインインすると、そのユーザーは Auth インスタンスの現在のユーザーになります。インスタンスはユーザーの状態を保持するため、(ブラウザーで) ページを更新したり、アプリケーションを再起動したりしても、ユーザーの情報は失われません。

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

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

Auth インスタンスの現在の状態を追跡するための推奨される方法は、リスナー (JavaScript では「オブザーバー」とも呼ばれます) を使用することです。 Auth リスナーは、Auth オブジェクトに関連する何かが発生するたびに通知を受け取ります。ユーザーの管理 ( iOSAndroidweb ) を参照してください。

認証リスナーは、次の状況で通知を受け取ります。

  • Auth オブジェクトの初期化が完了し、ユーザーが以前のセッションから既にサインインしているか、ID プロバイダーのサインイン フローからリダイレクトされている
  • ユーザーがサインインする (現在のユーザーが設定されている)
  • ユーザーがサインアウトする (現在のユーザーが null になる)
  • 現在のユーザーのアクセス トークンが更新されます。このケースは、次の条件で発生する可能性があります。
    • アクセス トークンの有効期限が切れる: これは一般的な状況です。リフレッシュ トークンは、新しい有効なトークン セットを取得するために使用されます。
    • ユーザーがパスワードを変更すると、Firebase は新しいアクセス トークンと更新トークンを発行し、古いトークンを期限切れにします。これにより、セキュリティ上の理由から、ユーザーのトークンが自動的に期限切れになり、すべてのデバイスでユーザーがサインアウトされます。
    • ユーザーの再認証: 一部のアクションでは、ユーザーの資格情報が最近発行されたものである必要があります。このようなアクションには、アカウントの削除、プライマリ メール アドレスの設定、パスワードの変更が含まれます。ユーザーをサインアウトしてから再度サインインする代わりに、ユーザーから新しい資格情報を取得し、新しい資格情報をユーザー オブジェクトの reauthenticate メソッドに渡します。

ユーザーセルフサービス

デフォルトでは、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 によって作成されます。これらのトークンは、Firebase プロジェクトでユーザーを安全に識別する署名付き JWT です。これらのトークンには、Firebase プロジェクトに固有のユーザー ID 文字列など、ユーザーの基本的なプロファイル情報が含まれています。 ID トークンの整合性は検証できるため、ID トークンをバックエンド サーバーに送信して、現在サインインしているユーザーを特定できます。
ID プロバイダーのトークンGoogle や Facebook などのフェデレーション ID プロバイダーによって作成されます。これらのトークンはさまざまな形式にすることができますが、多くの場合 OAuth 2.0 アクセス トークンです。アプリはこれらのトークンを使用して、ユーザーが ID プロバイダーで正常に認証されたことを確認し、Firebase サービスで使用できる資格情報に変換します。
Firebase カスタム トークンユーザーが認証システムを使用してアプリにサインインできるようにするために、カスタム認証システムによって作成されます。カスタム トークンは、サービス アカウントの秘密鍵を使用して署名された JWT です。アプリは、フェデレーション ID プロバイダーから返されたトークンを使用するのと同じように、これらのトークンを使用します。

確認済みのメールアドレス

Firebase は、メールが次の 2 つの条件を満たしている場合に検証済みと見なします。

電子メールを一度検証するが、ユーザーが再検証を必要とせずに電子メール アドレスを変更できるようにする IdP は信頼されません。ドメインを所有しているか、常に検証を必要とする IdP は、信頼されていると見なされます。

信頼できるプロバイダー:

  • Google (@gmail.com アドレス用)
  • Yahoo (@yahoo.com アドレス用)
  • Microsoft (@outlook.com および @hotmail.com アドレス用)
  • Apple (アカウントは常に検証され、多要素認証されるため、常に検証されます)

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

  • フェイスブック
  • ツイッター
  • GitHub
  • その ID プロバイダーによって発行されていないドメインの Google、Yahoo、および Microsoft
  • 電子メール/電子メール認証なしのパスワード

場合によっては、ユーザーが同じメール アドレスを使用して別のプロバイダーでサインインすると、Firebase が自動的にアカウントをリンクします。ただし、これは特定の基準が満たされた場合にのみ発生します。その理由を理解するために、次の状況を考えてみましょう: ユーザーが @gmail.com アカウントで Google を使用してサインインし、悪意のあるアクターが同じ @gmail.com アドレスを使用してアカウントを作成しますが、Facebook 経由でサインインします。これら 2 つのアカウントが自動的にリンクされた場合、悪意のあるアクターはユーザーのアカウントにアクセスできます。

次のケースでは、アカウントを自動的にリンクする場合と、ユーザーまたは開発者のアクションが必要なエラーをスローする場合について説明します。

  • ユーザーが信頼されていないプロバイダーでサインインし、同じ電子メールを使用して別の信頼されていないプロバイダーでサインインします (たとえば、Facebook に続いて GitHub)。これにより、アカウントのリンクが必要なエラーがスローされます。
  • ユーザーが信頼できるプロバイダーでサインインしてから、同じ電子メールを使用して信頼できないプロバイダーでサインインします (たとえば、Google の後に Facebook が続きます)。これにより、アカウントのリンクが必要なエラーがスローされます。
  • ユーザーが信頼されていないプロバイダーでサインインしてから、信頼できるプロバイダーで同じ電子メールを使用してサインインします (たとえば、Facebook の後に Google が続く)。信頼できるプロバイダーは、信頼できないプロバイダーを上書きします。ユーザーが Facebook で再度サインインしようとすると、アカウントのリンクが必要なエラーが発生します。
  • ユーザーが信頼できるプロバイダーでサインインし、次に同じ電子メールで別の信頼できるプロバイダーでサインインします (たとえば、Apple の後に Google が続きます)。両方のプロバイダーがエラーなしでリンクされます。

Admin SDK を使用して電子メールを手動で検証済みとして設定することもできますが、ユーザーが実際に電子メールを所有していることがわかっている場合にのみ、これを行うことをお勧めします。