Authentifizierung und Autorisierung für APIs in Azure API Management

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.

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.

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.

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.

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.

Beispiel:

• Schützen einer API in Azure API Management mithilfe der OAuth 2.0-Autorisierung mit Microsoft Entra ID

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.

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.

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:

• Konfigurieren der Anmeldeinformationsverwaltung – Microsoft Graph-API
• Konfigurieren der Anmeldeinformationsverwaltung – GitHub-API
• Konfigurieren der Anmeldeinformationsverwaltung – benutzerdelegierter Zugriff auf Back-End-API

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

Dienstseitige Optionen

Nächste Schritte

• Erfahren Sie mehr über Authentifizierung und Autorisierung in der Microsoft Identity Platform.
• Erfahren Sie, wie Sie OWASP-API-Sicherheitsbedrohungen mithilfe von API Management mindern.