🎉 Vorstellung unseres Juli-Releases: Logto API SDK, geheimer Tresor zur Speicherung föderierter Tokens, Verwaltung von TOTP und Backup-Codes über die Account API und mehr!
Ein TypeScript SDK zur Interaktion mit der Logto Management API mittels Client-Credentials-Authentifizierung.
Funktionsweise:
npm install @logto/apicreateManagementApi(), um einen typisierten Management API-Client mit den Anmeldedaten deiner Anwendung zu erstellen.Highlights:
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.
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:
Funktionsweise:
Für mehr Details siehe die Secret vault-Dokumentation.
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.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.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.