Zugriffstoken in Rest-Api

GILT FÜR: Alle API Management-Tarife

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

Die API-Authentifizierung und -Autorisierung in API Management umfasst die Sicherung der End-to-End-Kommunikation von Client-Apps mit dem API Management-Gateway und über Back-End-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 Back-End-API oder zwischen beiden unabhängig voneinander.

API Management unterstützt andere clientseitige und dienstseitige Authentifizierungs- und Autorisierungsmechanismen, die OAuth 2.0 ergänzen oder bei OAuth 2.0 nützlich sind Eine Autorisierung für APIs ist nicht möglich. Wie Sie sich für eine dieser Optionen entscheiden, hängt vom Reifegrad der API-Umgebung Ihrer Organisation, Ihren Sicherheits- und Complianceanforderungen und dem Ansatz Ihrer Organisation zur Abwehr gängiger API-Bedrohungen ab.

Authentifizierung im Vergleich zur Autorisierung

Im Folgenden finden Sie eine kurze Erläuterung der Authentifizierung und Autorisierung im Zusammenhang mit dem Zugriff 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 durch Single Sign-On (SSO) oder andere Methoden erfolgen.

• Autorisierung : Der Prozess der Bestimmung, ob ein Benutzer oder eine App über die Berechtigung zum 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 Standard-Autorisierungsframework, 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 ausführen kann Ressourcen im Namen des Benutzers, ohne jemals die Anmeldeinformationen des Benutzers weiterzugeben. Obwohl OAuth 2.0 kein Authentifizierungsprotokoll ist, wird es häufig mit OpenID Connect (OIDC) verwendet, das OAuth 2.0 durch die Bereitstellung von Benutzerauthentifizierungs- und SSO-Funktionen erweitert.

OAuth-Ablauf

Was geschieht, wenn eine Client-App eine API mit einer Anforderung aufruft, die mit TLS und OAuth 2.0 gesichert ist? Im Folgenden finden Sie ein abgekürztes Beispielablauf:

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

• Der Client ruft ein zeitlich begrenztes Zugriffstoken (ein JSON-Web-Token oder JWT) vom Autorisierungsserver des Identitätsanbieters ab.

  Der Identitätsanbieter (z. B. Microsoft Entra ID) ist der Aussteller des Tokens, und das Token enthält eine audience-Anspruch, 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, z. B. in einem Authorization-Header.

• Der Ressourcenserver überprüft das Zugriffstoken. Die Validierung ist ein komplexer Prozess, der eine Überprüfung umfasst, ob die Ansprüche des Ausstellers und der Zielgruppe die erwarteten Werte enthalten.

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

Abhängig von der Art der Client-App und den Szenarien sind unterschiedliche Autorisierungsflüsse erforderlich, um Token anzufordern und zu verwalten. Beispielsweise werden der Autorisierungscodeflow und der Berechtigungstyp häufig in Apps verwendet, die Web-APIs aufrufen. Weitere Informationen Informationen zu OAuth-Flows und Anwendungsszenarien in Microsoft Entra ID.

OAuth 2.0-Autorisierungsszenarien in API Management

Szenario 1 – Client-App autorisiert direkt am Back-End

Ein gängiges Autorisierungsszenario besteht darin, dass die aufrufende Anwendung direkt Zugriff auf die Back-End-API anfordert und dem Gateway ein OAuth 2.0-Token in einem Autorisierungsheader präsentiert. Azure API Management fungiert dann als "transparenter" Proxy zwischen dem Aufrufer und der Back-End-API und übergibt das Token unverändert an das Back-End. Der Bereich des Zugriffstokens liegt zwischen der aufrufenden Anwendung und der Back-End-API.

Die folgende Abbildung zeigt ein Beispiel, bei dem Microsoft Entra ID der Autorisierungsanbieter ist. Bei der Client-App kann es sich um eine Single-Page-Anwendung (SPA) handeln.

Obwohl das Zugriffstoken, das zusammen mit der HTTP-Anforderung gesendet wird, für die Back-End-API vorgesehen ist, lässt API Management weiterhin für einen Defense-in-Depth-Ansatz. Konfigurieren Sie z. B. Richtlinien zum Überprüfen des JWT, indem Sie Anforderungen ablehnen, die ohne Token oder ohne Token eingehen, oder ein Token, das für die beabsichtigte Back-End-API nicht gültig ist. Sie können API Management auch so konfigurieren, dass andere interessante Ansprüche überprüft werden, die aus dem Token extrahiert wurden.

Beispiel:

Szenario 2 – Client-App autorisiert sich für API Management

In diesem Szenario handelt der API Management-Dienst im Namen der API, und die aufrufende Anwendung fordert Zugriff auf die API Management-Instanz an. Der Bereich 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 Back-End übergibt. Ein separater Mechanismus sichert in der Regel die Verbindung zwischen dem Gateway und der Backend-API.

Im folgenden Beispiel ist Microsoft Entra ID wieder der Autorisierungsanbieter, und die gegenseitige TLS-Authentifizierung (mTLS) sichert die Verbindung zwischen dem Gateway und dem Back-End.

Dafür gibt es verschiedene Gründe. Für Beispiel:

• Da es sich bei dem Back-End um eine Legacy-API handelt, die nicht aktualisiert werden kann, um OAuth

  API Management zu unterstützen, sollte zunächst so konfiguriert werden, dass das Token validiert wird (wobei mindestens die Ansprüche des Ausstellers und der Zielgruppe überprüft werden). Verwenden Sie nach der Validierung eine von mehreren verfügbaren Optionen, um Weiterverbindungen von API Management zu sichern, z. B. die gegenseitige TLS-Authentifizierung (mTLS). Weitere Informationen finden Sie unter Optionen auf der Dienstseite weiter unten in diesem Artikel.

• Der vom Back-End benötigte Kontext kann vom Aufrufer nicht erstellt werden

  . Nachdem API Management das vom Aufrufer empfangene Token erfolgreich überprüft hat, muss ein Zugriffstoken für die Back-End-API mithilfe eines eigenen Kontexts oder eines von der aufrufenden Anwendung abgeleiteten Kontexts abgerufen werden. Dieses Szenario kann wie folgt erreicht werden:

  • Eine benutzerdefinierte Richtlinie, z. B. send-request to Rufen Sie ein für die Backend-API gültiges Weiterzugriffstoken von einem konfigurierten Identitätsanbieter ab.

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

• Das Unternehmen möchte einen standardisierten Autorisierungsansatz einführen

  Unabhängig von den Authentifizierungs- und Autorisierungsmechanismen in ihren API-Backends können sich Unternehmen für OAuth 2.0 entscheiden, um einen standardisierten Autorisierungsansatz im Frontend zu erhalten. Das Gateway von API Management kann eine konsistente Autorisierungskonfiguration und eine gemeinsame Erfahrung für API-Verbraucher ermöglichen, während sich die Backends des Unternehmens weiterentwickeln.

Szenario 3: API Management autorisiert das Back-End

mit verwalteten Verbindungen (früher als authorizations ) verwenden Sie den Credential Manager in API Management, um den Zugriff auf einen oder mehrere Backend- oder SaaS-Dienste zu autorisieren, z. B. LinkedIn, GitHub oder andere OAuth 2.0-kompatible Back-Ends. In diesem Szenario sendet 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 die Benutzer- oder Client-App über die Richtlinienkonfiguration die Back-End-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.

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

• Eine Client-App benötigt möglicherweise um mehrere SaaS-Backends zu autorisieren, um mehrere Felder mit GraphQL-Resolvern aufzulösen.
• Benutzer authentifizieren sich bei API Management per SSO von ihrem Identitätsanbieter, autorisieren sich jedoch mit einem gemeinsamen Organisationskonto bei einem Back-End-SaaS-Anbieter (z. B. LinkedIn).
• Eine Client-App (oder ein Bot) muss im Namen eines authentifizierten Benutzers auf durch das Back-End gesicherte Onlineressourcen zugreifen (z. B. um E-Mails abzurufen oder eine Bestellung aufzugeben).

Beispiele:

Weitere Optionen zum Sichern von APIs

Obwohl die Autorisierung bevorzugt wird und OAuth 2.0 zur vorherrschenden Methode geworden ist, um eine starke Autorisierung für APIs zu ermöglichen, bietet API Management mehrere andere Mechanismen, um den Zugriff zwischen Client und Gateway (Clientseite) oder zwischen Gateway und Back-End (Dienstseite) zu sichern oder einzuschränken. Abhängig von den Anforderungen der Organisation können diese als Ergänzung zu OAuth 2.0 verwendet werden. Alternativ Konfigurieren Sie sie unabhängig, wenn die aufrufenden Anwendungen oder Backend-APIs veraltet sind oder OAuth 2.0 noch nicht unterstützen.

Nächste Schritte