## 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](https://docs.logto.io/docs/recipes/impersonation/) 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: ```js import LogtoClient from '@logto/client'; const logtoClient = new LogtoClient(/* deine Konfiguration */); logtoClient.signIn({ redirectUri: 'https://deine-app.com/callback', extraParams: { organization_id: '', }, }); ``` Der Wert `` 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.