Benutzer-Datenstruktur

Benutzer sind die Kerneinheiten im Identitätsdienst. In Logto umfassen sie grundlegende Authentifizierungsdaten basierend auf dem OpenID Connect-Protokoll sowie benutzerdefinierte Daten.

Benutzerprofil

Jeder Benutzer hat ein Profil, das alle Benutzerinformationen enthält.

Es besteht aus den folgenden Datentypen:

Grundlegende Daten: sind die Basisinformationen aus dem Benutzerprofil. Sie speichern alle anderen Eigenschaften des Benutzers, außer den sozialen identities und custom_data, wie Benutzer-ID, Benutzername, E-Mail, Telefonnummer und wann sich der Benutzer zuletzt angemeldet hat.
Soziale Identitäten: speichert die Benutzerinformationen, die von der sozialen Anmeldung (d. h. Anmeldung mit einem sozialen Connector) abgerufen wurden, wie Facebook, GitHub und WeChat.
Benutzerdefinierte Daten: speichert zusätzliche Benutzerinformationen, die nicht in den vordefinierten Benutzereigenschaften aufgeführt sind, wie die vom Benutzer bevorzugte Farbe und Sprache.

Hier ist ein Beispiel für die Daten eines Benutzers, die von einer Anmeldung bei Facebook abgerufen wurden:

{
  "id": "iHXPuSb9eMzt",
  "username": null,
  "primaryEmail": null,
  "primaryPhone": null,
  "name": "John Doe",
  "avatar": "https://example.com/avatar.png",
  "customData": {
    "preferences": {
      "language": "en",
      "color": "#f236c9"
    }
  },
  "identities": {
    "facebook": {
      "userId": "106077000000000",
      "details": {
        "id": "106077000000000",
        "name": "John Doe",
        "email": "[email protected]",
        "avatar": "https://example.com/avatar.png"
      }
    }
  },
  "lastSignInAt": 1655799453171,
  "applicationId": "admin_console"
}

Du kannst das Benutzerprofil mit Logto Console oder der Logto Management API abfragen, wie z. B. GET /api/users/:userId.

Grundlegende Daten

Lass uns alle Eigenschaften der grundlegenden Daten eines Benutzers durchgehen.

id

id ist ein einzigartiger, automatisch generierter Schlüssel, um den Benutzer in Logto zu identifizieren.

username

username wird für die Anmeldung mit Benutzername und Passwort verwendet.

Sein Wert stammt von dem Benutzernamen, mit dem sich der Benutzer zuerst registriert hat. Er kann null sein. Sein nicht-null-Wert sollte nicht länger als 128 Zeichen sein, nur Buchstaben, Zahlen und Unterstriche (_) enthalten und NICHT mit einer Zahl beginnen.

primary_email

primary_email ist die E-Mail-Adresse des Benutzers, die für die Anmeldung mit der E-Mail und dem Passcode verwendet wird.

Sein Wert stammt normalerweise von der E-Mail-Adresse, mit der sich der Benutzer zuerst registriert hat. Er kann null sein. Seine maximale Länge beträgt 128.

primary_phone

primary_phone ist die Telefonnummer des Benutzers, die für die Anmeldung mit der Telefonnummer und dem Passcode aus der SMS verwendet wird.

Sein Wert stammt normalerweise von der Telefonnummer, mit der sich der Benutzer zuerst registriert hat. Er kann null sein. Sein nicht-null-Wert sollte Zahlen enthalten, die mit dem Ländervorwahl (ohne das Pluszeichen +) beginnen.

name

name ist der vollständige Name des Benutzers. Seine maximale Länge beträgt 128.

avatar

avatar ist die URL, die auf das Avatarbild des Benutzers zeigt. Seine maximale Länge beträgt 2048.

Wenn sich der Benutzer mit einem sozialen Connector wie Google und Facebook registriert, kann sein Wert aus den sozialen Benutzerinformationen abgerufen werden.

hinweis

Diese Eigenschaft wird im OpenID Connect Standard dem picture Anspruch zugeordnet.

profile

profile speichert zusätzliche OpenID Connect Standardansprüche, die nicht in den Benutzereigenschaften enthalten sind.

Seine Typdefinition kann in dieser Datei gefunden werden. Hier ist eine Kopie der Typdefinition:

type UserProfile = Partial<{
  familyName: string;
  givenName: string;
  middleName: string;
  nickname: string;
  preferredUsername: string;
  profile: string;
  website: string;
  gender: string;
  birthdate: string;
  zoneinfo: string;
  locale: string;
  address: Partial<{
    formatted: string;
    streetAddress: string;
    locality: string;
    region: string;
    postalCode: string;
    country: string;
  }>;
}>;

hinweis

Partial bedeutet, dass alle Eigenschaften optional sind.

Ein Unterschied im Vergleich zu den anderen Standardansprüchen besteht darin, dass die Eigenschaften in profile nur dann im ID-Token oder in der Antwort des Benutzerinfo-Endpunkts enthalten sind, wenn ihre Werte nicht leer sind, während andere Standardansprüche null zurückgeben, wenn die Werte leer sind.

application_id

Der Wert von application_id stammt von der Anwendung, bei der sich der Benutzer zuerst angemeldet hat. Er kann null sein.

last_signed_in_at

last_signed_in_at ist der Zeitstempel mit der Zeitzone, wann sich der Benutzer zuletzt angemeldet hat.

password_encrypted

password_encrypted wird verwendet, um das verschlüsselte Passwort des Benutzers zu speichern.

Sein Wert stammt von dem Passwort, mit dem sich der Benutzer zuerst registriert hat. Er kann null sein. Wenn sein Wert nicht null ist, sollte sein ursprünglicher Inhalt vor der Verschlüsselung mindestens sechs Zeichen lang sein.

password_encryption_method

password_encryption_method wird verwendet, um das Passwort des Benutzers zu verschlüsseln. Sein Wert wird initialisiert, wenn sich der Benutzer mit dem Benutzernamen und Passwort registriert. Er kann null sein.

Logto verwendet standardmäßig die Argon2-Implementierung node-argon2 als Verschlüsselungsmethode; siehe die Referenz für Details, wenn du interessiert bist.

Beispiel für ein password_encrypted und password_encryption_method von einem Benutzer, dessen Passwort 123456 ist:

{
  "password_encryption_method": "Argon2i",
  "password_encrypted": "$argon2i$v=19$m=4096,t=10,p=1$aZzrqpSX45DOo+9uEW6XVw$O4MdirF0mtuWWWz68eyNAt2u1FzzV3m3g00oIxmEr0U"
}

is_suspended

is_suspended ist ein boolescher Wert, der angibt, ob ein Benutzer gesperrt ist oder nicht. Der Wert kann durch Aufrufen der Logto Management API oder über die Admin Console verwaltet werden.

Sobald ein Benutzer gesperrt ist, werden die zuvor gewährten Auffrischungstokens sofort widerrufen und der Benutzer kann sich nicht mehr bei Logto authentifizieren.

Eigenschaftsreferenz

Die folgenden Eigenschaften (außer password_encrypted und password_encryption_method) sind im Benutzerprofil sichtbar, was bedeutet, dass du sie mit der Management API abfragen kannst.

Name	Typ	Beschreibung	Einzigartig	Erforderlich
id	string	Eindeutiger Identifikator	✅	✅
username	string	Benutzername für die Anmeldung	✅	❌
primary_email	string	Primäre E-Mail	✅	❌
primary_phone	string	Primäre Telefonnummer	✅	❌
name	string	Vollständiger Name	❌	❌
avatar	string	URL, die auf das Avatarbild des Benutzers zeigt	❌	❌
identities	object	Benutzerinformationen aus der sozialen Anmeldung	❌	✅
custom_data	object	Zusätzliche Informationen in anpassbaren Eigenschaften	❌	✅
application_id	string	Anwendungs-ID, bei der sich der Benutzer zuerst registriert hat	❌	✅
last_sign_in_at	date time	Zeitstempel, wann sich der Benutzer zuletzt angemeldet hat	❌	✅
password_encrypted	string	Verschlüsseltes Passwort	❌	❌
password_encryption_method	string	Passwortverschlüsselungsmethode	❌	❌
is_suspended	bool	Benutzer-Sperrmarkierung	❌	✅

Einzigartig: Stellt die Einzigartigkeit der in eine Eigenschaft einer Datenbanktabelle eingegebenen Werte sicher.
Erforderlich: Stellt sicher, dass die in eine Eigenschaft einer Datenbanktabelle eingegebenen Werte NICHT null sein können.

Soziale Identitäten

identities enthält die Benutzerinformationen, die von der sozialen Anmeldung (d. h. Anmeldung mit einem sozialen Connector) abgerufen wurden. Jede identities eines Benutzers wird in einem individuellen JSON-Objekt gespeichert.

Die Benutzerinformationen variieren je nach Anbieter der sozialen Identität (d. h. soziale Netzwerkplattform) und umfassen typischerweise Folgendes:

target des Identitätsanbieters, wie "facebook" oder "google"
Eindeutiger Identifikator des Benutzers für diesen Anbieter
Name des Benutzers
Verifizierte E-Mail des Benutzers
Avatar des Benutzers

Das Benutzerkonto kann mit mehreren Anbietern sozialer Identitäten über die soziale Anmeldung verknüpft sein; die entsprechenden Benutzerinformationen, die von diesen Anbietern abgerufen werden, werden im identities Objekt gespeichert.

Beispiel identities von einem Benutzer, der sich sowohl mit Google als auch mit Facebook angemeldet hat:

{
  "facebook": {
    "userId": "5110888888888888",
    "details": {
      "id": "5110888888888888",
      "name": "John Doe",
      "email": "[email protected]",
      "avatar": "https://example.com/avatar.png"
    }
  },
  "google": {
    "userId": "111000000000000000000",
    "details": {
      "id": "111000000000000000000",
      "name": "John Doe",
      "email": "[email protected]",
      "avatar": "https://example.com/avatar.png"
    }
  }
}

Benutzerdefinierte Daten

custom_data speichert zusätzliche Benutzerinformationen, die nicht in den vordefinierten Benutzereigenschaften aufgeführt sind.

Du kannst custom_data verwenden, um Folgendes zu tun:

Aufzeichnen, ob bestimmte Aktionen vom Benutzer durchgeführt wurden, wie z. B. das Sehen der Willkommensseite.
Anwendungsspezifische Daten im Benutzerprofil speichern, wie die bevorzugte Sprache und das Erscheinungsbild des Benutzers pro Anwendung.
Andere beliebige Daten im Zusammenhang mit dem Benutzer pflegen.

Beispiel custom_data von einem Admin-Benutzer in Logto:

{
  "adminConsolePreferences": {
    "language": "en",
    "appearanceMode": "system",
    "experienceNoticeConfirmed": true
  },
  "customDataFoo": {
    "foo": "foo"
  },
  "customDataBar": {
    "bar": "bar"
  }
}

Jede custom_data eines Benutzers wird in einem individuellen JSON-Objekt gespeichert.

Lege KEINE sensiblen Daten in custom_data

Du kannst ein Benutzerprofil mit custom_data über die Management API abrufen und an Frontend-Apps oder externe Backend-Dienste senden. Daher kann das Speichern sensibler Informationen in custom_data zu Datenlecks führen.

Wenn du dennoch sensible Informationen in custom_data speichern möchtest, empfehlen wir, sie zuerst zu verschlüsseln. Verschlüssele/entschlüssle sie nur in einer vertrauenswürdigen Partei wie deinen Backend-Diensten und vermeide es, dies in den Frontend-Apps zu tun. Dies minimiert den Verlust, falls die custom_data deiner Benutzer versehentlich geleakt wird.

Du kannst die custom_data eines Benutzers über die Admin Console oder die Logto Management API aktualisieren, wie z. B. PATCH /api/users/:userId.

Vorsichtig aktualisieren

Das Aktualisieren der custom_data eines Benutzers überschreibt vollständig den ursprünglichen Inhalt im Speicher.

Zum Beispiel, wenn dein Eingabewert beim Aufrufen der Update-custom_data-API so aussieht (angenommen, die ursprünglichen custom_data sind die zuvor gezeigten Beispieldaten):

{
  "customDataBaz": {
    "baz": "baz"
  }
}

dann sollte der neue custom_data-Wert nach der Aktualisierung so aussehen:

{
  "customDataBaz": {
    "baz": "baz"
  }
}

Das heißt, der aktualisierte Feldwert hat nichts mit dem vorherigen Wert zu tun.

Benutzerprofil​

Grundlegende Daten​

id​

username​

primary_email​

primary_phone​

name​

avatar​

profile​

application_id​

last_signed_in_at​

password_encrypted​

password_encryption_method​

is_suspended​

Eigenschaftsreferenz​

Soziale Identitäten​

Benutzerdefinierte Daten​

Verwandte Ressourcen​