Freigeben über


Aufrufen einer API über eine andere API

Wie stellen Sie als Entwickler sicher, dass Zero Trust verwendet wird, wenn Sie über eine API verfügen, die eine andere API aufrufen muss? In diesem Artikel erfahren Sie, wie Sie Ihre Anwendung sicher entwickeln, wenn sie im Auftrag eines Benutzers arbeitet.

Wenn ein Benutzer die Benutzeroberfläche einer App steuert, verwendet die App möglicherweise eine delegierte Berechtigung, damit die API weiß, in welchem Auftrag die App arbeitet. Er prüft die Ansprüche des Betreffs (Sub) oder der Objekt-ID (oid) und der Mandanten-ID (tid) im Zugriffstoken, das die App beim Aufrufen der API bereitstellt. Die API würde sich nicht auf die nicht vertrauenswürdige App verlassen, bei der es sich nur um einen Aufruf handelt, der von einer beliebigen Stelle im Netzwerk stammt. Stattdessen würde das Token überprüft, um sicherzustellen, dass die API nur im Auftrag des App-Benutzers funktioniert, den Microsoft Entra ID überprüft hat.

Wenn eine API (die Original-API) eine andere aufruft, ist es wichtig, dass die API, die wir aufrufen (die Downstream-API) dem oben beschriebenen Überprüfungsprozess folgt. Die Downstream-API kann sich nicht auf eine nicht vertrauenswürdige Netzwerkquelle verlassen. Sie muss die Benutzeridentität von einem ordnungsgemäß überprüften Zugriffstoken abrufen.

Wenn die Downstream-API nicht dem richtigen Überprüfungsprozess folgt, muss die Downstream-API die Original-API verwenden, um die Identität des Benutzers auf eine andere Weise bereitzustellen. Die Downstream-API verwendet möglicherweise fälschlicherweise eine Anwendungsberechtigung zum Ausführen des Vorgangs. Dann würde die ursprüngliche API zur alleinigen Autorität werden, über die Benutzer die Ergebnisse für die Downstream-API erreichen könnten. Die Original-API kann es einem Benutzer absichtlich (oder unbeabsichtigt) ermöglichen, eine Aufgabe auszuführen, die der Benutzer sonst nicht ausführen konnte. Beispielsweise könnte ein Benutzer die Details eines anderen Benutzers ändern oder Dokumente lesen und aktualisieren, für die der Benutzer nicht über die Berechtigung zum Zugriff verfügt. Unsachgemäße Überprüfung kann zu schwerwiegenden Sicherheitsproblemen führen.

Um eine bessere Sicherheit zu gewährleisten, erwirbt die Original-API ein Zugriffstoken mit delegierter Berechtigung und stellt es der Downstream-API zur Verfügung, wenn die ursprüngliche API den Aufruf vorgibt. Sehen wir uns an, wie dies funktioniert.

Client App erwirbt ein Zugriffstoken zum Aufrufen der Original-API

Das folgende Diagramm zeigt die Client-App und die Original-API.

Das Diagramm zeigt die Client-App mit ID und Zugriffstoken und die Original-API, die eine Autorisierung erfordert.

Die Clientanwendung hat ein Zugriffstoken für delegierte Berechtigungen (gekennzeichnet durch das Fünfeck mit der Bezeichnung „A“) für die Original-API erworben. Das delegierte Berechtigungszugriffstoken ermöglicht es, im Auftrag des Benutzers die Original-API aufzurufen, die eine Autorisierung erfordert.

Client-App erteilt Zugriffstoken für die Original-API

Die folgende Animation zeigt die Client-App, die das Zugriffstoken der Original-API übergibt. Die Original-API überprüft und inspiziert das Zugriffstoken, um die Identität des Benutzers der Client-App zu ermitteln.

Das animierte Diagramm zeigt die Client-App, die der Original-API, die eine Autorisierung erfordert, ein Zugriffstoken übergibt.

Die Original-API führt Token-Überprüfung und -Erzwingung durch

Die nächste Animation zeigt, dass die Original-API Token-Überprüfung und -Erzwingung durchführt, nachdem die Client-App das Zugriffstoken der Original-API erteilt hat. Wenn alles gut ist, fährt die API fort und erfüllt die Anforderung für die Client-App.

Animiertes Diagramm zeigt Client-App mit ID-Token auf der linken Seite, die das Zugriffstoken der ursprünglichen API auf der rechten Seite angibt.

Die Original-API kann kein Zugriffstoken verwenden, um die Downstream-API aufzurufen

Die folgende Animation zeigt, dass die Original-API jetzt eine Downstream-API aufrufen möchte. Die Original-API kann das Zugriffstoken jedoch nicht verwenden, um die Downstream-API aufzurufen.

Animiertes Diagramm zeigt Client-App, die Zugriffstoken für die ursprüngliche API gibt. Die erforderliche Autorisierung verhindert, dass die Original API Token für die Downstream API gibt.

Die Original-API geht zurück zur Microsoft Entra-ID

In der folgenden Animation muss die Original-API zu Microsoft Entra ID zurückkehren. Sie benötigt ein Zugriffstoken, um die Downstream-API im Namen des Benutzers aufzurufen.

Animiertes Diagramm zeigt Client-App, die Zugriffstoken für die Original API gibt, die eine Überprüfung von Microsoft Entra-ID benötigt, um die Downstream API aufzurufen.

Die nächste Animation zeigt die Original-API, die das Token bereitstellt, das die Original-API von der Client-App und den Client-Anmeldeinformationen der Original-API erhalten hat.

Animiertes Diagramm zeigt Client-App, die Zugriffstoken für die originale API gibt, die eine Überprüfung von Microsoft Entra-ID empfängt, um die Downstream API aufzurufen.

Microsoft Entra ID prüft auf Dinge wie Einwilligung oder die Durchsetzung von bedingtem Zugriff. Möglicherweise müssen Sie zu Ihrem aufrufenden Client zurückkehren und einen Grund angeben, warum das Token nicht abgerufen werden kann. In der Regel verwenden Sie einen Anspruchsabfrageprozess, um zur aufrufenden Anwendung zurückzukehren, die Informationen dazu enthält, dass die Zustimmung nicht empfangen wird (z. B. im Zusammenhang mit Richtlinien für den bedingten Zugriff).

Microsoft Entra ID führt Überprüfungen durch

In der folgenden Animation führt Microsoft Entra ID die Überprüfungen durch. Wenn alles in Ordnung ist, gibt Microsoft Entra ID ein Zugriffstoken für die Original-API aus, um die Downstream-API im Namen des Benutzers aufzurufen.

Animiertes Diagramm zeigt originale API, die Zugriffstoken für nachgeschaltete API nach der Überprüfung mit der Microsoft Entra-ID angibt.

Die Original-API verfügt über einen Benutzerkontext mit dem „On-Behalf-Of-Flow“.

Die folgende Animation veranschaulicht den Prozess On-Behalf-Of-Fluss (OBO), der es einer API ermöglicht, weiterhin den Benutzerkontext aufzuweisen, während sie die Downstream-API aufruft.

Animiertes Diagramm zeigt die Original API, die Zugriffstoken für Downstream API gibt.

Die Original-API ruft die Downstream-API auf

In der nächsten Animation rufen wir die Downstream-API auf. Das Token, das die Downstream-API empfängt, weist den richtigen Zielgruppenanspruch (aud) auf, der die Downstream-API angibt.

Animiertes Diagramm zeigt die Downstream API, die Zugriffstoken aus der Original API überprüft.

Das Token enthält die Bereiche für die erteilte Einwilligung und die Benutzeridentität der Original-App. Die Downstream-API kann effektive Berechtigungen ordnungsgemäß implementieren, um sicherzustellen, dass der identifizierte Benutzer über die Berechtigung zum Ausführen der angeforderten Aufgabe verfügt. Sie könnten den On-Behalf-Of-Fluss verwenden, um Token für eine API abzurufen, um eine andere API aufzurufen und sicherzustellen, dass der Benutzerkontext an alle Downstream-APIs übergeben wird.

Beste Option: Die Original-API führt einen „On-Behalf-Of-Flow“ aus.

Diese letzte Animation zeigt, dass die beste Option für die Original-API zum Ausführen des Flusses „On-Behalf-Of-Flow“ (OBO) ist. Wenn die Downstream-API das richtige Token empfängt, kann sie richtig reagieren.

Animiertes Diagramm zeigt nachgeschaltete API, die Zugriffstoken von der Ursprünglichen API empfängt.

Wenn eine API im Namen eines Benutzers fungiert und eine andere API aufrufen muss, muss die API OBO verwenden, um ein delegiertes Berechtigungszugriffstoken abzurufen, um die Downstream-API im Namen des Benutzers aufzurufen. APIs sollten niemals Anwendungsberechtigungen verwenden, um Downstream-APIs aufzurufen, wenn die API im Namen eines Benutzers fungiert.

Nächste Schritte