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 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: 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 Google 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 Sie die Mehrfachnutzung verwenden, müssen Sie eine HTTP-Anfrage senden, um diese Funktionen pro Tenant zu deaktivieren.
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:
- Der Nutzer schließt den Identity Platform-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:
- 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 Identity Platform automatisch Konten, wenn sich ein Nutzer mit verschiedenen Anbietern über dieselbe E-Mail-Adresse 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.