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.

Diagrammtitel: Die Client-App hat ein Zugriffstoken abgerufen, um die Original-API aufzurufen. Diagrammuntertitel: Die Clientanwendung verfügt über ein Zugriffstoken „A“, das es ermöglicht, im Namen des Benutzers zu arbeiten, der im Token identifiziert wurde, um die Original-API aufzurufen.

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 zwei Diagramme mit einem Bewegungsübergang zwischen dem ersten Diagramm und dem zweiten Diagramm. Erster Diagrammtitel: Die Client-App hat ein Zugriffstoken abgerufen, um die Original-API aufzurufen. Erster Diagrammuntertitel: Die Clientanwendung verfügt über ein Zugriffstoken „A“, das es ermöglicht, im Namen des Benutzers zu arbeiten, der im Token identifiziert wurde, um die Original-API aufzurufen. Zweiter Diagrammtitel: Die Client-App übergibt das Zugriffstoken an die Original-API.

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.

Das animierte Diagramm zeigt zwei Diagramme mit einem Bewegungsübergang zwischen dem ersten Diagramm und dem zweiten Diagramm. Erster Diagrammtitel: Die Client-App übergibt den Zugriffstoken an die Original-API. Zweiter Diagrammtitel: Die Original-API führt Token-Überprüfung und -Erzwingung durch. Wenn alles in Ordnung ist, fährt die API fort und bedient die Anforderung.

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.

Das animierte Diagramm zeigt zwei Diagramme mit einem Bewegungsübergang zwischen dem ersten Diagramm und dem zweiten Diagramm. Erster Diagrammtitel: Die Original-API möchte eine Downstream-API aufrufen. Zweiter Diagrammtitel: Die Original-API kann das Token nicht verwenden, um die Downstream-API aufzurufen.

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.

Das animierte Diagramm zeigt zwei Diagramme mit einem Bewegungsübergang zwischen dem ersten Diagramm und dem zweiten Diagramm. Erster Diagrammtitel: Die Original-API kann das Token nicht verwenden, um die Downstream-API aufzurufen. Zweiter Diagrammtitel: Die Original-API geht zurück zur Microsoft Entra ID. Zweiter Diagrammuntertitel: Benötigt ein Zugriffstoken, um die Downstream-API im Namen des Benutzers 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.

Das animierte Diagramm zeigt zwei Diagramme mit einem Bewegungsübergang zwischen dem ersten Diagramm und dem zweiten Diagramm. Erster Diagrammtitel: Die Original-API geht zurück zur Microsoft Entra ID. Erster Diagrammuntertitel: Benötigt ein Zugriffstoken, um die Downstream-API im Namen des Benutzers aufzurufen. Zweiter Diagrammtitel: Die Original-API geht zurück zur Microsoft Entra ID. Zweiter Diagrammuntertitel: Stellt das Token aus der Client-App und die Anmeldeinformationen für die Original-API bereit.

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.

Das animierte Diagramm zeigt zwei Diagramme mit einem Bewegungsübergang zwischen dem ersten Diagramm und dem zweiten Diagramm. Erster Diagrammtitel: Die Original-API geht zurück zur Microsoft Entra ID. Erster Diagrammuntertitel: Stellt das Token aus der Client-App und die Anmeldeinformationen für die Original-API bereit. Zweiter Diagrammtitel: Microsoft Entra ID überprüft bedingten Zugriff, Zustimmung usw. Zweiter Diagrammuntertitel: Die Original-API empfängt ein eigenes Zugriffstoken, um die Downstream-API im Namen des Benutzers aufzurufen, der sich bei der Client-App angemeldet hat.

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.

Das animierte Diagramm zeigt zwei Diagramme mit einem Bewegungsübergang zwischen dem ersten Diagramm und dem zweiten Diagramm. Erster Diagrammtitel: Der On-Behalf-Of-Flow-Prozess ermöglicht der Original-API, weiterhin über Benutzerkontext zu verfügen, wenn es die Downstream-API aufruft. Zweiter Diagrammtitel: Der On-Behalf-Of-Flow-Prozess ermöglicht der Original-API, weiterhin über Benutzerkontext zu verfügen, wenn es die Downstream-API aufruft.

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.

Das animierte Diagramm zeigt zwei Diagramme mit einem Bewegungsübergang zwischen dem ersten Diagramm und dem zweiten Diagramm. Erster Diagrammtitel: Der On-Behalf-Of-Flow-Prozess ermöglicht der Original-API, weiterhin über Benutzerkontext zu verfügen, wenn es die Downstream-API aufruft. Zweiter Diagrammtitel: Die Downstream-API wird aufgerufen. Zweiter Diagrammuntertitel: Das Token, das die Downstream-API empfängt, verfügt über ordnungsgemäße Ansprüche, um den Benutzer der Client-App zu identifizieren.

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.

Das animierte Diagramm zeigt zwei Diagramme mit einem Bewegungsübergang zwischen dem ersten Diagramm und dem zweiten Diagramm. Erster Diagrammtitel: Die Downstream-API wird aufgerufen. Erster Diagrammuntertitel: Das Token, das die Downstream-API empfängt, verfügt über ordnungsgemäße Ansprüche, um den Benutzer der Client-App zu identifizieren. Zweiter Diagrammtitel: Die beste Option besteht darin, dass die Original-API „im Auftrag des Ablaufs“ ausgeführt wird. Wenn die Downstream-API das richtige Token empfängt, kann sie richtig reagieren.

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

• Microsoft Identity Platform-Authentifizierungsabläufe und App-Szenarien beschreiben Authentifizierungsflüsse und Anwendungsszenarien, in denen sie verwendet werden.
• Der API-Schutz beschreibt bewährte Methoden zum Schutz Ihrer API durch Registrierung, Definieren von Berechtigungen und Einwilligung sowie das Durchsetzen der Zugriffskontrolle, um Ihre Zero Trust-Ziele zu erreichen.
• Ein Beispiel für API protected by Microsoft Identity Consent Framework hilft Ihnen, Strategien für die Anwendungsberechtigungen mit geringsten Berechtigungen für die beste Benutzererfahrung zu entwerfen.
• Anpassen von Token beschreibt die Informationen, die Sie in Microsoft Entra-Token empfangen können. Es wird erläutert, wie Token angepasst werden, um Flexibilität und Kontrolle zu verbessern, während gleichzeitig die Zero Trust-Sicherheit der Anwendung mit minimalen Berechtigungen erhöht wird.
• Im Lernmodul „Sichere benutzerdefinierte APIs mit Microsoft Identity“ wird erläutert, wie Sie eine Web-API mit Microsoft Identity sichern und von einer anderen Anwendung aufrufen.
• Bewährte Sicherheitsmethoden für Anwendungseigenschaften beschreibt die Umleitungs-URI, Zugriffstoken (verwendet für implizite Abläufe), Zertifikate und geheime Schlüssel, Anwendungs-ID-URI und Anwendungsbesitz.
• In den Microsoft Identity Platform-Authentifizierungsbibliotheken wird die Unterstützung der Microsoft-Authentifizierungsbibliothek für verschiedene Anwendungstypen beschrieben.