Zum Hauptinhalt springen

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:

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​

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. Für Support-, Admin- oder Agenten-Szenarien, in denen ein Benutzer vorübergehend als ein anderer Benutzer agiert, verwende Benutzermimikry.

Wie es funktioniert​

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​

  1. Erstelle API-Ressourcen für die beteiligten Dienste. Siehe Globale API-Ressourcen schützen.
  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.
Voraussetzungen:

Bevor du den Token-Austausch-Grant verwenden kannst, musst du ihn für deine Anwendung aktivieren:

  1. Gehe zu Konsole > Anwendungen und wähle deine Anwendung aus.
  2. Suche in den Anwendungseinstellungen den Abschnitt „Token-Austausch“.
  3. Aktiviere den Schalter „Token-Austausch erlauben“.

Der Token-Austausch ist aus Sicherheitsgründen standardmäßig deaktiviert. Wenn du ihn nicht aktivierst, erhältst du einen Fehler „Token-Austausch ist für diese Anwendung nicht erlaubt“.

Zugangstoken für die nachgelagerte API anfordern​

Wenn API A API B aufrufen muss, stelle eine Token Exchange Anfrage an den Token-Endpunkt von Logto.

Für traditionelle Webanwendungen oder Maschine-zu-Maschine-Anwendungen mit App-Secret füge die Zugangsdaten in den Authorization Header ein:

POST /oidc/token HTTP/1.1
Host: tenant.logto.app
Content-Type: application/x-www-form-urlencoded
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:

{
  "access_token": "eyJhbGci...<truncated>",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "read:orders"
}

Nach dem Dekodieren enthält das Zugangstoken Ansprüche wie:

{
  "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:

GET /orders HTTP/1.1
Host: api-b.example.com
Authorization: Bearer <exchanged_access_token>

Token in API B validieren​

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 für Implementierungshinweise.

Globale API-Ressourcen schützen Zugangstokens in API validieren Benutzermimikry