Logto Produktupdates (August 2024)

Benutzerimitation (RFC 8693: OAuth 2.0 Token Exchange)#

Unterstützung für Benutzerimitation über Token Exchange hinzugefügt:

• Neuer Management-API-Endpunkt POST /subject-tokens, um ein subject_token für den Token-Austausch anzufordern.
• Aktualisierung des OIDC-Endpunkts POST /oidc/token mit einem neuen Grant-Typ urn:ietf:params:oauth:grant-type:token-exchange, um ein subject_token gegen ein Nutzer-imitiertes access_token auszutauschen.

Siehe Benutzerimitation für weitere Details.

Anwendungsebene custom_data#

Ein neues beliebiges Objektfeld custom_data für Anwendungen hinzugefügt. Dieses Feld kann alle zusätzlichen Informationen speichern, die nicht im Standard-Application-Schema definiert sind.

Klicken, um die Management-API-Updates zu erweitern

• Neuer Endpunkt PATCH /api/applications/{applicationId}/custom-data, um das custom_data-Feld einer Anwendung zu aktualisieren.
• Aktualisierung des Endpunkts PATCH /api/applications/{applicationId}, um das Überschreiben des custom_data-Felds zu ermöglichen.

Klicken, um die Konsolen-Updates zu erweitern

Ein neuer benutzerdefinierter JSON-Editor für das custom_data im Anwendungsdetails-Bereich (außer bei geschützten Apps) hinzugefügt.

Verwaltung mehrerer Anwendungsschlüssel#

Sichere Apps (Machine-to-Machine, traditionelle Webanwendungen, geschützt) können jetzt mehrere Anwendungsschlüssel mit Ablaufdaten haben. Dies ermöglicht eine Schlüsselrotation und bietet eine noch sicherere Erfahrung.

Hinweis: Der vor Einführung dieser Funktion erstellte Altschlüssel kann weiterhin zur Client-Authentifizierung verwendet werden. Es wird jedoch empfohlen, die alten Schlüssel zu löschen und neue Schlüssel mit Ablaufdatum zu erstellen, um die Sicherheit zu erhöhen.

Klicken, um die Management-API-Updates zu erweitern

• GET /api/applications/{applicationId}/secrets: Listet alle Schlüssel einer Anwendung auf.
• POST /api/applications/{applicationId}/secrets: Erstellt einen neuen Schlüssel für eine Anwendung.
• DELETE /api/applications/{applicationId}/secrets/{name}: Löscht einen Schlüssel einer Anwendung anhand des Namens.
• PATCH /api/applications/{applicationId}/secrets/{name}: Aktualisiert einen Schlüssel einer Anwendung anhand des Namens.
• DELETE /api/applications/{applicationId}/legacy-secret: Löscht den Altschlüssel einer Anwendung und ersetzt ihn durch einen neuen.

Klicken, um die Konsolen-Updates zu erweitern

Um deine Anwendungsschlüssel zu verwalten, gehe zu Logto Konsole -> Anwendungen -> Anwendungsdetails -> Endpunkte & Anmeldeinformationen.

Das ursprüngliche schreibgeschützte Eingabefeld für den Anwendungsschlüssel wurde jetzt durch eine neue Schlüsselverwaltungstabelle ersetzt. In dieser Tabelle kannst du Schlüssel erstellen, aktualisieren und löschen.

Branding auf Organisations- und Anwendungsebene#

Organisationslogo#

Es ist jetzt möglich, helle und dunkle Logos für Organisationen festzulegen. Du kannst die Logos auf der Einstellungsseite der Organisation hochladen.

Ebenso ist es möglich, das Anmeldeerfahrungs-Logo einer Organisation zu überschreiben. Füge einfach den Parameter organization_id in die Authentifizierungsanfrage ein. In den meisten Logto-SDKs kann dies über das extraParams-Feld in der signIn-Methode erfolgen.

Zum Beispiel im JavaScript-SDK:

Der Wert <organization-id> kann auf der Einstellungsseite der Organisation gefunden werden.

Falls du das extraParams-Feld im verwendeten SDK nicht findest, lass es uns bitte wissen.

Anwendungsbranding#

Du kannst nun Logos, Favicons und Farben für deine App festlegen. Diese Einstellungen werden in der Anmeldeerfahrung verwendet, wenn die App den Authentifizierungsfluss startet. Für Apps ohne Branding-Einstellungen wird das allgemeine Branding der Anmeldeerfahrung verwendet.

Falls organization_id in der Authentifizierungsanfrage angegeben ist, werden die App-Branding-Einstellungen durch die Branding-Einstellungen der Organisation überschrieben, sofern vorhanden.

Leistungsverbesserungen#

Unterstützung der Server-seitigen Rendering-Erfahrung der App#

Logto injiziert jetzt die Anmeldeerfahrung-Einstellungen und Phrasen in die index.html Datei für eine bessere Erstbildschirm-Performance. Die Erlebnis-App wird die Einstellungen und Phrasen weiterhin vom Server abrufen, wenn:

• Der Server die Einstellungen und Phrasen nicht injiziert hat.
• Die Parameter in der URL von den Server-gerenderten Daten abweichen.

Verbesserungen beim Paketbau#

• tsup wird nun verwendet, um die Konnektor-Pakete zu bauen. Dies beschleunigt den Bauprozess und sollte die Funktionalität der Pakete nicht beeinträchtigen.
• Vite wird für die Transpilation und das Bündeln der Pakete @logto/console, @logto/demo-app und @logto/experience verwendet. ParcelJS wurde entfernt und durch Vite ersetzt. Es sollten keine breaking changes auftreten.

Fehlerbehebungen#

Behebung des jsonb-Aktualisierungsverhaltens des Endpunkts PATCH /api/applications/{applicationId}#

Alle jsonb-Felder des Application-Objekts sollten im replace-Modus und nicht im merge-Modus aktualisiert werden. Diese Änderung macht die PATCH-Methode vorhersehbarer und konsistenter mit dem Restful-API-Design.

• Aktualisierung des jsonb-Feld-Aktualisierungsmodus von merge auf replace im Endpunkt PATCH /api/applications/{applicationId}.
• Aktualisierung der API-jsonb-Feld-Eingabeparametervalidierung von partial auf full im Endpunkt PATCH /api/applications/{applicationId}.
• Betroffene Felder: oidc_client_metadata, custom_client_metadata, protected_app_metadata und custom_data.

Hinweis: Wenn du die Logto-Konsole zum Aktualisieren der Application-Einstellungen verwendest, solltest du von dieser Änderung nicht betroffen sein. API-Nutzer, die die PATCH-Methode verwenden, um die jsonb-Feldeinstellungen der Application zu aktualisieren, sollten sich dieser Änderung bewusst sein. Die PATCH-Methode ersetzt nun das gesamte jsonb-Feld durch die neuen Eingabedaten. Jegliche partielle Eingabedaten in den betroffenen Feldern werden abgelehnt.

Behebung einiger Probleme, bei denen die Webhook-Ereignis-Nutzlast immer den API-Antwortstatus 404 zurückgibt#

Betroffene Webhook-Ereignisse: Role.Scopes.Updated, Organizations.Membership.Updates.

Der vom Webhook-Ereignis-Nutzlast zurückgegebene API-Antwortstatuscode war immer 404. Dies wurde verursacht, indem die Webhook-Ereignis-Nutzlast eingefügt wurde, bevor der API-Antwortkontext festgelegt wurde.

Da wir den Webhook nur auslösen, wenn das Ereignis erfolgreich verarbeitet wurde, sollte der Statuscode immer 2xx sein.

Dieses Problem wurde behoben, indem die Einfügung der Webhook-Ereignis-Nutzlast nach der Festlegung des API-Antwortkontexts verschoben wurde.

Weitere Verbesserungen#

• Das Favicon für das dunkle Thema kann jetzt in den Einstellungen für das Branding der Anmeldeerfahrung festgelegt werden.
• Neue Passwort-Digest-Algorithmen hinzugefügt: Argon2d und Argon2id. Nutzer, die diese Algorithmen verwenden, werden bei erfolgreicher Anmeldung auf Argon2i migriert.
• Die Browserlisten-Konfiguration für @logto/experience wurde mit dem was in der README.md angegeben ist, synchronisiert.
• Verbesserung der Swagger-Auth-Beschreibung. Verwendung des nativen OpenAPI OAuth2 Sicherheitsschemas anstatt eines benutzerdefinierten HTTP-Header-basierten Sicherheitsschemas.