OAuth 2.0-Verbindungen im Anmeldeinformations-Manager – Prozessdetails und Flows

  • Artikel

GILT FÜR: Alle API Management-Ebenen

In diesem Artikel erfahren Sie mehr über die Prozessflows zum Verwalten von OAuth 2.0-Verbindungen mithilfe des Anmeldeinformations-Managers in Azure API Management. Die Prozessflows sind in zwei Teile unterteilt: Verwaltung und Laufzeit.

Hintergrundinformationen zum Anmeldeinformationsmanager in der API-Verwaltung finden Sie unter Über den Anmeldeinformationsmanager und API-Anmeldeinformationen in API Management.

Verwaltung von Verbindungen

Der Verwaltungsanteil der Verbindungen im Anmeldeinformations-Manager übernimmt das Einrichten und Konfigurieren eines Anmeldeinformationsanbieters für OAuth 2.0-Token, das Aktivieren des Einwilligungsflows für den Anbieter und das Einrichten von Verbindungen mit dem Anmeldeinformationsanbieter für den Zugriff auf die Anmeldeinformationen.

Die folgende Abbildung zeigt den Prozessflow zum Erstellen einer Verbindung in API Management, die den Gewährungstyp mit Autorisierungscode verwendet.

Diagramm, das den Prozessflow zum Erstellen von Anmeldeinformationen zeigt.

Schritt Beschreibung
1 Der Client sendet eine Anforderung zum Erstellen eines Anmeldeinformationsanbieters.
2 Der Anmeldeinformationsanbieter wird erstellt, und eine Antwort wird zurückgesendet.
3 Der Client sendet eine Anforderung zum Erstellen einer Verbindung
4 Die Verbindung wird erstellt, und eine Antwort wird mit der Information zurückgesendet, dass die Autorisierung nicht „verbunden“ ist
5 Client sendet eine Anforderung zum Abrufen einer Anmelde-URL, um die OAuth 2.0-Einwilligung beim Anmeldeinformationsanbieter zu starten. Die Anforderung enthält eine Post-Umleitungs-URL zur Verwendung im letzten Schritt
6 Antwort wird mit einer Anmelde-URL zurückgegeben, die zum Starten des Einwilligungsflows verwendet werden sollte.
7 Client öffnet einen Browser mit der Anmelde-URL, die im vorherigen Schritt bereitgestellt wurde. Der Browser wird an den OAuth 2.0-Einwilligungsfluss des Anmeldeinformationsanbieters umgeleitet
8 Nachdem die Einwilligung genehmigt ist, wird der Browser mit einem Autorisierungscode an die Umleitungs-URL umgeleitet, die beim Anmeldeinformationsanbieter konfiguriert ist
9 API Management verwendet den Autorisierungscode zum Abrufen von Zugriffs- und Aktualisierungstoken
10 API Management empfängt die Token und verschlüsselt sie
11 API Management leitet an die in Schritt 5 bereitgestellte URL um

Anmeldeinformationsanbieter

Bei der Konfiguration Ihres Anmeldeinformationsanbieters können Sie zwischen verschiedenen OAuth-Anbietern und Gewährungstypen (Autorisierungscode oder Clientanmeldeinformationen) auswählen. Jeder Anbieter erfordert spezifische Konfigurationen. Wichtige Punkte, die Sie beachten sollten:

  • Eine Anmeldeinformationsanbieter-Konfiguration kann nur einen Gewährungstyp enthalten.
  • Eine Anmeldeinformationsanbieter-Konfiguration kann mehrere Verbindungen aufweisen.

Hinweis

Mit dem generischen OAuth 2.0-Anbieter können andere Identitätsanbieter verwendet werden, welche die Standards des OAuth 2.0-Flows unterstützen.

Wenn Sie einen Anmeldeinformationsanbieter konfigurieren, erstellt der Anmeldeinformations-Manager im Hintergrund einen Anmeldeinformationsspeicher zum Zwischenspeichern der OAuth 2.0-Zugriffstoken und Aktualisierungstoken des Anbieters.

Verbindung mit einem Anmeldeinformationsanbieter

Um auf Token für einen Anbieter zuzugreifen und diese zu verwenden, benötigen Client-Apps eine Verbindung mit dem Anmeldeinformationsanbieter. Eine bestimmte Verbindung wird durch Zugriffsrichtlinien basierend auf Microsoft Entra ID-Identitäten zugelassen. Sie können mehrere Verbindungen für einen Anbieter konfigurieren.

Der Prozess der Konfiguration einer Verbindung unterscheidet sich nach der konfigurierten Gewährung und ist spezifisch für die Anmeldeinformationsanbieter-Konfiguration. Wenn Sie beispielsweise Microsoft Entra ID so konfigurieren möchten, dass beide Gewährungstypen verwendet werden, sind zwei Anmeldeinformationsanbieter-Konfigurationen erforderlich. In der folgenden Tabelle werden die beiden Gewährungstypen zusammengefasst.

Gewährungstyp BESCHREIBUNG
Authorization code (Autorisierungscode) Gebunden an einen Benutzerkontext, d. h., Benutzer*innen müssen in die Autorisierung einwilligen. Solange das Aktualisierungstoken gültig ist, kann API Management neue Zugriffs- und Aktualisierungstoken abrufen. Wenn das Aktualisierungstoken ungültig wird, muss der Benutzer sich erneut authentifizieren. Alle Anmeldeinformationsanbieter unterstützen Autorisierungscode. Weitere Informationen
Client credentials (Clientanmeldeinformationen) Ist nicht an einen Benutzer gebunden, und wird häufig in Anwendungs-zu-Anwendungs-Szenarien verwendet. Für den Gewährungstyp mit Clientanmeldeinformationen ist keine Einwilligung erforderlich, und die Autorisierung wird nicht ungültig. Weitere Informationen

Bei Verbindungen, die auf dem Gewährungstyp „Autorisierungscode“ basieren, müssen Sie sich beim Anbieter authentifizieren und in die Autorisierung einwilligen. Nach erfolgreicher Anmeldung und Autorisierung durch den Anmeldeinformationsanbieter gibt der Anbieter gültige Zugriffs- und Aktualisierungstoken zurück, die verschlüsselt und von API Management gespeichert werden.

Zugriffsrichtlinie

Sie konfigurieren für jede Verbindung Zugriffsrichtlinien. Die Zugriffsrichtlinien legen fest, welche Microsoft Entra ID-Identitäten zur Laufzeit Zugriff auf Ihre Anmeldeinformationen erhalten können. Verbindungen unterstützen derzeit den Zugriff über Dienstprinzipale, die Identität Ihrer API Management-Instanz, Benutzer*innen und Gruppen.

Identity BESCHREIBUNG Vorteile Überlegungen
Dienstprinzipal Die Identität, deren Token zum Authentifizieren und Gewähren des Zugriffs auf bestimmte Azure-Ressourcen verwendet werden können, wenn ein Organisation Microsoft Entra ID verwendet. Mithilfe eines Dienstprinzipals vermeiden Organisationen die Erstellung fiktiver Benutzer, um die Authentifizierung zu verwalten, wenn sie auf eine Ressource zugreifen müssen. Ein Dienstprinzipal ist eine Microsoft Entra-Identität, die eine registrierte Microsoft Entra-Anwendung darstellt. Ermöglicht einen engeren Zugriff auf Verbindungs- und Benutzerdelegationsszenarien. Ist nicht an bestimmte API Management-Instanzen gebunden. Basiert auf der Microsoft Entra-ID für die Erzwingung von Berechtigungen. Zum Abrufen des Autorisierungskontexts ist ein Microsoft Entra ID-Token erforderlich.
Verwaltete Identität <Your API Management instance name> Diese Option entspricht einer verwalteten Identität, die an Ihre API Management-Instanz gebunden ist. Standardmäßig erfolgt der Zugriff auf die systemseitig zugewiesene verwaltete Identität für die entsprechende API Management-Instanz. Die Identität ist an Ihre API Management-Instanz gebunden. Alle Benutzer*innen mit Zugriff als „Mitwirkender“ auf die API Management-Instanz können auf alle Verbindungen zugreifen, die Berechtigungen für verwaltete Identitäten gewähren.
Benutzer oder Gruppen Benutzer*innen oder Gruppen in Ihrem Microsoft Entra ID-Mandanten. Ermöglicht Ihnen, den Zugriff auf bestimmte Benutzer*innen oder Gruppen einzuschränken. Erfordert ein Microsoft Entra ID-Konto für Benutzer*innen.

Verbindungen zur Laufzeit

Für den Laufzeitanteil muss eine OAuth 2.0-Back-End-API mit der Richtlinie get-authorization-context konfiguriert werden. Zur Laufzeit holt und speichert die Richtlinie Zugriffs- und Aktualisierungs-Tokens aus dem Berechtigungsnachweis-Speicher, den API Management für den Anbieter eingerichtet hat. Wenn ein Aufruf in API Management eingeht und die get-authorization-context-Richtlinie ausgeführt wird, wird zunächst überprüft, ob das vorhandene Autorisierungstoken gültig ist. Wenn das Autorisierungstoken abgelaufen ist, verwendet API Management einen OAuth 2.0-Flow, um die gespeicherten Token vom Anmeldeinformationsanbieter zu aktualisieren. Dann wird das Zugriffstoken verwendet, um den Zugriff auf den Back-End-Dienst zu autorisieren.

Während der Richtlinienausführung wird der Zugriff auf die Token auch mithilfe von Zugriffsrichtlinien überprüft.

Die folgende Abbildung zeigt einen Beispielprozessflow zum Abrufen und Speichern von Autorisierungs- und Aktualisierungstoken basierend auf einer Verbindung, die den Gewährungstyp mit Autorisierungscode verwenden. Nachdem die Token abgerufen wurden, erfolgt ein Aufruf an die Back-End-API.

Diagramm, das den Prozessflow zum Abrufen von Token zur Runtime zeigt.

Schritt Beschreibung
1 Der Client sendet eine Anforderung an die API Management-Instanz
2 Die Richtlinie get-authorization-context überprüft, ob das Zugriffstoken für die aktuelle Verbindung gültig ist
3 Wenn das Zugriffstoken abgelaufen, das Aktualisierungstoken aber gültig ist, versucht API Management, neue Zugriffs- und Aktualisierungstoken vom konfigurierten Anmeldeinformationsanbietern abzurufen
4 Der Anmeldeinformationsanbieter gibt sowohl ein Zugriffstoken als auch ein Aktualisierungstoken zurück, die verschlüsselt und in API Management gespeichert werden
5 Nachdem die Token abgerufen wurden, wird das Zugriffstoken mithilfe der Richtlinie set-header als Autorisierungsheader an die ausgehende Anforderung zur Back-End-API angefügt
6 Die Antwort wird an API Management zurückgegeben
7 Die Antwort wird an den Client zurückgegeben

Zugehöriger Inhalt