Teilen über

OAuth 2.0-Verbindungen im Anmeldedaten-Manager – Prozessdetails und Abläufe

GILT FÜR: Alle API Management-Ebenen

Dieser Artikel enthält Details zu den Prozessflüssen zum Verwalten von OAuth 2.0-Verbindungen mithilfe des Anmeldeinformations-Managers in Azure API Management. Die Prozessflüsse sind in zwei Teile unterteilt: Verwaltung und Laufzeit.

Hintergrundinformationen zum Anmeldeinformations-Manager in der API-Verwaltung finden Sie unter Informationen zum Anmeldeinformations-Manager und API-Anmeldeinformationen in der API-Verwaltung.

Verwaltung von Verbindungen

Der Verwaltungsteil von Verbindungen im Anmeldeinformations-Manager kümmert sich um das Einrichten und Konfigurieren eines Anmeldeinformationsanbieters für OAuth 2.0-Token, wodurch der Zustimmungsfluss für den Anbieter aktiviert und eine oder mehrere Verbindungen mit dem Anmeldeinformationsanbieter für den Zugriff auf die Anmeldeinformationen eingerichtet werden.

Die folgende Abbildung fasst den Prozessablauf zum Erstellen einer Verbindung in der API-Verwaltung zusammen, die den Autorisierungscode-Erteilungstyp verwendet.

Diagramm, das den Prozessfluss zum Erstellen von Anmeldeinformationen zeigt.

Schritt Description
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 Der Client sendet eine Anforderung, um eine Login-URL abzurufen, um die OAuth 2.0-Zustimmung beim Anbieter von Zugangsdaten zu starten. Die Anforderung enthält eine URL nach der Umleitung, die im letzten Schritt verwendet werden soll.
6 Die Antwort wird mit einer Anmelde-URL zurückgegeben, die zum Starten des Zustimmungsflusses verwendet werden soll.
7 Der Client öffnet einen Browser mit der Anmelde-URL, die im vorherigen Schritt angegeben wurde. Der Browser wird an den OAuth 2.0-Zustimmungsfluss des Anbieters von Anmeldeinformationen umgeleitet.
8 Nachdem die Einwilligung genehmigt wurde, wird der Browser mit einem Autorisierungscode zur konfigurierten Umleitungs-URL beim Credential-Anbieter umgeleitet.
9 Api Management verwendet den Autorisierungscode zum Abrufen von Zugriffs- und Aktualisierungstoken.
10 DIE API-Verwaltung empfängt die Token und verschlüsselt sie.
11 Die API-Verwaltung leitet zu der in Schritt 5 bereitgestellten URL um.

Authentifizierungsanbieter

Beim Konfigurieren Ihres Anmeldeinformationsanbieters können Sie zwischen verschiedenen OAuth-Anbietern und Erteilungstypen (Autorisierungscode oder Clientanmeldeinformationen) wählen. Für jeden Anbieter sind bestimmte Konfigurationen erforderlich. 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, die die Standards des OAuth 2.0-Flusses unterstützen.

Wenn Sie einen Anmeldeinformationsanbieter konfigurieren, erstellt der Anmeldeinformations-Manager hinter den Kulissen einen Anmeldeinformationsspeicher , der zum Zwischenspeichern der OAuth 2.0-Zugriffstoken und Aktualisierungstoken des Anbieters verwendet wird.

Verbindung mit einem Anmeldeinformationsanbieter

Um Benutzerzugang und die Verwendung von Token für einen Anbieter zu gewährleisten, benötigen Client-Anwendungen eine Verbindung mit dem Authentifizierungsanbieter. Eine bestimmte Verbindung ist durch Zugriffsrichtlinien basierend auf Microsoft Entra-ID-Identitäten zulässig. 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, benötigen Sie zwei Konfigurationen für den Anbieter der Zugangsdaten. In der folgenden Tabelle sind die beiden Grant-Typen zusammengefasst.

Grant-Typ Description
Authorization code (Autorisierungscode) An einen Benutzerkontext gebunden, was bedeutet, dass ein Benutzer der Verbindung zustimmen muss. Solange das Aktualisierungstoken gültig ist, kann die API-Verwaltung neue Zugriffs- und Aktualisierungstoken abrufen. Wenn das Aktualisierungstoken ungültig wird, muss der Benutzer erneut autorisieren. Alle Authentifizierungsanbieter unterstützen den Autorisierungscode. Weitere Informationen
Client credentials (Clientanmeldeinformationen) Ist nicht an einen Benutzer gebunden und wird häufig in Anwendungs-zu-Anwendung-Szenarien verwendet. Für den Gewährungstyp mit Clientanmeldeinformationen ist keine Einwilligung erforderlich, und die Autorisierung wird nicht ungültig.  Weitere Informationen

Für Verbindungen, die auf dem Autorisierungscode-Erteilungstyp basieren, müssen Sie sich beim Anbieter authentifizieren und der Autorisierung zustimmen . Nach erfolgreicher Anmeldung und Autorisierung durch den Anmeldedatenanbieter gibt der Anbieter gültige Zugriffs- und Aktualisierungstoken zurück, die von der API-Verwaltung verschlüsselt und gespeichert werden.

Zugriffsrichtlinie

Sie konfigurieren eine oder mehrere Zugriffsrichtlinien für jede Verbindung. Die Zugriffsrichtlinien bestimmen, 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, Benutzer und Gruppen Ihrer API-Verwaltungsinstanz.

Identität Description Vorteile Überlegungen
Service Principal Identität, deren Token zum Authentifizieren und Gewähren des Zugriffs auf bestimmte Azure-Ressourcen verwendet werden können, wenn eine Organisation Microsoft Entra-ID verwendet. Durch die Verwendung eines Dienstprinzipals vermeiden Organisationen das Erstellen 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 engeren Zugriff auf Verbindungs- und Benutzerdelegierungsszenarien. Ist nicht an eine bestimmte API-Verwaltungsinstanz 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-Verwaltungsinstanz gebunden ist. Standardmäßig wird der Zugriff auf die vom System zugewiesene verwaltete Identität für die entsprechende API-Verwaltungsinstanz bereitgestellt. Die Identität ist an Ihre API-Verwaltungsinstanz gebunden. Jeder Benutzer mit Mitwirkenderzugriff auf die API-Verwaltungsinstanz kann auf jede Verbindung zugreifen, die verwaltete Identitätsberechtigungen gewährt.
Benutzer oder Gruppen Benutzer oder Gruppen in Ihrem Microsoft Entra ID-Mandanten. Ermöglicht Es Ihnen, den Zugriff auf bestimmte Benutzer oder Benutzergruppen einzuschränken. Erfordert, dass Benutzer über ein Microsoft Entra-ID-Konto verfügen.

Laufzeit von Verbindungen

Für das Laufzeitteil muss eine Back-End-OAuth 2.0-API mit der Get-Authorization-Kontextrichtlinie 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 die API-Verwaltung eingeht und die get-authorization-context Richtlinie ausgeführt wird, wird zuerst überprüft, ob das vorhandene Autorisierungstoken gültig ist. Wenn das Autorisierungstoken abgelaufen ist, verwendet die API-Verwaltung einen OAuth 2.0-Fluss, um die gespeicherten Token vom Anmeldeinformationsanbieter zu aktualisieren. Anschließend 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 Beispielprozessablauf zum Abrufen und Speichern von Autorisierungs- und Aktualisierungstoken basierend auf einer Verbindung, die den Autorisierungscodegenehmigungstyp verwendet. Nachdem die Token abgerufen wurden, wird ein Aufruf der Back-End-API ausgeführt.

Diagramm, das den Prozessfluss zum Abrufen von Token zur Laufzeit zeigt.

Schritt Description
1 Der Client sendet eine Anforderung an die API-Verwaltungsinstanz.
2 Die Get-Authorization-Context-Richtlinie überprüft, ob das Zugriffstoken für die aktuelle Verbindung gültig ist.
3 Wenn das Zugriffstoken abgelaufen ist, aber das Aktualisierungstoken gültig ist, versucht die API-Verwaltung, neue Zugriffs- und Aktualisierungstoken vom konfigurierten Anmeldeinformationsanbieter 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 set-header Richtlinie als Autorisierungsheader an die ausgehende Anforderung an die Back-End-API angefügt.
6 Die Antwort wird an die API-Verwaltung zurückgegeben.
7 Die Antwort wird an den Client zurückgegeben.

Verwandte Inhalte

  • Last updated on