Delen via

Verificatie en autorisatie van API's in Azure API Management

  • Artikel

VAN TOEPASSING OP: Alle API Management-lagen

Dit artikel is een inleiding tot een uitgebreide, flexibele set functies in API Management waarmee u de toegang van gebruikers tot beheerde API's kunt beveiligen.

API-verificatie en -autorisatie in API Management betreft het beveiligen van de end-to-end-communicatie van client-apps naar de API Management-gateway en de back-end-API's. In veel klantomgevingen is OAuth 2.0 het voorkeursprotocol voor API-autorisatie. API Management ondersteunt OAuth 2.0-autorisatie tussen de client en de API Management-gateway, tussen de gateway en de back-end-API, of beide onafhankelijk.

Diagram met interactiepunten voor het beveiligen van API's.

API Management ondersteunt andere verificatie- en autorisatiemechanismen aan de clientzijde en servicezijde die OAuth 2.0 aanvullen of nuttig zijn wanneer OAuth 2.0-autorisatie voor API's niet mogelijk is. Hoe u uit deze opties kiest, is afhankelijk van de volwassenheid van de API-omgeving van uw organisatie, uw beveiligings- en nalevingsvereisten en de aanpak van uw organisatie om veelvoorkomende API-bedreigingen te beperken.

Belangrijk

Het beveiligen van de toegang van gebruikers tot API's is een van de vele overwegingen voor het beveiligen van uw API Management omgeving. Raadpleeg Azure-beveiligingsbasislijn voor API Management voor meer informatie.

Notitie

Andere API Management-onderdelen hebben afzonderlijke mechanismen om gebruikerstoegang te beveiligen en te beperken:

  • Voor het beheren van het API Management-exemplaar via het Azure-besturingsvlak is API Management afhankelijk van Microsoft Entra ID en op rollen gebaseerd toegangsbeheer van Azure (RBAC).
  • De API Management-ontwikkelaarsportal ondersteunt verschillende opties om het registreren en aanmelden van gebruikers te vergemakkelijken.

Het verschil tussen verificatie en autorisatie

Hier volgt een korte uitleg van verificatie en autorisatie in de context van toegang tot API's:

  • Verificatie: het proces waarbij de identiteit wordt geverifieerd van een gebruiker of app die toegang heeft tot de API. Verificatie kan worden uitgevoerd via referenties zoals gebruikersnaam en wachtwoord, een certificaat of via eenmalige aanmelding (SSO) of andere methoden.

  • Autorisatie: het proces om te bepalen of een gebruiker of app is gemachtigd om toegang te krijgen tot een bepaalde API, vaak via een protocol op basis van tokens, zoals OAuth 2.0.

Notitie

Ter aanvulling op verificatie en autorisatie moet toegang tot API's ook worden beveiligd met behulp van TLS om de referenties of tokens te beveiligen die voor verificatie of autorisatie worden gebruikt.

OAuth 2.0-concepten

OAuth 2.0 is een standaardautorisatieframework dat veel wordt gebruikt om de toegang tot resources zoals web-API's te beveiligen. OAuth 2.0 beperkt acties van wat een client-app namens de gebruiker kan uitvoeren, zonder de referenties van de gebruiker te delen. Hoewel OAuth 2.0 geen verificatieprotocol is, wordt dit vaak gebruikt met OpenID Verbinding maken (OIDC), waarmee OAuth 2.0 wordt uitgebreid door gebruikersverificatie en SSO-functionaliteit te bieden.

OAuth-stroom

Wat gebeurt er wanneer een client-app een API aanroept met een aanvraag die is beveiligd met TLS en OAuth 2.0? Hier volgt een verkorte voorbeeldstroom:

  • De client (de aanroepende app of bearer) verifieert met behulp van referenties voor een id-provider.

  • De client verkrijgt een tijdsgebonden toegangstoken (een JSON-webtoken of JWT) van de autorisatieserver van de id-provider.

    De id-provider (bijvoorbeeld Microsoft Entra-id) is de verlener van het token en het token bevat een doelgroepclaim waarmee toegang tot een resourceserver wordt geautoriseerd (bijvoorbeeld naar een back-end-API of naar de API Management-gateway zelf).

  • De client roept de API aan en geeft het toegangstoken weer, bijvoorbeeld in een autorisatieheader.

  • De resourceserver valideert het toegangstoken. Validatie is een complex proces dat een controle bevat dat de verlener - en doelgroepclaims verwachte waarden bevatten.

  • Op basis van validatiecriteria voor tokens wordt vervolgens toegang tot resources van de back-end-API verleend.

Afhankelijk van het type client-app en scenario's zijn verschillende autorisatiestromen nodig om tokens aan te vragen en te beheren. De autorisatiecodestroom en het toekenningstype worden bijvoorbeeld vaak gebruikt in apps die web-API's aanroepen. Meer informatie over OAuth-stromen en toepassingsscenario's in Microsoft Entra ID.

OAuth 2.0-autorisatiescenario's in API Management

Scenario 1: client-app autoriseert rechtstreeks naar de back-end

Een veelvoorkomend autorisatiescenario is wanneer de aanroepende toepassing rechtstreeks toegang tot de back-end-API aanvraagt en een OAuth 2.0-token in een autorisatieheader naar de gateway presenteert. Azure API Management fungeert vervolgens als een 'transparante' proxy tussen de aanroeper en de back-end-API en geeft het token door aan de back-end ongewijzigd. Het bereik van het toegangstoken is tussen de aanroepende toepassing en de back-end-API.

In de volgende afbeelding ziet u een voorbeeld waarin Microsoft Entra-id de autorisatieprovider is. De client-app kan een toepassing met één pagina (SPA) zijn.

Diagram met OAuth-communicatie waarbij de doelgroep de back-end is.

Hoewel het toegangstoken dat samen met de HTTP-aanvraag wordt verzonden, is bedoeld voor de back-end-API, biedt API Management nog steeds een diepgaande verdedigingsbenadering. Configureer bijvoorbeeld beleidsregels om de JWT te valideren, aanvragen te weigeren die zonder token binnenkomen of een token dat niet geldig is voor de beoogde back-end-API. U kunt API Management ook configureren om andere renteclaims te controleren die zijn geëxtraheerd uit het token.

Notitie

Als u op deze manier een API beveiligt die beschikbaar is via Azure API Management met OAuth 2.0, kunt u API Management configureren om een geldig token te genereren voor testdoeleinden namens een testconsolegebruiker in de Azure-portal of in de ontwikkelaarsportal. U moet een OAuth 2.0-server toevoegen aan uw API Management-exemplaar en OAuth 2.0-autorisatie-instellingen inschakelen in de API. Zie De testconsole van de ontwikkelaarsportal autoriseren door OAuth 2.0-gebruikersautorisatie te configureren voor meer informatie.

Voorbeeld:

Tip

In het speciale geval wanneer API-toegang wordt beveiligd met behulp van Microsoft Entra ID, kunt u het beleid validate-azure-ad-token configureren voor tokenvalidatie.

Scenario 2: client-app autoriseert aan API Management

In dit scenario fungeert de API Management-service namens de API en vraagt de aanroepende toepassing om toegang tot het API Management-exemplaar. Het bereik van het toegangstoken is tussen de aanroepende toepassing en de API Management-gateway. Configureer in API Management een beleid (validate-jwt of validate-azure-ad-token) om het token te valideren voordat de gateway de aanvraag doorgeeft aan de back-end. Een afzonderlijk mechanisme beveiligt doorgaans de verbinding tussen de gateway en de back-end-API.

In het volgende voorbeeld is Microsoft Entra-id opnieuw de autorisatieprovider en beveiligt wederzijdse TLS-verificatie (mTLS) de verbinding tussen de gateway en de back-end.

Diagram met OAuth-communicatie waarbij de doelgroep de API Management-gateway is.

Er zijn verschillende redenen om dit te doen. Voorbeeld:

  • De back-end is een verouderde API die niet kan worden bijgewerkt ter ondersteuning van OAuth

    API Management moet eerst worden geconfigureerd om het token te valideren (minimaal de verlener en doelgroepclaims te controleren). Gebruik na validatie een van de verschillende opties die beschikbaar zijn voor het beveiligen van verdere verbindingen vanuit API Management, zoals wederzijdse TLS-verificatie (mTLS). Zie Opties aan de servicezijde verderop in dit artikel.

  • De context die door de back-end is vereist, is niet mogelijk om vanuit de aanroeper tot stand te brengen

    Nadat API Management het token heeft gevalideerd dat is ontvangen van de aanroeper, moet het vervolgens een toegangstoken voor de back-end-API verkrijgen met behulp van een eigen context of context die is afgeleid van de aanroepende toepassing. Dit scenario kan worden uitgevoerd met behulp van:

    • Een aangepast beleid, zoals send-request , om een hoger toegangstoken te verkrijgen dat geldig is voor de back-end-API van een geconfigureerde id-provider.

    • De eigen identiteit van het API Management-exemplaar: het token wordt doorgegeven vanuit de door het systeem toegewezen of door de gebruiker toegewezen beheerde identiteit van de API Management-resource aan de back-end-API.

  • De organisatie wil een gestandaardiseerde autorisatiebenadering aannemen

    Ongeacht de verificatie- en autorisatiemechanismen op hun API-back-ends, kunnen organisaties ervoor kiezen om te convergeren op OAuth 2.0 voor een gestandaardiseerde autorisatiebenadering op de front-end. De gateway van API Management kan consistente autorisatieconfiguratie en een algemene ervaring voor API-consumenten mogelijk maken naarmate de back-ends van de organisatie zich ontwikkelen.

Scenario 3: API Management autoriseert de back-end

Met beheerde verbindingen (voorheen autorisaties genoemd) gebruikt u referentiebeheer in API Management om toegang te verlenen tot een of meer back-end- of SaaS-services, zoals LinkedIn, GitHub of andere met OAuth 2.0 compatibele back-ends. In dit scenario doet een gebruiker of client-app een aanvraag naar de API Management-gateway, waarbij gatewaytoegang wordt beheerd met behulp van een id-provider of andere opties aan de clientzijde. Via beleidsconfiguratie delegeert de gebruiker of client-app vervolgens back-endverificatie en -autorisatie naar API Management.

In het volgende voorbeeld wordt een abonnementssleutel gebruikt tussen de client en de gateway en is GitHub de referentieprovider voor de back-end-API.

Diagram van autorisatie voor back-end SaaS-service met behulp van een verbinding die wordt beheerd in referentiebeheer.

Met een verbinding met een referentieprovider verkrijgt EN vernieuwt API Management de tokens voor API-toegang in de OAuth 2.0-stroom. Verbinding maken ies vereenvoudigen tokenbeheer in meerdere scenario's, zoals:

  • Een client-app moet mogelijk autoriseren voor meerdere SaaS-back-ends om meerdere velden op te lossen met behulp van GraphQL-resolvers.
  • Gebruikers verifiëren bij API Management by SSO van hun id-provider, maar autoriseren een back-end SaaS-provider (zoals LinkedIn) met behulp van een gemeenschappelijk organisatieaccount.
  • Een client-app (of bot) moet namens een geverifieerde gebruiker toegang krijgen tot beveiligde back-endbronnen (bijvoorbeeld e-mailberichten controleren of een bestelling plaatsen).

Voorbeelden:

Andere opties voor het beveiligen van API's

Hoewel autorisatie de voorkeur heeft en OAuth 2.0 de dominante methode is geworden voor het inschakelen van sterke autorisatie voor API's, biedt API Management verschillende andere mechanismen om de toegang tussen client en gateway (clientzijde) of tussen gateway en back-end (servicezijde) te beveiligen of te beperken. Afhankelijk van de vereisten van de organisatie kunnen deze worden gebruikt om OAuth 2.0 aan te vullen. U kunt ze ook onafhankelijk configureren als de aanroepende toepassingen of back-end-API's verouderd zijn of nog geen ondersteuning bieden voor OAuth 2.0.

Opties aan clientzijde

Mechanisme Beschrijving Overwegingen
mTLS Certificaat valideren dat wordt gepresenteerd door de client die verbinding maakt en certificaateigenschappen controleert op basis van een certificaat dat wordt beheerd in API Management Het certificaat kan worden opgeslagen in een sleutelkluis.
Ip-adressen van bellers beperken Filter aanroepen van specifieke IP-adressen of adresbereiken (toestaan/weigeren). Gebruik dit om de toegang tot bepaalde gebruikers of organisaties te beperken of om verkeer van upstream-services te beperken.
Abonnementssleutel Toegang tot een of meer API's beperken op basis van een API Management-abonnement U wordt aangeraden naast een andere verificatie- of autorisatiemethode een abonnementssleutel (API) te gebruiken. Een eigen abonnementssleutel is geen sterke vorm van verificatie, maar het gebruik van de abonnementssleutel kan nuttig zijn in bepaalde scenario's, bijvoorbeeld het bijhouden van het API-gebruik van afzonderlijke klanten of het verlenen van toegang tot specifieke API-producten.

Tip

Voor diepgaande verdediging wordt het implementeren van een webtoepassingsfirewall upstream van het API Management-exemplaar sterk aanbevolen. Gebruik bijvoorbeeld Azure-toepassing Gateway of Azure Front Door.

Opties aan de servicezijde

Mechanisme Beschrijving Overwegingen
Verificatie van beheerde identiteit Verifiëren bij back-end-API met een door het systeem toegewezen of door de gebruiker toegewezen beheerde identiteit. Aanbevolen voor bereiktoegang tot een beveiligde back-endresource door een token te verkrijgen van Microsoft Entra-id.
Certificaatverificatie Verifiëren bij back-end-API met behulp van een clientcertificaat. Het certificaat kan worden opgeslagen in de sleutelkluis.
Basisverificatie Verifiëren bij back-end-API met gebruikersnaam en wachtwoord die worden doorgegeven via een autorisatieheader. Afgeraden als er betere opties beschikbaar zijn.

Volgende stappen