chore: update translations and generated content

i18n/de/docusaurus-plugin-content-docs/current/developers/README.mdx

@@ -39,25 +39,34 @@ import Settings from '@site/docs/developers/assets/icons/gear.svg';
       type: 'link',
       label: 'Benutzermimikry (User impersonation)',
       href: '/developers/user-impersonation',
-      description: 'Erlaube autorisierten Benutzern, vorübergehend im Namen von Endbenutzern zu handeln – nützlich für Fehlerbehebung, Kundensupport und administrative Aufgaben.',
+      description: 'Erlaube autorisierten Benutzern, vorübergehend im Namen von Endbenutzern zu agieren – nützlich für Fehlerbehebung, Kundensupport und administrative Aufgaben.',
       customProps: {
         icon: <UserImpersonation />,
       }
     },
+    {
+      type: 'link',
+      label: 'Service-zu-Service-Delegation (Service-to-service delegation)',
+      href: '/developers/service-to-service-delegation',
+      description: 'Tausche ein Benutzer-Zugangstoken gegen ein nachgelagertes API-Zugangstoken aus, damit Backend-Dienste im Namen des aktuellen Benutzers agieren können.',
+      customProps: {
+        icon: <Key />,
+      }
+    },
   ]}
 />
 ```
 
-## Generisches für Entwickler \{#generics-for-developers}
+## Allgemeines für Entwickler \{#generics-for-developers}
 
 ```mdx-code-block
 <DocCardList
   items={[
     {
       type: 'link',
-      label: 'Signaturschlüssel (Signing keys)',
+      label: 'Signierschlüssel (Signing keys)',
       href: '/developers/signing-keys',
-      description: 'Stellt einen systemweiten Signaturschlüssel über den Passwort-Tresor bereit und macht den Authentifizierungsdienst sicherer.',
+      description: 'Stelle einen systemweiten Signierschlüssel über den Passwort-Tresor bereit, um den Authentifizierungsdienst sicherer zu machen.',
       customProps: {
         icon: <Key />,
       }
@@ -66,7 +75,7 @@ import Settings from '@site/docs/developers/assets/icons/gear.svg';
       type: 'link',
       label: 'Webhooks',
       href: '/developers/webhooks',
-      description: 'Webhooks unterstützen Echtzeit-Benachrichtigungen über Benutzerinformationen und Berechtigungsaktualisierungen per HTTP-Anfrage und erhöhen die Bequemlichkeit und Flexibilität der Logto-Integration.',
+      description: 'Webhooks unterstützen Echtzeit-Benachrichtigungen über Benutzerinformationen und Berechtigungsaktualisierungen per HTTP-Anfragen und erhöhen die Bequemlichkeit und Flexibilität der Logto-Integration.',
       customProps: {
         icon: <Webhook />,
       }
@@ -75,16 +84,16 @@ import Settings from '@site/docs/developers/assets/icons/gear.svg';
       type: 'link',
       label: 'Audit-Logs',
       href: '/developers/audit-logs',
-      description: 'Zeichnet benutzerbezogene Authentifizierungsaktivitäten auf, um das Debugging und die Analyse von Benutzeraktivitäten zu erleichtern.',
+      description: 'Zeichne Aktivitäten im Zusammenhang mit der Benutzer-Authentifizierung auf, um das Debugging und die Analyse von Benutzeraktivitäten zu erleichtern.',
       customProps: {
         icon: <AuditLog />,
       }
     },
     {
       type: 'link',
-      label: 'SDK-Konvention',
+      label: 'SDK-Konvention (SDK convention)',
       href: '/developers/',
-      description: 'Stellt die Datenstrukturen, Zwecke und Methoden im SDK vor, sodass Nutzer das SDK an verschiedene Geschäftsszenarien anpassen können.',
+      description: 'Stelle die Datenstrukturen, Zwecke und Methoden im SDK vor, damit Nutzer das SDK an verschiedene Geschäftsszenarien anpassen können.',
       customProps: {
         icon: <Settings />,
       }

i18n/de/docusaurus-plugin-content-docs/current/developers/audit-logs/README.mdx

@@ -1,5 +1,5 @@
 ---
-sidebar_position: 7
+sidebar_position: 8
 ---
 
 # Audit-Logs
@@ -11,7 +11,7 @@ Das Audit-Log von Logto ermöglicht es dir, Benutzeraktivitäten und Ereignisse
 Navigiere zu <CloudLink to="/audit-logs">Konsole > Audit-Logs</CloudLink>. Logto erfasst und organisiert Authentifizierungsereignisse in einer Tabelle. Es werden der Ereignisname, der Benutzer, die Anwendung und der Zeitstempel protokolliert. Du kannst die Ergebnisse eingrenzen, indem du nach Ereignisname und Anwendungsname filterst. Durch Klicken auf ein bestimmtes Ereignis erhältst du weitere Details.
 
 :::warning
-Audit-Logs enthalten nur Logs, die während des Authentifizierungsprozesses des Benutzers auftreten. Logs von Management API-Operationen werden nicht aufgezeichnet.
+Audit-Logs enthalten nur Protokolle, die während des Authentifizierungsprozesses des Benutzers auftreten. Protokolle von Management API-Operationen werden nicht aufgezeichnet.
 :::
 
 ## Benutzeraktivität auf Mandantenebene erfassen \{#capture-user-activity-at-the-tenant-level}
@@ -32,17 +32,17 @@ Durch die Aufzeichnung dieser Ereignisse können Organisationen potenzielle Sich
 
 ## Detaillierte Analyse auf Benutzerebene durchführen \{#perform-a-detailed-analysis-at-the-user-level}
 
-Administratoren können eine detaillierte Analyse der Logs durchführen, die mit bestimmten Benutzern verknüpft sind, um umfassende Untersuchungen zu bestimmten Ereignissen zu ermöglichen. Der Navigationsprozess ist einfach und benutzerfreundlich.
+Administratoren können eine detaillierte Analyse der Logs durchführen, die mit bestimmten Benutzern verknüpft sind, und so umfassende Untersuchungen zu bestimmten Ereignissen ermöglichen. Der Navigationsprozess ist einfach und benutzerfreundlich.
 
 Um benutzerspezifische Logs einzusehen, folge diesen Schritten:
 
 1. Navigiere zu <CloudLink to="/users">Konsole > Benutzerverwaltung</CloudLink>.
 2. Wähle den gewünschten Benutzer aus und gehe zur Detailseite.
-3. Klicke auf „Benutzer-Logs“. Die angezeigte Tabelle zeigt ausschließlich Log-Ereignisse, die von diesem bestimmten Benutzer durchgeführt und ausgelöst wurden.
+3. Klicke auf „Benutzer-Logs“. Die angezeigte Tabelle zeigt ausschließlich Log-Ereignisse an, die von diesem bestimmten Benutzer durchgeführt und ausgelöst wurden.
 
 <img
   src="/img/assets/audit-logs-related-to-specific-user.png"
-  alt="Audit-Logs, die sich auf einen bestimmten Benutzer beziehen"
+  alt="Audit-Logs im Zusammenhang mit einem bestimmten Benutzer"
 />
 
 ## FAQs \{#faqs}

i18n/de/docusaurus-plugin-content-docs/current/developers/sdk-conventions/README.mdx

@@ -2,18 +2,18 @@
 id: sdk-conventions
 title: Plattform-SDK-Konventionen
 sidebar_label: Plattform-SDK-Konventionen
-sidebar_position: 8
+sidebar_position: 9
 ---
 
 # Plattform-SDK-Konventionen
 
 Logto bietet einen sehr leistungsstarken und flexiblen Web-Authentifizierungsdienst.
 
-Im praktischen Einsatz der Logto-Dienste ist es für Entwickler oft notwendig, das Logto SDK in ihre eigenen Client-Anwendungen zu integrieren, um den Anmeldestatus der Benutzer, Berechtigungen und mehr zu verwalten.
+Im praktischen Einsatz der Logto-Dienste ist es für Entwickler oft aus Gründen der Bequemlichkeit notwendig, das Logto SDK in ihre eigenen Client-Anwendungen zu integrieren, um den Anmeldestatus der Benutzer, Berechtigungen und mehr zu verwalten.
 
 SDKs für alle von Logto unterstützten Programmiersprachen / Frameworks findest du [hier](/quick-starts).
 
-Falls du das gewünschte SDK nicht findest, gibt es hier eine Konvention, der du folgen kannst, um das SDK für deine gewünschte Programmiersprache zu implementieren und so die Nutzung der Logto-Dienste zu erleichtern.
+Falls du kein passendes SDK findest, gibt es hier eine Konvention, der du folgen kannst, um das SDK für deine gewünschte Programmiersprache zu implementieren und so die Nutzung der Logto-Dienste zu erleichtern.
 
 Diese Konvention besteht aus drei Hauptteilen:
 
@@ -24,13 +24,13 @@ Diese Konvention besteht aus drei Hauptteilen:
 ## Verwandte Ressourcen \{#related-resources}
 
 <Url href="https://blog.logto.io/implement-client-sdk#summary">
-  Implementierung eines einfachen clientseitigen OIDC SDK
+  Implementierung eines einfachen clientseitigen OIDC-SDKs
 </Url>
 
 <Url href="https://blog.logto.io/crafting-nodejs-sdk">
-  Entwicklung eines Node.js-basierten Framework-SDKs für Logto in wenigen Minuten
+  In wenigen Minuten ein Node.js-basiertes Framework-SDK für Logto erstellen
 </Url>
 
 <Url href="https://blog.logto.io/crafting-browser-sdk">
-  Entwicklung eines Web-SDKs für Logto in wenigen Minuten
+  In wenigen Minuten ein Web-SDK für Logto erstellen
 </Url>

i18n/de/docusaurus-plugin-content-docs/current/developers/service-to-service-delegation.mdx

@@ -0,0 +1,149 @@
+---
+id: service-to-service-delegation
+title: Service-to-service delegation
+sidebar_label: Service-to-service delegation
+sidebar_position: 5
+---
+
+import TokenExchangePrerequisites from './fragments/_token-exchange-prerequisites.mdx';
+
+# Service-to-service delegation
+
+In einigen API-Architekturen erhält ein Backend-Service eine Anfrage von einem angemeldeten Benutzer und muss einen weiteren Backend-Service aufrufen, während die Identität des Benutzers erhalten bleibt.
+
+Zum Beispiel:
+
+```text
+Benutzer -> API A -> API B
+```
+
+API B muss zwei Dinge wissen:
+
+1. Der Aufrufer ist ein vertrauenswürdiger Service, wie API A.
+2. Die Operation wird für den ursprünglichen Benutzer ausgeführt.
+
+Nutze das Token Exchange Grant von Logto, um das Zugangstoken des Benutzers gegen ein neues Zugangstoken auszutauschen, dessen Zielgruppe die nachgelagerte API-Ressource ist. Dies folgt dem OAuth 2.0 Token Exchange Muster und vermeidet es, das ursprüngliche Benutzertoken an nachgelagerte Dienste weiterzuleiten.
+
+## Wann dieser Ablauf verwendet werden sollte \{#when-to-use-this-flow}
+
+Verwende Service-to-service delegation, wenn:
+
+- API A ein Backend-Service ist, der sich sicher beim Token-Endpunkt von Logto authentifizieren kann.
+- API A ein von Logto ausgestelltes Benutzer-Zugangstoken erhält.
+- API A API B im Namen desselben Benutzers aufrufen muss.
+- API B ein Zugangstoken mit seiner eigenen API-Ressource als Zielgruppe validieren sollte.
+
+Verwende diesen Ablauf nicht für reinen Maschine-zu-Maschine-Zugriff ohne Benutzer. In diesem Fall verwende den [Client Credentials Flow](/quick-starts/m2m). Für Support-, Admin- oder Agenten-Szenarien, in denen ein Benutzer vorübergehend als ein anderer Benutzer agiert, verwende [Benutzermimikry](/developers/user-impersonation).
+
+## Wie es funktioniert \{#how-it-works}
+
+```mermaid
+sequenceDiagram
+    participant User as Benutzer
+    participant ApiA as API A
+    participant Logto as Logto Token-Endpunkt
+    participant ApiB as API B
+
+    Benutzer->>ApiA: Authorization: Bearer Benutzer-Zugangstoken
+    Note over ApiA: Validiert das Benutzertoken für API A
+
+    ApiA->>Logto: POST /oidc/token mit Token Exchange Grant
+    Note over ApiA,Logto: subject_token = Zugangstoken des Benutzers<br/>resource = API B Ressourcenindikator
+
+    Logto-->>ApiA: Zugangstoken für API B
+    ApiA->>ApiB: Authorization: Bearer ausgetauschtes Zugangstoken
+    Note over ApiB: Validiert Aussteller, Zielgruppe, Ablauf und Berechtigungen
+```
+
+Das ausgetauschte Zugangstoken repräsentiert den ursprünglichen Benutzer (`sub`) und ist an die nachgelagerte API-Ressource (`aud`) gebunden. Die nachgelagerte API kann auch den `client_id` Anspruch prüfen, um die Anwendung zu identifizieren, die den Austausch initiiert hat.
+
+## Voraussetzungen \{#prerequisites}
+
+1. Erstelle API-Ressourcen für die beteiligten Dienste. Siehe [Globale API-Ressourcen schützen](/authorization/global-api-resources).
+2. Konfiguriere die Berechtigungen von API B und weise sie Benutzern über Rollen oder Organisationsrollen zu.
+3. Verwende eine serverseitige Anwendung für API A, wie eine Maschine-zu-Maschine-App oder eine traditionelle Webanwendung, damit sie sich sicher mit einem App-Secret authentifizieren kann.
+4. Aktiviere Token Exchange für die Anwendung von API A.
+
+<TokenExchangePrerequisites />
+
+## Zugangstoken für die nachgelagerte API anfordern \{#request-an-access-token-for-the-downstream-api}
+
+Wenn API A API B aufrufen muss, stelle eine Token Exchange Anfrage an den [Token-Endpunkt](/integrate-logto/application-data-structure#token-endpoint) von Logto.
+
+Für traditionelle Webanwendungen oder Maschine-zu-Maschine-Anwendungen mit App-Secret füge die Zugangsdaten in den `Authorization` Header ein:
+
+```bash
+POST /oidc/token HTTP/1.1
+Host: tenant.logto.app
+Content-Type: application/x-www-form-urlencoded
+# highlight-next-line
+Authorization: Basic <base64(api-a-app-id:api-a-app-secret)>
+
+grant_type=urn:ietf:params:oauth:grant-type:token-exchange
+&subject_token=<user_access_token_received_by_api_a>
+&subject_token_type=urn:ietf:params:oauth:token-type:access_token
+&resource=https://api-b.example.com
+&scope=read:orders
+```
+
+Parameter:
+
+1. `grant_type`: Verwende `urn:ietf:params:oauth:grant-type:token-exchange`.
+2. `subject_token`: Das ursprüngliche, von Logto ausgestellte Benutzer-Zugangstoken, das von API A empfangen wurde.
+3. `subject_token_type`: Verwende `urn:ietf:params:oauth:token-type:access_token`.
+4. `resource`: Der Ressourcenindikator der API B.
+5. `scope`: Die nachgelagerten Berechtigungen, die API A für diesen delegierten Aufruf anfordert. Logto stellt nur die angeforderten Berechtigungen aus, die dem ursprünglichen Benutzer für diese Ressource gemäß den RBAC-Einstellungen zur Verfügung stehen.
+
+Logto gibt ein Zugangstoken für API B zurück:
+
+```json
+{
+  "access_token": "eyJhbGci...<truncated>",
+  "token_type": "Bearer",
+  "expires_in": 3600,
+  "scope": "read:orders"
+}
+```
+
+Nach dem Dekodieren enthält das Zugangstoken Ansprüche wie:
+
+```json
+{
+  "sub": "user_id",
+  "client_id": "api_a_app_id",
+  "iss": "https://tenant.logto.app/oidc",
+  "aud": "https://api-b.example.com",
+  "scope": "read:orders",
+  "exp": 1760000000
+}
+```
+
+Dann ruft API A API B mit dem ausgetauschten Token auf:
+
+```bash
+GET /orders HTTP/1.1
+Host: api-b.example.com
+Authorization: Bearer <exchanged_access_token>
+```
+
+## Token in API B validieren \{#validate-the-token-in-api-b}
+
+API B sollte das ausgetauschte Token wie jedes von Logto ausgestellte API-Ressourcen-Zugangstoken validieren:
+
+1. Überprüfe die Signatur mit den JWKs von Logto.
+2. Prüfe den Aussteller (`iss`).
+3. Prüfe, dass die Zielgruppe (`aud`) mit dem Ressourcenindikator von API B übereinstimmt.
+4. Prüfe das Ablaufdatum (`exp`).
+5. Prüfe die erforderlichen Berechtigungen.
+6. Verwende `sub` als ursprüngliche Benutzer-ID.
+7. Optional prüfe `client_id`, wenn nur bestimmte Upstream-Services delegierte Aufrufe durchführen dürfen.
+
+Siehe [Zugangstokens in API validieren](/authorization/validate-access-tokens) für Implementierungshinweise.
+
+## Verwandte Ressourcen \{#related-resources}
+
+<Url href="/authorization/global-api-resources">Globale API-Ressourcen schützen</Url>
+
+<Url href="/authorization/validate-access-tokens">Zugangstokens in API validieren</Url>
+
+<Url href="/developers/user-impersonation">Benutzermimikry</Url>