chore: sync heading ids

logto-io · Dec 18, 2024 · ec5c27c · ec5c27c
1 parent acc7f1a
commit ec5c27c
Show file tree

Hide file tree

Showing 1,540 changed files with 9,388 additions and 9,254 deletions.
diff --git a/...e/docusaurus-plugin-content-docs/current/authorization/api-resources/README.mdx b/...e/docusaurus-plugin-content-docs/current/authorization/api-resources/README.mdx
@@ -6,7 +6,7 @@ sidebar_position: 1
 
 API-Ressourcen, auch bekannt als [Ressourcenindikatoren](https://www.rfc-editor.org/rfc/rfc8707.html), geben die Zielservices oder -ressourcen an, die angefordert werden sollen, in der Regel eine URI-Formatvariable, die die Identität der Ressource darstellt. Dies ist ein Schlüsselkonzept im Logto-Autorisierungssystem, da es den Endpunkt definiert, den die Autorisierungsrichtlinie schützen soll.
 
-## Ressourcenindikator
+## Ressourcenindikator \{#resource-indicator}
 
 - Ein Ressourcenwert gibt den Zielservice oder die Ressource an, auf die zugegriffen werden soll.
 - Sein Wert **MUSS** eine absolute URI sein.
@@ -24,7 +24,7 @@ https://tenantId.logto.app/api
 
 Standardmäßig ist diese API-Ressource in deinem Logto-Dienst vorregistriert. Alle [Management API](https://openapi.logto.io/) unter dieser URI sind durch Logto geschützt.
 
-## Logto API-Ressourcen-Schema
+## Logto API-Ressourcen-Schema \{#logto-api-resource-schema}
 
 | **Eigenschaftsname**                                                                                                                                                                                                                     | **Eigenschaftsbeschreibung**                                                                                                           | **Erforderlich** |
 | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ---------------- |
@@ -41,7 +41,7 @@ Anfragen mit einem abgelaufenen `Zugangstoken` sollten eingeschränkt werden. Di
 
 :::
 
-## Standard-API
+## Standard-API \{#default-api}
 
 :::note
 
@@ -61,7 +61,7 @@ Um dieses Problem zu lösen, kannst du eine API-Ressource als standardmäßige R
 
 Durch die Festlegung einer Standard-API-Ressource kannst du eine reibungslose Integration mit Apps sicherstellen, die keine RFC 8707-Unterstützung bieten, während du die entsprechenden Zugangskontrollen beibehältst.
 
-## Registriere die API-Ressourcen in Logto
+## Registriere die API-Ressourcen in Logto \{#register-the-api-resources-in-logto}
 
 Um ein zielgruppenbeschränktes `Zugangstoken` von Logto zu erhalten, registriere zuerst deine Backend-APIs, um die zielgruppenbeschränkten Zugangstokens von Logto zu aktivieren. Wenn eine Autorisierungsanfrage eingeht, wird Logto die registrierten API-Ressourcen identifizieren und den Zugang entsprechend gewähren.
 
@@ -74,7 +74,7 @@ Klicke auf die Schaltfläche **API-Ressource erstellen** und folge dem interakti
 
 Die neue API wird in der Liste angezeigt, sobald sie erstellt wurde. Du kannst sie auf der API-Detailseite verwalten oder löschen, indem du auf die Entität klickst.
 
-## Verwandte Ressourcen
+## Verwandte Ressourcen \{#related-resources}
 
 <Url href="https://blog.logto.io/opaque-token-vs-jwt">Opaker Token vs JWT</Url>
 

diff --git a/...saurus-plugin-content-docs/current/authorization/api-resources/node-express.mdx b/...saurus-plugin-content-docs/current/authorization/api-resources/node-express.mdx
@@ -4,7 +4,7 @@ sidebar_position: 3
 
 # Anleitung: Node (Express)
 
-## Schritt 1: Extrahiere das Bearer Token aus dem Anfrage-Header
+## Schritt 1: Extrahiere das Bearer Token aus dem Anfrage-Header \{#step-1-extract-the-bearer-token-from-request-header}
 
 Eine autorisierte Anfrage sollte einen `Authorization`-Header mit `Bearer <access_token>` als Inhalt enthalten. Extrahiere das Autorisierungstoken aus dem Anfrage-Header:
 
@@ -28,17 +28,17 @@ const extractBearerTokenFromHeaders = ({ authorization }: IncomingHttpHeaders) =
 };
 ```
 
-## Schritt 2: Token-Validierung
+## Schritt 2: Token-Validierung \{#step-2-token-validation}
 
 Zur Demonstration verwenden wir das [jose](https://github.com/panva/jose)-Paket, um die Signatur, den Ablaufstatus und die erforderlichen Ansprüche des Tokens zu validieren.
 
-### Installiere `jose` als Abhängigkeit
+### Installiere `jose` als Abhängigkeit \{#install-jose-as-your-dependency}
 
 ```bash
 npm i jose --save
 ```
 
-### Abrufen der OIDC-Konfigurationen von Logto
+### Abrufen der OIDC-Konfigurationen von Logto \{#retrieve-logtos-oidc-configurations}
 
 Du benötigst einen JWK-öffentlichen Schlüssel und den Token-Aussteller, um die Signatur und die Quelle des empfangenen JWS-Tokens zu überprüfen. Alle aktuellen öffentlichen Logto-Autorisierungskonfigurationen findest du unter `https://<your-logto-domain>/oidc/.well-known/openid-configuration`.
 
@@ -51,7 +51,7 @@ z.B. Rufe `https://tenant-id.logto.app/oidc/.well-known/openid-configuration` au
 }
 ```
 
-### Auth-Middleware hinzufügen
+### Auth-Middleware hinzufügen \{#add-auth-middleware}
 
 Die `jwtVerify`-Methode von Jose kann dir helfen, das JWS-Format des Tokens, die Tokensignatur, den Aussteller, die Zielgruppe und den Ablaufstatus zu überprüfen. Eine Ausnahme wird ausgelöst, wenn die Validierung fehlschlägt.
 
@@ -93,7 +93,7 @@ export const verifyAuthFromRequest = async (req, res, next) => {
 };
 ```
 
-## Middleware auf deine API anwenden
+## Middleware auf deine API anwenden \{#apply-middleware-to-your-api}
 
 ```tsx
 import { verifyAuthFromRequest } from '/middleware/auth-middleware.ts';
@@ -103,7 +103,7 @@ app.get('/user/:id', verifyAuthFromRequest, (req, res, next) => {
 });
 ```
 
-## Verwandte Ressourcen
+## Verwandte Ressourcen \{#related-resources}
 
 <Url href="https://blog.logto.io/protect-your-express-js-api">
   Schütze deine Express.js API mit JWT und Logto

diff --git a/...us-plugin-content-docs/current/authorization/api-resources/protect-your-api.mdx b/...us-plugin-content-docs/current/authorization/api-resources/protect-your-api.mdx
@@ -42,7 +42,7 @@ In diesem Tutorial
 
 Du solltest diese durch deine tatsächlichen Endpunkte ersetzen, wenn du implementierst.
 
-## Authentifizierungsanfrage
+## Authentifizierungsanfrage \{#authentication-request}
 
 Stelle eine Liste von Ressourcenindikator-Parametern in einer [Authentifizierungsanfrage](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest) bereit. Dies wird alle geschützten Ressourcen anzeigen, die der Benutzer möglicherweise anfordert.
 
@@ -67,7 +67,7 @@ const config: LogtoConfig = {
 };
 ```
 
-## Token-Anfrage
+## Token-Anfrage \{#token-request}
 
 Wenn der Ressourcenparameter bei einer [Token-Anfrage](https://openid.net/specs/openid-connect-core-1_0.html#TokenRequest) zusammen mit dem oben gewährten `authorization_code` vorhanden ist, wird die Ziel-API-Ressourcenzielgruppe des Zugangstokens spezifiziert.
 
@@ -96,7 +96,7 @@ Der Payload des accessToken wird enthalten:
 }
 ```
 
-## Anfrage an die API-Ressource
+## Anfrage an die API-Ressource \{#request-to-the-api-resource}
 
 Der Client-Benutzer sendet eine Anfrage an die API-Ressource, indem er das gegebene `access_token` im Authorization-Header präsentiert.
 
@@ -107,11 +107,11 @@ Authorization: Bearer eyJhbGciOiJIUz...
 
 Logto folgt dem standardmäßigen tokenbasierten Autorisierungsprotokoll, um deine API-Ressourcen zu schützen. Um mehr über OAuth 2.0 zu erfahren, siehe bitte das [offizielle Dokument](https://datatracker.ietf.org/doc/html/rfc6749#section-1.3.1) von OAuth 2.0.
 
-## Autorisierungstoken für API-Anfragen validieren
+## Autorisierungstoken für API-Anfragen validieren \{#validate-authorization-tokens-for-api-requests}
 
 Logto stellt ein standardmäßiges [JWT](https://datatracker.ietf.org/doc/html/rfc7519)-Format Autorisierungstoken für jede autorisierte API-Anfrage aus. Das Token ist verschlüsselt und als [JWS](https://datatracker.ietf.org/doc/html/rfc7515)-Token signiert.
 
-#### Verständnis des JWS-Tokens
+#### Verständnis des JWS-Tokens \{#understanding-jws-token}
 
 Ein kodiertes [JWS](https://datatracker.ietf.org/doc/html/rfc7515)-Token wird aus drei Teilen konstruiert:
 
@@ -138,7 +138,7 @@ Für die Entwicklung, um ein JWT-Token visuell zu inspizieren, könntest du ein
 
 :::
 
-#### Das Autorisierungstoken validieren
+#### Das Autorisierungstoken validieren \{#validate-the-authorization-token}
 
 1. [Ein JWT validieren](https://datatracker.ietf.org/doc/html/rfc7519#section-7.2)
 2. [Die JWS-Signatur validieren](https://datatracker.ietf.org/doc/html/rfc7515#section-5.2)
@@ -153,6 +153,6 @@ Es gibt verschiedene Open-Source-Bibliotheken und -Pakete, die dir helfen könne
 - [Spring Boot](/authorization/api-resources/spring-boot)
 - [Python](/authorization/api-resources/python)
 
-## Referenz
+## Referenz \{#reference}
 
 Logto verwendet das codebasierte OAuth 2.0 Autorisierungsprotokoll, um deine API-Anfrage sicher zu machen. Wenn du an der dahinterstehenden Strategie interessiert bist, sieh dir die [Spezifikation](https://datatracker.ietf.org/doc/html/rfc6749#section-1.3.1) von OAuth 2.0 für weitere Details an.
diff --git a/...e/docusaurus-plugin-content-docs/current/authorization/api-resources/python.mdx b/...e/docusaurus-plugin-content-docs/current/authorization/api-resources/python.mdx
@@ -4,7 +4,7 @@ sidebar_position: 2
 
 # Leitfaden: Python
 
-## Schritt 1: Extrahiere das Bearer-Token aus dem Anfrage-Header
+## Schritt 1: Extrahiere das Bearer-Token aus dem Anfrage-Header \{#step-1-extract-the-bearer-token-from-request-header}
 
 Eine autorisierte Anfrage sollte einen `Authorization`-Header mit `Bearer <access_token>` als Inhalt enthalten. Extrahiere das Autorisierungstoken aus dem Anfrage-Header:
 
@@ -28,11 +28,11 @@ def get_auth_token():
   return contents[1]
 ```
 
-## Schritt 2: Token-Validierung
+## Schritt 2: Token-Validierung \{#step-2-token-validation}
 
 Zur Demonstration verwenden wir die Flask-App und das [jose](https://github.com/mpdavis/python-jose)-Paket, um den require_auth-Decorator zu erstellen, der die Signatur, den Ablaufstatus und die erforderlichen Ansprüche des Tokens validiert.
 
-### Installiere `python-jose` als Abhängigkeit
+### Installiere `python-jose` als Abhängigkeit \{#install-python-jose-as-your-dependency}
 
 Wähle die Kryptografie, die du in Logto verwendest. (`ecdsa` standardmäßig)
 
@@ -41,7 +41,7 @@ pip install python-jose[ecdsa]
 
 ```
 
-### Abrufen der OIDC-Konfigurationen von Logto
+### Abrufen der OIDC-Konfigurationen von Logto \{#retrieve-logtos-oidc-configurations}
 
 Du benötigst einen JWK-öffentlichen Schlüssel und den Token-Aussteller, um die Signatur und Quelle des empfangenen JWS-Tokens zu überprüfen. Alle aktuellen öffentlichen Logto-Autorisierungskonfigurationen findest du unter `https://<your-logto-domain>/oidc/.well-known/openid-configuration`.
 
@@ -54,7 +54,7 @@ z.B. Rufe `https://tenant-id.logto.app/oidc/.well-known/openid-configuration` au
 }
 ```
 
-### Erstelle den Autorisierungsvalidierungs-Decorator
+### Erstelle den Autorisierungsvalidierungs-Decorator \{#create-the-authorization-validation-decorator}
 
 :::warning
 
@@ -109,7 +109,7 @@ def requires_auth(f):
   return decorated
 ```
 
-## Wende den Decorator auf deine API an
+## Wende den Decorator auf deine API an \{#apply-decorator-to-your-api}
 
 ```python
 from flask import Flask

diff --git a/...usaurus-plugin-content-docs/current/authorization/api-resources/spring-boot.mdx b/...usaurus-plugin-content-docs/current/authorization/api-resources/spring-boot.mdx
@@ -11,7 +11,7 @@ In diesem Tutorial gehen wir davon aus, dass der Client ein gültiges `access_to
 
 Deine Webanwendung kann serverseitig mit dem Spring Boot Framework ausgeführt werden. Derzeit musst du Logto manuell in Spring Boot integrieren. Dieser Artikel führt dich Schritt für Schritt durch den Prozess. Wir verwenden Gradle, Java und Spring Security als Beispiel.
 
-## Ein Spring Boot-Projekt starten
+## Ein Spring Boot-Projekt starten \{#start-a-spring-boot-project}
 
 Mit [Spring Initializr](https://start.spring.io/) kannst du schnell ein Spring Boot-Projekt starten. Verwende die folgenden Optionen:
 
@@ -21,7 +21,7 @@ Mit [Spring Initializr](https://start.spring.io/) kannst du schnell ein Spring B
 
 Generiere und öffne das Projekt.
 
-## Abhängigkeiten hinzufügen
+## Abhängigkeiten hinzufügen \{#add-dependencies}
 
 Füge die Abhängigkeiten zu deiner Gradle-Projekt-Build-Datei `build.gradle` hinzu:
 
@@ -40,7 +40,7 @@ Siehe [Spring Security OAuth 2.0 Resource Server](https://docs.spring.io/spring-
 
 :::
 
-## Aussteller und JWKS-URI abrufen
+## Aussteller und JWKS-URI abrufen \{#get-issuer-and-jwks-uri}
 
 Alle Tokens werden vom [Aussteller (Issuer)](https://openid.net/specs/openid-connect-core-1_0.html#IssuerIdentifier) ausgestellt und mit [JWK](https://datatracker.ietf.org/doc/html/rfc7517) signiert (siehe [JWS](https://datatracker.ietf.org/doc/html/rfc7515) für weitere Details).
 
@@ -59,7 +59,7 @@ Alle neuesten Logto Authorization Server Konfigurationen findest du unter `https
 }
 ```
 
-## Anwendung konfigurieren
+## Anwendung konfigurieren \{#configure-application}
 
 Verwende eine `application.yml`-Datei (anstelle der Standard-`application.properties`), um den Serverport, die Zielgruppe und den OAuth2-Ressourcenserver zu konfigurieren.
 
@@ -84,7 +84,7 @@ spring:
 - `spring.security.oauth2.resourceserver.jwt.issuer-uri`: Der `iss` Anspruchswert und die Aussteller-URI im von Logto ausgestellten JWT. Fülle den `issuer`-Wert aus dem vorherigen Abschnitt aus.
 - `spring.security.oauth2.resourceserver.jwt.jwk-set-uri`: Spring Security verwendet diese URI, um die öffentlichen Schlüssel des Autorisierungsservers zu erhalten, um JWT-Signaturen zu validieren. Fülle den `jwks_uri`-Wert aus dem vorherigen Abschnitt aus.
 
-## Zielgruppen-Validator bereitstellen
+## Zielgruppen-Validator bereitstellen \{#provide-audience-validator}
 
 Stelle deine eigene `AudienceValidator`-Klasse bereit, die das `OAuth2TokenValidator`-Interface implementiert, um zu validieren, ob die erforderliche Zielgruppe im JWT vorhanden ist.
 
@@ -122,7 +122,7 @@ public class AudienceValidator implements OAuth2TokenValidator<Jwt> {
 }
 ```
 
-## Spring Security konfigurieren
+## Spring Security konfigurieren \{#configure-spring-security}
 
 Spring Security macht es einfach, deine Anwendung als Ressourcenserver zu konfigurieren und das JWT aus dem Bearer Token im Anforderungsheader zu validieren.
 
@@ -204,7 +204,7 @@ public class SecurityConfiguration {
 }
 ```
 
-## APIs hinzufügen
+## APIs hinzufügen \{#add-apis}
 
 Füge einen Controller hinzu, um die geschützten und öffentlichen APIs bereitzustellen:
 
@@ -234,7 +234,7 @@ public class ProtectedController {
 
 ```
 
-## Geschützte API aufrufen
+## Geschützte API aufrufen \{#access-protected-api}
 
 Baue und führe deine Spring Boot-Webanwendung aus, z. B. führe die `bootRun` Gradle-Aufgabe aus.
 

diff --git a/...urus-plugin-content-docs/current/authorization/organization-template/README.mdx b/...urus-plugin-content-docs/current/authorization/organization-template/README.mdx
@@ -23,7 +23,7 @@ Um es richtig einzurichten, musst du verstehen, [wie Organisationen funktioniere
 
 # Organisationstemplate verstehen
 
-### Organisationsberechtigung
+### Organisationsberechtigung \{#organization-permission}
 
 Organisationsberechtigung bezieht sich auf die Autorisierung, eine Aktion im Kontext einer Organisation auszuführen. Eine Organisationsberechtigung sollte als aussagekräftiger String dargestellt werden, der auch als Name und eindeutiger Identifikator dient.
 
@@ -33,7 +33,7 @@ Zum Beispiel `edit:resource`.
 
 Organisationsberechtigungen sind ohne den Kontext einer Organisation nicht aussagekräftig. Zum Beispiel ist `edit:resource` im Kontext der Organisation `org1` anders als `edit:resource` im Kontext der Organisation `org2`, da sie auf unterschiedliche Ressourcen verweisen (`org1` vs. `org2`).
 
-### Organisationsrolle
+### Organisationsrolle \{#organization-role}
 
 Eine Organisationsrolle ist eine Sammlung von [Organisationsberechtigungen](#organization-permission) oder [API-Berechtigungen](/authorization/role-based-access-control/configure-permissions) (API-Berechtigungen, die direkt in <CloudLink to="/api-resources">API-Ressourcen in der Logto-Konsole</CloudLink> definiert sind), die Benutzern zugewiesen werden können.
 
@@ -51,7 +51,7 @@ Ja, du kannst [API-Berechtigungen](/authorization/role-based-access-control#perm
 
 :::
 
-## Organisationstemplate
+## Organisationstemplate \{#organization-template}
 
 Organisationstemplate bezieht sich auf eine Sammlung von Organisationsberechtigungen und Rollen, die für jede [Organisation](/organizations) gelten. Es wird als rollenbasierte Zugangskontrolle auf Organisationsebene betrachtet.
 
@@ -82,7 +82,7 @@ Du kannst sowohl [Organisationstemplate](/authorization/organization-template) a
 
 :::
 
-## Verwandte Ressourcen
+## Verwandte Ressourcen \{#related-resources}
 
 <Url href="https://blog.logto.io/case-study-multi-tenancy">
   Fallstudie: Multi-Tenancy mit Logto-Organisationen aufbauen