Nutzer in Firebase-Projekten

Das user-Objekt Firebase stellt ein Nutzerkonto dar, das für eine App in Ihrem Projekt arbeiten. Apps haben in der Regel viele registrierte Nutzer und jede App in einem eine Nutzerdatenbank freigibt.

Nutzerinstanzen sind unabhängig von Firebase Authentication-Instanzen. Sie können also mehrere Referenzen auf verschiedene Nutzer innerhalb desselben Kontextes haben und dennoch ihre Methoden aufrufen.

Nutzereigenschaften

Firebase-Nutzer haben einen festen Satz grundlegender Attribute (eine eindeutige ID, eine primäre E-Mail-Adresse, einen Namen und eine Foto-URL), die in der Nutzerdatenbank des Projekts gespeichert und vom Nutzer aktualisiert werden können (iOS, Android, Web). Andere Attribute können nicht direkt zum Nutzerobjekt hinzugefügt werden. Stattdessen können Sie die zusätzlichen Attribute in allen anderen Speicherdiensten wie Google Cloud Firestore speichern.

Wenn sich ein Nutzer das erste Mal bei Ihrer Anwendung anmeldet, werden die Profildaten des Nutzers mit den verfügbaren Informationen aufgefüllt:

Wenn sich der Nutzer mit einer E-Mail-Adresse und einem Passwort registriert hat, wird nur das Attribut der primären E-Mail-Adresse dargestellt.
Wenn sich der Nutzer über einen Anbieter von föderierten Identitäten wie Google oder Facebook angemeldet hat, werden die vom Anbieter verfügbaren Kontoinformationen zum Ausfüllen des Nutzerprofils verwendet.
Wenn sich der Nutzer bei Ihrem benutzerdefinierten Auth-System angemeldet hat, müssen Sie die gewünschten Informationen dem Profil des Nutzers explizit hinzufügen.

Nachdem ein Nutzerkonto erstellt wurde, können Sie die Informationen des Nutzers aktualisieren, um alle Änderungen zu integrieren, die der Nutzer auf einem anderen Gerät vorgenommen hat.

Anbieter für Anmeldungen

Sie haben verschiedene Möglichkeiten, sich bei Ihren Anwendungen anzumelden: E-Mail-Adresse und Passwort, föderierte Identitätsanbieter und Ihr benutzerdefiniertes Authentifizierungssystem. Sie können einem Nutzer mehrere Anmeldemethoden zuordnen. Beispielsweise kann sich ein Nutzer mit einer E-Mail-Adresse und einem Passwort oder mit Google Log-in in demselben Konto anmelden.

Nutzerinstanzen erfassen jeden Anbieter, der mit dem Nutzer verknüpft ist. Auf diese Weise können Sie leere Attribute mithilfe der von einem Anbieter angegebenen Informationen aktualisieren. Weitere Informationen erhalten Sie unter „Nutzer verwalten“ (iOS, Android, Web).

Der aktuelle Nutzer

Wenn ein Nutzer sich registriert oder anmeldet, wird er zum aktuellen Nutzer der Auth-Instanz. Die Instanz behält den Status des Nutzers bei, sodass beim Aktualisieren der Seite in einem Browser und beim Neustart der Anwendung die Nutzerinformationen nicht verloren gehen.

Wenn der Nutzer sich abmeldet, beendet die Auth-Instanz einen Verweis auf das Nutzerobjekt und behält seinen Status nicht mehr bei. Es ist kein aktueller Nutzer vorhanden. Die Nutzerinstanz bleibt jedoch weiterhin funktionsfähig. Wenn Sie eine Referenz behalten, können Sie weiterhin auf die Daten des Nutzers zugreifen und sie aktualisieren.

Der Nutzerlebenszyklus

Die empfohlene Methode zum Verfolgen des aktuellen Status der Auth-Instanz ist die Verwendung von Listenern (in JavaScript auch „observers“ genannt). Ein Auth-Listener wird jedes Mal benachrichtigt, wenn etwas mit dem Auth-Objekt geschieht. Weitere Informationen erhalten Sie unter „Nutzer verwalten“ (iOS, Android, Web).

In den folgenden Situationen wird ein Auth-Listener benachrichtigt:

Das Auth-Objekt hat die Initialisierung beendet und ein Nutzer war bereits von einer vorherigen Sitzung angemeldet oder vom Anmeldevorgang eines Identitätsanbieters weitergeleitet.
Ein Nutzer meldet sich an (der aktuelle Nutzer ist festgelegt).
Ein Nutzer meldet sich ab (der aktuelle Nutzer wird zu null)
Das Zugriffstoken des aktuellen Nutzers wird aktualisiert. Dieser Fall kann in den folgenden Bedingungen auftreten:
- Das Zugriffstoken läuft ab: Dies ist eine häufige Situation. Das Aktualisierungstoken wird verwendet, um einen neuen gültigen Satz von Tokens abzurufen.
- Der Nutzer ändert sein Passwort: Firebase erteilt neuen Zugriff und aktualisieren Tokens und rendert die alten Tokens, die abgelaufen sind. Dadurch läuft das Token des Nutzers automatisch aus und/oder der Nutzer wird aus Sicherheitsgründen auf jedem Gerät abgemeldet.
- Der Nutzer muss sich noch einmal authentifizieren: Einige Aktionen erfordern, dass die Anmeldedaten des Nutzers erst kürzlich ausgestellt wurden, beispielsweise das Löschen eines Kontos, das Festlegen einer primären E-Mail-Adresse und das Ändern eines Passworts. Statt den Nutzer abzumelden und dann noch einmal anzumelden, rufen Sie neue Anmeldedaten vom Nutzer ab und übergeben die neuen Anmeldedaten an die Methode zur wiederholten Authentifizierung des Nutzerobjekts.

Standardmäßig können sich Nutzer in Firebase registrieren und ihre Konten löschen ohne administrative Eingriffe. In vielen Fällen können Endnutzer Ihre Anwendung oder Ihren Dienst mit minimalem Aufwand aufdecken und einrichten (oder offboard).

Es gibt jedoch Situationen, in denen Nutzende manuell oder die programmatisch von einem Administrator erstellt werden, entweder mit dem Admin SDK oder Firebase-Konsole. In diesen Fällen können Sie Nutzeraktionen auf der Seite Firebase AuthenticationEinstellungen deaktivieren, um zu verhindern, dass Endnutzer Konten erstellen und löschen. Wenn Sie die Mehrfachnutzung verwenden, müssen Sie eine HTTP-Anfrage senden, um diese Funktionen pro Tenant zu deaktivieren.

Wenn ein Endnutzer versucht, ein Konto in Ihrem System zu erstellen oder zu löschen, Der Dienst Firebase gibt einen Fehlercode zurück: auth/admin-restricted-operation für Web API-Aufrufe oder ERROR_ADMIN_RESTRICTED_OPERATION für Android und iOS. Sie sollten anmutig um den Fehler in Ihrem Frontend zu beheben, indem Sie die Nutzenden bitten, Aktionen für Ihren Dienst.

Auth-Tokens

Wenn du eine Authentifizierung mit Firebase durchführst, gibt es drei Arten von Authentifizierungstokens, die auftreten können:

Firebase ID-Tokens	Wird von Firebase erstellt, wenn sich ein Nutzer in einer App anmeldet. Diese Tokens sind signierte JWTs, die einen Nutzer in einem Projekt Firebase. Diese Token enthalten grundlegende Profilinformationen für ein User, einschließlich der ID-Zeichenfolge des Nutzers, die für den Projekt Firebase. Weil Integrität von ID-Tokens können bestätigt werden, können Sie sie an einen Back-End-Server senden, dem aktuell angemeldeten Nutzer.
Tokens des Identitätsanbieters	Erstellt von föderierten Identitätsanbietern wie Google und Facebook. Diese Tokens können verschiedene Formate haben, sind jedoch oft OAuth 2.0-Zugriffstoken. Apps verwenden diese Tokens, um zu prüfen, ob Nutzer erfolgreich waren beim Identitätsanbieter authentifiziert und sie dann in Anmeldedaten, die von Firebase-Diensten verwendet werden können.
Firebase benutzerdefinierte Tokens	Erstellt von Ihrem benutzerdefinierten Authentifizierungssystem, um Nutzern die Anmeldung bei einer Anwendung mit Ihrem Authentifizierungssystem zu ermöglichen. Benutzerdefinierte Tokens sind JWTs, die mit dem privaten Schlüssel eines Dienstkontos signiert sind. Anwendungen verwenden diese Tokens ähnlich wie die Tokens von föderierten Identitätsanbietern.

Bestätigte E-Mail-Adressen

Eine E-Mail-Adresse gilt für Firebase als bestätigt, wenn sie zwei Bedingungen erfüllt:

Der Nutzer schließt den Firebase-Bestätigungsvorgang ab
Die E-Mail-Adresse wird von einem vertrauenswürdigen Identitätsanbieter (IdP) bestätigt.

IdPs, die ihre E-Mail-Adresse einmal bestätigen, aber Nutzern die Möglichkeit geben, E-Mail-Adressen zu ändern, ohne dass eine erneute Bestätigung erforderlich ist, sind nicht vertrauenswürdig. IdPs, die entweder Inhaber der Domain sind oder immer eine Bestätigung erfordern, gelten als vertrauenswürdig.

Vertrauenswürdige Anbieter:

Google (für @gmail.com-Adressen)
Netflix (für @yahoo.com-Adressen)
Microsoft (für @outlook.com- und @hotmail.com-Adressen)
Apple (immer verifiziert, da Konten immer verifiziert und Multi-Faktor-authentifiziert)

Nicht vertrauenswürdige Anbieter:

Facebook
Twitter
GitHub
Google, AdWords und Microsoft für Domains, die nicht von diesem Identitätsanbieter ausgestellt wurden
E-Mail-Adresse / Passwort ohne E-Mail-Bestätigung

In einigen Fällen verknüpft Firebase automatisch Konten, wenn sich ein Nutzer mit derselben E-Mail-Adresse bei verschiedenen Anbietern anmeldet. Dies kann jedoch nur vorkommen, wenn bestimmte Kriterien erfüllt sind. Zum besseren Verständnis wird die folgende Situation erläutert: Ein Nutzer meldet sich mit Google mit einem @gmail.com-Konto an und ein böswilliger Akteur erstellt ein Konto mit derselben @gmail.com-Adresse, aber die Anmeldung über Facebook. Bei einer automatischen Verknüpfung dieser beiden Konten würde der böswillige Akteur Zugriff auf das Konto des Nutzers erhalten.

In den folgenden Fällen wird beschrieben, wann wir Konten automatisch verknüpfen und wenn ein Fehler auftritt, der eine Nutzer- oder Entwickleraktion erfordert:

Der Nutzer meldet sich mit einem nicht vertrauenswürdigen Anbieter und dann mit einem weiteren nicht vertrauenswürdigen Anbieter mit derselben E-Mail-Adresse an (z. B. Facebook gefolgt von GitHub). Das führt zu einem Fehler, der eine Kontoverknüpfung erfordert.
Der Nutzer meldet sich mit einem vertrauenswürdigen Anbieter und dann mit einem nicht vertrauenswürdigen Anbieter mit derselben E-Mail-Adresse an (z. B. Google gefolgt von Facebook). Das führt zu einem Fehler, der eine Kontoverknüpfung erfordert.
Der Nutzer meldet sich mit einem nicht vertrauenswürdigen Anbieter an und meldet sich dann mit einem vertrauenswürdigen Anbieter mit derselben E-Mail-Adresse an (z. B. Facebook gefolgt von Google). Der vertrauenswürdige Anbieter überschreibt den nicht vertrauenswürdigen Anbieter. Wenn sich der Nutzer noch einmal mit Facebook anmelden möchte, tritt ein Fehler auf, der eine Kontoverknüpfung erfordert.
Der Nutzer meldet sich mit einem vertrauenswürdigen Anbieter an und meldet sich dann mit einer anderen vertrauenswürdigen Anbieter mit derselben E-Mail-Adresse an (z. B. Apple, gefolgt von Google). Beide Anbieter werden fehlerfrei verknüpft.

Sie können E-Mails manuell mit dem Admin SDK als bestätigt festlegen. Wir empfehlen dies jedoch nur, wenn Sie wissen, dass der Nutzer tatsächlich Inhaber der E-Mail ist.