Zum Hauptinhalt springen

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 aus 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 aus 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 über Logto Console oder Logto Management API abfragen, wie zum Beispiel 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 zur Identifizierung des Benutzers in Logto.

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. Er ist case-sensitiv.

primary_email​

primary_email ist die E-Mail-Adresse des Benutzers, die für die Anmeldung mit E-Mail und Passwort / Verifizierungscode 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 Telefonnummer und Passwort / Verifizierungscode aus 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 +) versehen sind.

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, als 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 Benutzername und Passwort registriert. Er kann null sein.

Logto verwendet standardmäßig die Implementierung node-argon2 von 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 durch die Verwendung von Logto 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.

NameTypBeschreibungEinzigartigErforderlich
idstringEindeutiger Identifikator✅✅
usernamestringBenutzername für die Anmeldung✅❌
primary_emailstringPrimäre E-Mail✅❌
primary_phonestringPrimäre Telefonnummer✅❌
namestringVollständiger Name❌❌
avatarstringURL, die auf das Avatarbild des Benutzers zeigt❌❌
identitiesobjectBenutzerinformationen aus der sozialen Anmeldung❌✅
custom_dataobjectZusätzliche Informationen in anpassbaren Eigenschaften❌✅
application_idstringAnwendungs-ID, bei der sich der Benutzer zuerst registriert hat❌✅
last_sign_in_atdate timeZeitstempel, als sich der Benutzer zuletzt angemeldet hat❌✅
password_encryptedstringVerschlüsseltes Passwort❌❌
password_encryption_methodstringPasswortverschlüsselungsmethode❌❌
is_suspendedboolBenutzer-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 aus der sozialen Anmeldung (d. h. Anmeldung mit einem sozialen Connector) abgerufen wurden. Die identities jedes Benutzers werden 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 Konto des Benutzers kann über die soziale Anmeldung mit mehreren Anbietern sozialer Identitäten 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 vom Benutzer bevorzugte Sprache und das Erscheinungsbild 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"
  }
}

Die custom_data jedes Benutzers wird in einem individuellen JSON-Objekt gespeichert.

Hinweis: Lege KEINE sensiblen Daten in custom_data ab.

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

Wenn du dennoch sensible Informationen in custom_data ablegen 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 dies in den Frontend-Apps. Dies minimiert den Verlust, falls die custom_data deiner Benutzer versehentlich geleakt wird.

Du kannst die custom_data des Benutzers über Logto Console oder Logto Management API aktualisieren, wie zum Beispiel 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 Aktualisierung der custom_data API so aussieht (angenommen, dass die ursprünglichen custom_data die zuvor gezeigten Beispieldaten sind):

{
  "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.

Sicherer Hub für Benutzerdaten in Bewegung