Entdecke unser August 2024 Release mit Benutzerimitation, Verwaltung von Anwendungsschlüsseln, Branding der Anmeldeerfahrung auf Organisations- und Anwendungsebene und vielem mehr.
Unterstützung für Benutzerimitation über Token Exchange hinzugefügt:
POST /subject-tokens, um ein subject_token für den Token-Austausch anzufordern.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.
custom_dataEin 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.
PATCH /api/applications/{applicationId}/custom-data, um das custom_data-Feld einer Anwendung zu aktualisieren.PATCH /api/applications/{applicationId}, um das Überschreiben des custom_data-Felds zu ermöglichen.Ein neuer benutzerdefinierter JSON-Editor für das custom_data im Anwendungsdetails-Bereich (außer bei geschützten Apps) hinzugefügt.
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.
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.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.
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.
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.
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:
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.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.
merge auf replace im Endpunkt PATCH /api/applications/{applicationId}.partial auf full im Endpunkt PATCH /api/applications/{applicationId}.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 diePATCH-Methode verwenden, um die jsonb-Feldeinstellungen derApplicationzu aktualisieren, sollten sich dieser Änderung bewusst sein. DiePATCH-Methode ersetzt nun das gesamte jsonb-Feld durch die neuen Eingabedaten. Jegliche partielle Eingabedaten in den betroffenen Feldern werden abgelehnt.
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.
Argon2d und Argon2id. Nutzer, die diese Algorithmen verwenden, werden bei erfolgreicher Anmeldung auf Argon2i migriert.@logto/experience wurde mit dem was in der README.md angegeben ist, synchronisiert.