Freigeben über

Authentifizierung und Autorisierung für APIs in Azure API Management

  • Artikel

GILT FÜR: Alle API Management-Ebenen

Dieser Artikel enthält eine Einführung in eine umfassende, flexible Reihe von Features in API Management, mit denen Sie den Zugriff von Benutzern auf verwaltete APIs schützen können.

Die API-Authentifizierung und -Autorisierung in API Management umfasst die End-to-End-Kommunikation von Client-Apps über das API Management-Gateway zu Backend-APIs. In vielen Kundenumgebungen ist OAuth 2.0 das bevorzugte API-Autorisierungsprotokoll. API Management unterstützt die OAuth 2.0-Autorisierung zwischen dem Client und dem API Management Gateway, zwischen dem Gateway und der Backend-API oder beides unabhängig.

Diagramm der Interaktionspunkte für die Sicherung von APIs.

API Management unterstützt andere client- und dienstseitige Authentifizierungs- und Autorisierungsmechanismen, die OAuth 2.0 ergänzen oder nützlich sind, wenn die OAuth 2.0-Autorisierung für APIs nicht möglich ist. Wie Sie aus diesen Optionen auswählen, hängt von der Reife der API-Umgebung Ihres Organisation, Ihren Sicherheits- und Complianceanforderungen und dem Ansatz Ihres Organisation zur Eindämmung allgemeiner API-Bedrohungen ab.

Wichtig

Das Schützen des Zugriffs von Benutzern auf APIs ist eine von vielen Überlegungen zum Schutz Ihrer API Management-Umgebung. Weitere Informationen zur API Management-Sicherheit finden Sie unter Azure-Sicherheitsbaseline für API Management.

Hinweis

Andere API Management-Komponenten verfügen über separate Mechanismen zum Schützen und Einschränken des Benutzerzugriffs:

Authentifizierung kontra Autorisierung

Hier finden Sie eine kurze Erläuterung der Authentifizierung und Autorisierung im Kontext des Zugriffs auf APIs:

  • Authentifizierung: Der Prozess der Überprüfung der Identität eines Benutzers oder einer App, die auf die API zugreift. Die Authentifizierung kann über Anmeldeinformationen wie Benutzername und Kennwort, ein Zertifikat oder über einmaliges Anmelden (Single Sign-On, SSO) oder andere Methoden erfolgen.

  • Autorisierung: Der Prozess zum Bestimmen, ob ein Benutzer oder eine App über die Berechtigung für den Zugriff auf eine bestimmte API verfügt, häufig über ein tokenbasiertes Protokoll wie OAuth 2.0.

Hinweis

Um die Authentifizierung und Autorisierung zu ergänzen, sollte der Zugriff auf APIs auch mithilfe von TLS gesichert werden, um die Anmeldeinformationen oder Token zu schützen, die für die Authentifizierung oder Autorisierung verwendet werden.

OAuth 2.0-Konzepte

OAuth 2.0 ist ein Standardautorisierungsframework, das häufig zum Sichern des Zugriffs auf Ressourcen wie Web-APIs verwendet wird. OAuth 2.0 schränkt Aktionen ein, die eine Client-App für Ressourcen im Namen des Benutzers ausführen kann, ohne jemals die Anmeldeinformationen des Benutzers freizugeben. OAuth 2.0 ist zwar kein Authentifizierungsprotokoll, wird aber häufig mit OpenID Connect (OIDC) verwendet, das OAuth 2.0 durch die Bereitstellung von Benutzerauthentifizierung und SSO-Funktionalität erweitert.

OAuth-Flow

Was passiert, wenn eine Client-App eine API mit einer Anfrage aufruft, die mit TLS und OAuth 2.0 gesichert ist? Das Folgende ist ein verkürzter Beispielablauf:

  • Der Client (die aufrufende App oder der Bearer) authentifiziert sich mithilfe von Anmeldeinformationen bei einem Identitätsanbieter.

  • Der Client erhält vom Autorisierungsserver des Identitätsanbieters ein zeitlich begrenztes Zugriffstoken (ein JSON-Webtoken oder JWT).

    Der Identitätsanbieter (z. B. Microsoft Entra ID) ist der Aussteller des Tokens, und das Token enthält einen Zielgruppenanspruch, der den Zugriff auf einen Ressourcenserver autorisiert (z. B. auf eine Back-End-API oder auf das API Management-Gateway selbst).

  • Der Client ruft die API auf und präsentiert das Zugriffstoken – zum Beispiel in einem Authorization-Header.

  • Der Ressourcenserver validiert das Zugriffstoken. Die Validierung ist ein komplexer Prozess, der eine Überprüfung umfasst, ob die Aussteller und die Zielgruppenansprüche erwartete Werte enthalten.

  • Basierend auf Token-Validierungskriterien wird dann Zugriff auf Ressourcen der Backend-API gewährt.

Je nach Typ der Client-App und Szenarien sind unterschiedliche Autorisierungsabläufe erforderlich, um Token anzufordern und zu verwalten. Beispielsweise werden der Autorisierungscodefluss und der Gewährungstyp häufig in Apps verwendet, die Web-APIs aufrufen. Erfahren Sie mehr über OAuth-Fluss- und Anwendungsszenarien in Microsoft Entra ID.

OAuth 2.0-Autorisierungsszenarien in API Management

Szenario 1: Client-App autorisiert direkt für das Backend

Ein häufiges Autorisierungsszenario ist, wenn die aufrufende Anwendung den Zugriff auf die Backend-API direkt anfordert und ein OAuth 2.0-Token in einem Autorisierungsheader für das Gateway darstellt. Azure API Management fungiert dann als "transparenter" Proxy zwischen dem Aufrufer und der Backend-API und übergibt das Token unverändert an das Backend. Der Geltungsbereich des Zugriffstokens liegt zwischen der aufrufenden Anwendung und der Back-End-API.

Folgende Abbildung zeigt ein Beispiel, in dem Microsoft Entra ID der Autorisierungsanbieter ist. Die Client-App kann eine Single-Page-Anwendung (SPA) sein.

Das Diagramm zeigt die OAuth-Kommunikation, wobei die Zielgruppe das Back-End ist.

Obwohl das zusammen mit der HTTP-Anforderung gesendete Zugriffstoken für die Backend-API vorgesehen ist, ermöglicht API Management dennoch einen Ansatz zur Tiefenverteidigung. Konfigurieren Sie beispielsweise Richtlinien zum Validieren von JWT und zum Ablehnen von Anfragen, die ohne Token ankommen, oder mit einem Token, das für die vorgesehene Backend-API nicht gültig ist. Sie können API Management auch so konfigurieren, dass andere aus dem Token extrahierte Claims of Interest geprüft werden.

Hinweis

Wenn Sie eine API schützen, die auf diese Weise über Azure API Management mit OAuth 2.0 verfügbar gemacht wird, können Sie API Management konfigurieren, um ein gültiges Token für Testzwecke im Auftrag eines Azure-Portal- oder Entwicklerportal-Testkonsolenbenutzers zu generieren. Sie müssen Ihrer API Management-Instanz einen OAuth 2.0-Server hinzufügen und die OAuth 2.0-Autorisierungseinstellungen in der API aktivieren. Weitere Informationen finden Sie unter Autorisieren der Testkonsole des Entwicklerportals durch Konfigurieren der OAuth 2.0-Benutzerautorisierung.

Beispiel:

Tipp

In dem speziellen Fall, wenn der API-Zugriff mithilfe von Microsoft Entra ID geschützt ist, können Sie die Richtlinie validate-azure-ad-token für die Tokenüberprüfung konfigurieren.

Szenario 2: Client-App autorisiert API Management

In diesem Szenario handelt der API Management-Dienst im Auftrag der API und die aufrufende Anwendung fordert Zugriff auf die API Management-Instanz an. Der Geltungsbereich des Zugriffstokens liegt zwischen der aufrufenden Anwendung und dem API Management-Gateway. Konfigurieren Sie in API Management eine Richtlinie (validate-jwt oder validate-azure-ad-token), um das Token zu überprüfen, bevor das Gateway die Anforderung an das Backend übergibt. Ein separater Mechanismus sichert in der Regel die Verbindung zwischen dem Gateway und der Backend-API.

Im folgenden Beispiel ist Microsoft Entra ID erneut der Autorisierungsanbieter, während die gegenseitige TLS-Authentifizierung (mTLS) die Verbindung zwischen dem Gateway und dem Backend sichert.

Das Diagramm zeigt die OAuth-Kommunikation, wobei die Zielgruppe das API Management-Gateway ist.

Es gibt verschiedene Gründe, dies tun zu wollen. Beispiel:

  • Das Backend ist eine veraltete API, die nicht aktualisiert werden kann, um OAuth zu unterstützen

    API Management sollte zunächst so konfiguriert werden, dass das Token validiert wird (mindestens die Ansprüche des Ausstellers und der Zielgruppe werden überprüft). Verwenden Sie nach der Validierung eine der verschiedenen Optionen, zur Absicherung weiterführender Verbindungen von API Management, z. B. die gegenseitige TLS-Authentifizierung (mTLS). Siehe Dienstseitige Optionen finden Sie weiter unten in diesem Artikel.

  • Der vom Backend benötigte Kontext kann vom Aufrufer nicht ermittelt werden

    Nachdem API Management das vom Aufrufer empfangene Token erfolgreich validiert hat, muss es ein Zugriffstoken für die Back-End-API unter Verwendung seines eigenen Kontexts oder eines von der aufrufenden Anwendung abgeleiteten Kontexts abrufen. Dieses Szenario kann mit einer der folgenden Methoden ausgeführt werden:

    • Eine benutzerdefinierte Richtlinie wie send-request, um ein für die Backend-API gültiges Onward Access Token von einem konfigurierten Identitätsanbieter zu erhalten.

    • Die eigene Identität der API Management-Instanz – Übergeben des Tokens von der vom System oder vom Benutzer zugewiesenen verwalteten Identität der API Management-Ressource an die Back-End-API.

  • Die Organisationorganization möchte einen standardisierten Autorisierungsansatz verfolgen

    Unabhängig von den Authentifizierungs- und Autorisierungsmechanismen in ihren API-Backends können Organisationen sich für eine Konvergierung mit OAuth 2.0 für einen standardisierten Autorisierungsansatz im Front-End entscheiden. das Gateway von API Management kann eine konsistente Autorisierungskonfiguration und eine allgemeine Benutzeroberfläche für API-Consumer ermöglichen, wenn sich die Backends der Organisation weiterentwickeln.

Szenario 3: API Management autorisiert das Backend

Mit verwalteten Verbindungen (früher als Autorisierungen bezeichnet) verwenden Sie die Anmeldeinformationsverwaltung in API Management, um den Zugriff auf einen oder mehrere Back-End- oder SaaS-Dienste wie LinkedIn, GitHub oder andere OAuth 2.0-kompatible Back-Ends zu autorisieren. In diesem Szenario stellt ein Benutzer oder eine Client-App eine Anforderung an das API Management-Gateway, wobei der Gatewayzugriff über einen Identitätsanbieter oder andere clientseitige Optionen gesteuert wird. Anschließend delegiert der Benutzer oder die Client-App mithilfe der Richtlinienkonfiguration die Backend-Authentifizierung und -Autorisierung an API Management.

Im folgenden Beispiel wird ein Abonnementschlüssel zwischen dem Client und dem Gateway verwendet, und GitHub ist der Anmeldeinformationsanbieter für die Back-End-API.

Diagramm, das die Autorisierung für den SaaS-Back-End-Dienst mithilfe einer in der Anmeldeinformationsverwaltung verwalteten Verbindung zeigt.

Mit einer Verbindung mit einem Anmeldeinformationsanbieter ruft API Management die Token für den API-Zugriff im OAuth 2.0-Flow ab und aktualisiert sie. Verbindungen vereinfachen die Tokenverwaltung in mehreren Szenarien, Beispiele:

  • Eine Client-App muss möglicherweise mehrere SaaS-Backends autorisieren, um mehrere Felder mit GraphQL-Resolvern aufzulösen.
  • Benutzer*innen authentifizieren sich bei API Management durch einmaliges Anmelden über ihren Identitätsanbieter. Einen Backend-SaaS-Anbieter (z. B. LinkedIn) autorisieren sie jedoch mithilfe eines gemeinsamen Organisationskontos.
  • Eine Client-App (oder ein Bot) muss im Namen eines authentifizierten Benutzers bzw. einer authentifizierten Benutzerin auf gesicherte Onlineressourcen im Back-End zugreifen (also z. B. E-Mails überprüfen oder eine Bestellung aufgeben).

Beispiele:

Andere Optionen zum Schützen von APIs

Obwohl die Autorisierung bevorzugt wird und OAuth 2.0 die dominierende Methode zum Aktivieren einer starken Autorisierung für APIs geworden ist, bietet API Management mehrere andere Mechanismen zum Sichern oder Einschränken des Zugriffs zwischen Client und Gateway (Clientseite) oder zwischen Gateway und Backend (Dienstseite). Je nach den Anforderungen der Organisation können diese zur Ergänzung von OAuth 2.0 verwendet werden. Konfigurieren Sie sie auch unabhängig, wenn die aufrufenden Anwendungen oder Backend-APIs veraltet sind oder OAuth 2.0 nicht unterstützen.

Clientseitige Optionen

Mechanismus Beschreibung Überlegungen
mTLS Überprüfen Sie das Zertifikat, das vom verbindenden Client bereitgestellt wird, und überprüfen Sie die Zertifikateigenschaften anhand eines in API Management verwalteten Zertifikats Das Zertifikat kann in einem Schlüsseltresor gespeichert werden.
Beschränkung für Aufrufer-IP Filtern (Zulassen/Verweigern) von Aufrufen von bestimmten IP-Adressen oder Adressbereichen. Dient dazu, den Zugriff auf bestimmte Benutzer oder Organisationen oder den Datenverkehr von Upstream-Diensten einzuschränken.
Abonnementschlüssel Beschränken des Zugriffs auf mindestens eine APIs basierend auf einem API Management-Abonnement Wir empfehlen die Verwendung eines Abonnementschlüssels (API) zusätzlich zu einer anderen Authentifizierungs- oder Autorisierungsmethode. Ein Abonnementschlüssel allein ist keine starke Form der Authentifizierung, aber die Verwendung des Abonnementschlüssels kann in bestimmten Szenarien nützlich sein, z. B. zum Nachverfolgen der API-Nutzung einzelner Kunden oder zur Gewährung von Zugang zu bestimmten API-Produkten.

Tipp

Zur ausführlichen Verteidigung wird dringend empfohlen, eine Web Application-in den Zugang zur API Management-Instanz einzufügen. Verwenden Sie beispielsweise Azure Application Gateway oder Azure Front Door.

Dienstseitige Optionen

Mechanismus Beschreibung Überlegungen
Authentifizierung der verwalteten Identität Authentifizieren sie sich bei der Backend-API mit einer systemseitig oder benutzerseitig zugewiesenen verwalteten Identität. Empfohlen für den bereichsbezogenen Zugriff auf eine geschützte Backend-Ressource durch Abrufen eines Tokens aus Microsoft Entra ID.
Zertifikatauthentifizierung Authentifizieren bei der Backend-API mithilfe eines Clientzertifikats. Das Zertifikat kann in einem Schlüsseltresor gespeichert werden.
Standardauthentifizierung Authentifizieren Sie sich bei der Backend-API mit Benutzername und Kennwort, die über einen Autorisierungsheader übergeben werden. Nicht empfohlen, wenn bessere Optionen verfügbar sind.

Nächste Schritte