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. Sie überprüft den Anspruch subject(sub) oder die Objekt-ID (oid) und die Mandanten-ID (tid) im Zugriffstoken, das die App beim Aufrufen der API bereitstellt. Die API verlässt sich nicht auf die nicht vertrauenswürdige App, bei der es sich nur um einen Aufruf handelt, der von irgendwo im Netzwerk kommt. Stattdessen wird das Token überprüft, um sicherzustellen, dass die API nur im Namen des App-Benutzers funktioniert, den die Microsoft Entra ID überprüft hat.

Wenn eine API (wir bezeichnen sie als Original-API) eine andere aufruft, ist es wichtig, dass die API, die wir aufrufen (wir bezeichnen sie als Downstream-API), dem Validierungsprozess 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 wird die Original-API zur alleinigen Autorität darüber, über welche Benutzer welche Ergebnisse gegen die Downstream-API erzielen können. Die Original-API kann es einem Benutzer absichtlich (oder unbeabsichtigt) ermöglichen, eine Aufgabe auszuführen, die der Benutzer sonst nicht ausführen kann. Beispielsweise kann ein Benutzer die Details eines anderen Benutzers ändern oder Dokumente lesen und aktualisieren, für die der Benutzer keine Zugriffsberechtigung hat. 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.

1. Die Client-App ruft das Zugriffstoken ab, um die Original-API aufzurufen. Die Clientanwendung ruft ein delegiertes Berechtigungszugriffstoken für die Original-API ab. Das delegierte Berechtigungszugriffstoken ermöglicht es, im Auftrag des Benutzers die Original-API aufzurufen, die eine Autorisierung erfordert.
2. Die Client-App stellt ein Zugriffstoken für die ursprüngliche API bereit. Die Client-App übergibt das Zugriffstoken an die Original-API. Die Original-API überprüft und inspiziert das Zugriffstoken, um die Identität des Benutzers der Client-App zu ermitteln.
3. Die ursprüngliche API führt die Tokenvalidierung und -durchsetzung durch. Nachdem die Client-App das Zugriffstoken an die Original-API übergeben hat, führt die Original-API die Tokenvalidierung und -durchsetzung durch. Wenn alles gut ist, fährt die API fort und erfüllt die Anforderung für die Client-App.
4. Die ursprüngliche API kann das Zugriffstoken nicht verwenden, um die Downstream-API aufzurufen. Die Original-API möchte eine Downstream-API aufrufen. Die Original-API kann das Zugriffstoken jedoch nicht verwenden, um die Downstream-API aufzurufen.
5. Die ursprüngliche API geht auf die Microsoft Entra ID zurück. Die ursprüngliche API muss zur Microsoft Entra ID zurückkehren. Sie benötigt ein Zugriffstoken, um die Downstream-API im Namen des Benutzers aufzurufen. Die Original-API stellt das Token bereit, das die Original-API von der Client-App empfangen hat, und die Clientanmeldeinformationen der Original-API.
6. Microsoft Entra ID führt Überprüfungen durch. 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). 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.
7. Die ursprüngliche API verfügt über einen Benutzerkontext mit dem On-Behalf-Of-Flow. Der OBO-Prozess (On-Behalf-Of Flow ) ermöglicht es einer API, weiterhin über den Benutzerkontext zu verfügen, wenn sie die Downstream-API aufruft.
8. Die ursprüngliche API ruft die Downstream-API auf. Rufen Sie die Downstream-API auf. Das Token, das die Downstream-API empfängt, weist den richtigen Zielgruppenanspruch (aud) auf, der die Downstream-API angibt. 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.

Die beste Option besteht darin, dass die Original-API einen On-Behalf-Of-Flow (OBO) ausführt. 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 und gleichzeitig die Sicherheit der Anwendung Zero Trust mit geringsten Berechtigungen zu erhöhen.
• 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.
• Sicherheitsbewährte Methoden für Anwendungseigenschaften beschreibt Redirect-URI, Zugriffstoken, 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.