Identity Platform-Nutzer in Projekten

Das Identity Platform-Nutzer-Objekt stellt ein Nutzerkonto dar, das sich für eine Anwendung in Ihrem Google Cloud-Projekt registriert hat. Anwendungen haben normalerweise viele registrierte Nutzer und jede Anwendung in einem Google Cloud-Projekt nutzt eine gemeinsame Datenbank.

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

Nutzereigenschaften

Identity Platform-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 alle mit dem Nutzer verknüpften Anbieter. 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: Identity Platform gibt neuen Zugriffs- und Aktualisierungstoken aus und rendert die alten Tokens. 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.

Nutzer-Self-Service

Standardmäßig bietet Identity Platform Nutzern die Möglichkeit, sich zu registrieren und Konten ohne Administratorzugriff zu löschen. 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 Nutzer manuell oder programmatisch von einem Administrator erstellt werden sollen, entweder über das Admin SDK oder die Cloud Console. In diesen Fällen können Sie Nutzeraktionen auf der Seite mit den Identity Platform-Einstellungen deaktivieren, um zu verhindern, dass Endnutzer Konten erstellen und löschen.

Wenn ein Endnutzer versucht, ein Konto innerhalb Ihres Systems zu erstellen oder zu löschen, gibt der Identity Platform-Dienst 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 den Fehler in Ihrem Front-End reibungslos handhaben, indem Sie den Nutzer bitten, die erforderlichen Aktionen für Ihren Dienst auszuführen.

Auth-Tokens

Bei der Authentifizierung mit Identity Platform gibt es drei Arten von Authentifizierungstokens:

Identity Platform-ID-Tokens Erstellt von Identity Platform, wenn sich ein Nutzer bei einer Anwendung anmeldet. Diese Tokens sind signierte JWTs, die einen Nutzer in einem Google Cloud-Projekt sicher identifizieren. Diese Tokens enthalten grundlegende Profilinformationen für einen Nutzer, einschließlich der ID des Nutzers, die für das Google Cloud-Projekt eindeutig ist. Da die Integrität der ID-Tokens überprüft werden kann, können Sie sie an einen Back-End-Server senden, um den derzeit angemeldeten Nutzer zu identifizieren.
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. Mithilfe dieser Tokens können Anwendungen prüfen, ob Nutzer sich beim Identitätsanbieter authentifiziert haben, und sie dann in Anmeldedaten umwandeln, die von Identity Platform-Diensten verwendet werden können.
Benutzerdefinierte Identity Platform-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

Identity Platform betrachtet eine E-Mail als bestätigt, wenn sie zwei Bedingungen erfüllt: 1. Der Nutzer führt den Verifizierungsprozess von Identity Platform durch. 2. Die E-Mail-Adresse wird von einem vertrauenswürdigen Identitätsanbieter (IdP) überprüft.

IdPs, die E-Mails einmal bestätigen, erlauben Nutzern aber später, die E-Mail-Adressen zu ändern, ohne dass eine erneute Bestätigung erforderlich ist. IdPs, die entweder die Domain besitzen oder immer eine Bestätigung erfordern, gelten als vertrauenswürdig.

Vertrauenswürdige Anbieter:

  • Google (für @gmail.com-Adressen)
  • Yahoo (für @yahoo.com-Adressen)
  • Microsoft (für @outlook.com- und @hotmail.com-Adressen)
  • Apple (immer überprüft, da Konten immer bestätigt und Multi-Faktor-Authentifizierung sind)

Nicht vertrauenswürdige Anbieter:

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

In manchen Fällen werden in Identity Platform automatisch Konten verknüpft, wenn sich ein Nutzer bei verschiedenen Anbietern mit derselben E-Mail-Adresse anmeldet. Dies kann jedoch nur geschehen, wenn bestimmte Kriterien erfüllt sind. Sehen Sie sich den Grund dafür an: Ein Nutzer meldet sich mit einem @gmail.com-Konto bei Google an und ein böswilliger Akteur erstellt ein Konto mit derselben @gmail.com-Adresse, meldet sich aber über Facebook an. Wenn diese beiden Konten automatisch verknüpft würden, hätte der böswillige Akteur Zugriff auf das Konto des Nutzers.

Die folgenden Fälle beschreiben, wann Konten automatisch verknüpft werden und wann ein Fehler ausgegeben wird, der eine Nutzer- oder Entwickleraktion erfordert:

  • Der Nutzer meldet sich mit einem nicht vertrauenswürdigen Anbieter an und meldet sich dann mit derselben E-Mail-Adresse an, z. B. Facebook gefolgt von GitHub. Dies führt zu einem Fehler, der eine Kontoverknüpfung erfordert.
  • Der Nutzer meldet sich mit einem vertrauenswürdigen Anbieter an und meldet sich mit der E-Mail-Adresse des nicht vertrauenswürdigen Anbieters an (z. B. Google gefolgt von Facebook). Dies 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 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 wieder mit Facebook anmeldet, wird ein Fehler angezeigt, der die Kontoverknüpfung erfordert.
  • Der Nutzer meldet sich mit einem vertrauenswürdigen Anbieter und mit derselben E-Mail-Adresse an, z. B. Apple gefolgt von Google. Beide Anbieter werden fehlerfrei verknüpft.

Sie können eine E-Mail-Adresse manuell mithilfe des Admin SDK als bestätigt markieren, aber wir empfehlen diesen Schritt nur, wenn Sie sicher sind, dass der Nutzer die E-Mail-Adresse besitzt.