Logto Produktaktualisierungen

Logto API SDK#

Ein TypeScript SDK zur Interaktion mit der Logto Management API mittels Client-Credentials-Authentifizierung.

Funktionsweise:

1. Erstelle eine Machine-to-Machine-Anwendung in der Logto-Konsole.
2. Gewähre der Anwendung Zugriff auf die Management API.
3. Installiere das SDK via npm: npm install @logto/api
4. Verwende createManagementApi(), um einen typisierten Management API-Client mit den Anmeldedaten deiner Anwendung zu erstellen.

Highlights:

• Handhabt automatisch OAuth-Token-Authentifizierung und -Erneuerung.
• Unterstützt sowohl Logto Cloud als auch selbstgehostete Instanzen.
• Vereinfacht die Integration mit der Logto Management API, sodass du dich auf das Entwickeln von Features statt auf das Handling von Low-Level-API-Anfragen konzentrieren kannst.

Geheimer Tresor (Secret vault)#

Der geheime Tresor ist eine sichere Speicherlösung in Logto, um sensible Benutzerdaten zu verwalten, darunter Zugriffstoken, API-Schlüssel, Zugangscodes und andere vertrauliche Informationen. Diese Geheimnisse werden typischerweise genutzt, um im Namen der Benutzer auf Drittanbieterdienste zuzugreifen, weshalb eine sichere Speicherung entscheidend ist.

Unterstützung für föderierte Token-Speicherung#

Die Token-Speicherung wird jetzt für soziale und Enterprise SSO-Connectoren unterstützt. Bei Aktivierung speichert Logto das vom Identity Provider ausgegebene Token-Set nach erfolgreicher Authentifizierung. Anwendungen können dann später das Zugriffstoken abrufen – ohne dass sich der Benutzer erneut authentifizieren muss –, um Drittanbieter-APIs aufzurufen.

Unterstützte Connectoren:

• Soziale Connectoren: GitHub, Google, Facebook, Standard OAuth 2.0 und Standard OIDC
• Enterprise SSO-Connectoren: Alle OIDC-basierten SSO-Connectoren

Funktionsweise:

1. Aktiviere die Token-Speicherung für soziale und Enterprise SSO-Connectoren in der Logto-Konsole oder über die Logto Management API.
2. Nach der Aktivierung speichert Logto automatisch das vom Anbieter nach erfolgreicher Benutzer-Authentifizierung ausgegebene Token-Set.
3. Rufe das gespeicherte Token bei Bedarf über die Account API ab.

Für mehr Details siehe die Secret vault-Dokumentation.

Hinzufügen von TOTP und Backup-Codes über die Account API#

Benutzer können nun TOTP und Backup-Codes über die Account API hinzufügen.

• POST /api/my-account/mfa-verifications/totp-secret/generate: Ein TOTP-Geheimnis generieren.
• POST /api/my-account/mfa-verifications/backup-codes/generate: Backup-Codes generieren.
• POST /api/my-account/mfa-verifications: Ein TOTP oder Backup-Code mit dem generierten Geheimnis oder den Codes hinzufügen.
• GET /api/my-account/mfa-verifications/backup-codes: Backup-Codes abrufen.

Weitere Verbesserungen#

• Soziale Connectoren: Unterstützung für das Bereitstellen eines benutzerdefinierten scope-Parameters beim Generieren der Authorisierungs-URL für soziale Connectoren hinzugefügt. Dadurch kannst du beim Aufruf des Logto social verification endpoint zusätzliche Berechtigungen vom Social Provider anfordern. Wird der Scope angegeben, wird dieser für die Authorisierungsanfrage verwendet; andernfalls wird der in den Connector-Einstellungen konfigurierte Standard-Scope benutzt.
• Konsole: Um die neue Secret vault-Funktion besser zu unterstützen, haben wir das Layout der Benutzer-Detailseite überarbeitet. Soziale sowie Enterprise SSO-Identitäten eines Benutzers sind jetzt im neuen Bereich „Verbindung“ organisiert. In diesem Abschnitt werden alle verknüpften Verbindungen eines Benutzers aufgelistet und Informationen zu Drittanbieter-Identitäten sowie zum Status der Token-Speicherung (falls zutreffend) angezeigt. Für jede Verbindung gibt es zudem eine detaillierte Benutzer-Identitätsseite mit weiteren Informationen zur verknüpften Identität und den zugehörigen Tokens.

Fehlerbehebungen#

Mandantenbezogene Fremdschlüsselbeschränkung für die Tabelle organization_user_relations

Problem

Entwickler konnten versehentlich eine user_id aus einem anderen Mandanten einer Organisation zuweisen, was bei API-Endpunkten für Organisationsbenutzer zu 500er-Fehlern führte. Die ursprüngliche Tabelle organization_user_relations hatte nur eine Fremdschlüsselbeschränkung auf users (id), sodass jede existierende User-ID zugewiesen werden konnte, unabhängig von der Mandantentrennung.

Ursache

Logto setzt Row Level Security (RLS) auf allen Tabellen ein, um den Datenzugriff mandantengerecht zu isolieren. Sobald die Users-Tabelle mit organization_user_relations verknüpft wurde, waren die eigentlichen Benutzerdaten für den aktuellen Mandanten durch RLS nicht mehr zugänglich, was dazu führte, dass die Benutzerdaten als null zurückkamen und dadurch 500er-Serverfehler ausgelöst wurden.

Lösung

Eine zusammengesetzte Fremdschlüsselbeschränkung (tenant_id, user_id), die auf users (tenant_id, id) verweist, wurde hinzugefügt, um sicherzustellen, dass die Tenant-ID aus der Organisations-Benutzer-Zuordnung mit der Tenant-ID des Benutzers übereinstimmt. Dadurch wird die korrekte Mandantentrennung auf Datenbankebene erzwungen.