chore: update translations and generated content (#1323)

Co-authored-by: charIeszhao <12833674+charIeszhao@users.noreply.github.com>

Author: silverhand-bot

i18n/de/docusaurus-plugin-content-docs/current/concepts/opaque-token.mdx

@@ -2,13 +2,13 @@
 sidebar_position: 6
 ---
 
-# Opaker Token
+# Opaker Token (Opaque token)
 
-Während des Authentifizierungsprozesses, wenn keine Ressource angegeben ist, stellt Logto ein opakes Zugangstoken anstelle eines JWT aus. Das opake Token ist eine zufällige Zeichenfolge und viel kürzer als ein JWT:
+Während des Authentifizierungsprozesses gibt Logto, wenn keine Ressource angegeben ist, ein opakes Zugangstoken (Opaque token) anstelle eines JWT aus. Das opake Token ist eine zufällige Zeichenkette und deutlich kürzer als ein JWT:
 
 ```json
 {
-  "access_token": "some-random-string", // opakes Token
+  "access_token": "some-random-string", // opaker Token
   "expires_in": 3600,
   "id_token": "eyJhbGc...aBc", // JWT
   "scope": "openid profile email",
@@ -18,20 +18,20 @@ Während des Authentifizierungsprozesses, wenn keine Ressource angegeben ist, st
 
 Das opake Token kann verwendet werden, um den [userinfo endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) aufzurufen und auf geschützte Ressourcen zuzugreifen, die Authentifizierung erfordern. Da es sich nicht um ein JWT handelt, wie kann der Ressourcenserver es validieren?
 
-Logto bietet einen [Introspektions-Endpunkt](https://www.rfc-editor.org/rfc/rfc7662.html), der zur Validierung opaker Tokens verwendet werden kann. Standardmäßig ist der Introspektions-Endpunkt `/oidc/token/introspection` und akzeptiert `POST`-Anfragen. Der folgende Parameter ist erforderlich:
+Logto stellt einen [Introspektions-Endpunkt](https://www.rfc-editor.org/rfc/rfc7662.html) bereit, der zur Validierung opaker Tokens verwendet werden kann. Standardmäßig ist der Introspektions-Endpunkt `/oidc/token/introspection` und akzeptiert `POST`-Anfragen. Der folgende Parameter ist erforderlich:
 
 - `token`: das zu validierende opake Token
 
-Der Endpunkt erfordert auch eine Client-Authentifizierung. Du kannst eine der folgenden Methoden verwenden:
+Der Endpunkt erfordert außerdem eine Client-Authentifizierung. Du kannst eine der folgenden Methoden verwenden:
 
-- HTTP-Basic-Authentifizierung: Verwende den `Authorization`-Header mit dem Wert `Basic <base64-encoded-credentials>`. Die Anmeldedaten müssen die Client-ID und das Client-Geheimnis sein, getrennt durch einen Doppelpunkt (`:`) und base64-codiert.
-- HTTP-POST-Authentifizierung: Verwende die Parameter `client_id` und `client_secret`:
+- HTTP Basic-Authentifizierung: Verwende den `Authorization`-Header mit dem Wert `Basic <base64-encoded-credentials>`. Die Zugangsdaten müssen die Client-ID und das Client-Secret sein, getrennt durch einen Doppelpunkt (`:`) und base64-codiert.
+- HTTP POST-Authentifizierung: Verwende die Parameter `client_id` und `client_secret`:
   - `client_id`: die Client-ID der Anwendung, die das Token angefordert hat
-  - `client_secret`: das Client-Geheimnis der Anwendung, die das Token angefordert hat
+  - `client_secret`: das Client-Secret der Anwendung, die das Token angefordert hat
 
-Die Client-ID (App-ID) und das Client-Geheimnis (App-Geheimnis) können die App-Anmeldedaten von jeder "traditionellen Web"- oder "Maschine-zu-Maschine"-Anwendung in Logto sein. Der Introspektions-Endpunkt gibt einen Fehler zurück, wenn die Anmeldedaten ungültig sind.
+Die Client-ID (App-ID) und das Client-Secret (App-Secret) können die App-Zugangsdaten jeder "traditionellen Web"- oder "Maschine-zu-Maschine"-Anwendung in Logto sein. Der Introspektions-Endpunkt gibt einen Fehler zurück, wenn die Zugangsdaten ungültig sind.
 
-Der Introspektions-Endpunkt gibt ein JSON-Objekt mit den Ansprüchen des Tokens zurück:
+Der Introspektions-Endpunkt gibt ein JSON-Objekt mit den Ansprüchen (Claims) des Tokens zurück:
 
 ```json
 {
@@ -40,9 +40,9 @@ Der Introspektions-Endpunkt gibt ein JSON-Objekt mit den Ansprüchen des Tokens
 }
 ```
 
-Wenn das Token ungültig ist, wird das `active`-Feld `false` sein und das `sub`-Feld wird weggelassen.
+Wenn das Token ungültig ist, ist das Feld `active` auf `false` gesetzt und das Feld `sub` wird weggelassen.
 
-Hier ist ein nicht-normatives Beispiel für die Introspektionsanfrage:
+Hier ist ein nicht-normatives Beispiel für die Introspektions-Anfrage:
 
 ```bash
 curl --location \
@@ -54,3 +54,14 @@ curl --location \
 ```
 
 Denke daran, `[tenant-id]` durch deine Tenant-ID zu ersetzen.
+
+## Opaker Token und Organisationen \{#opaque-token-and-organizations}
+
+Opake Tokens können verwendet werden, um Organisationsmitgliedschaftsinformationen über den [userinfo endpoint](https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) abzurufen. Wenn du den `urn:logto:scope:organizations`-Scope anforderst, gibt der userinfo endpoint die organisationsbezogenen Ansprüche (Claims) des Benutzers zurück, wie z. B. `organizations` (Organisations-IDs) und `organization_data`.
+
+**Opake Tokens können jedoch nicht als Organisationstoken verwendet werden.** Organisationstokens werden immer im JWT-Format ausgegeben, weil:
+
+1. Organisationstokens enthalten organisationsspezifische Ansprüche (wie `organization_id` und bereichsspezifische Berechtigungen), die von Ressourcenservern validiert werden müssen.
+2. Das JWT-Format ermöglicht es Ressourcenservern, das Token zu überprüfen und den Organisationskontext ohne zusätzliche API-Aufrufe zu extrahieren.
+
+Um ein Organisationstoken zu erhalten, musst du den [Auffrischungstoken-Flow](/authorization/organization-permissions#refresh-token-flow) oder den [Client-Credentials-Flow](/authorization/organization-permissions#client-credentials-flow) mit Organisationsparametern verwenden.