Share via

Verificatie en autorisatie voor API's in Azure API Management

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 omvatten het beveiligen van de end-to-end communicatie van client-apps naar de API Management-gateway en via 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.

Important

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

Note

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

Verificatie versus autorisatie

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

  • Verificatie: het proces van het verifiëren van de identiteit 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 voor het bepalen of een gebruiker of app gemachtigd is voor toegang tot een bepaalde API, vaak via een op tokens gebaseerd protocol, zoals OAuth 2.0.

Note

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

OAuth 2.0-concepten

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

OAuth-proces

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 inloggegevens bij een identiteitsprovider.

  • 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 tokenverlener 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 presenteert het toegangstoken; 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. Lees meer over OAuth-stromen en toepassingsscenario's in Microsoft Entra ID.

OAuth 2.0-autorisatiescenario's in API-beheer

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 ligt 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, en weiger aanvragen die zonder een token of met een token komen 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.

Note

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.

Example:

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

    U moet eerst API Management configureren om het token te valideren (minimaal de uitgever en doelgroep claims 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 vervolgtoegangstoken te verkrijgen dat geldig is voor de backend-API van een geconfigureerde identiteitsprovider.

    • De identiteit van de API Management-instantie, waarbij het token wordt doorgegeven vanuit de door het systeem of door de gebruiker toegewezen beheerde identiteit van de API Management-resource aan de backend-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 credential provider verkrijgt en vernieuwt API Management de tokens voor API-toegang in de OAuth 2.0-flow. Verbindingen vereenvoudigen het beheer van tokens 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 authenticeren bij API Management via SSO van hun identiteitsprovider, maar verlenen autorisatie aan 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).

Examples:

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 voor het beveiligen of beperken van de toegang tussen client en gateway (clientzijde) of tussen gateway en back-end (servicezijde). Afhankelijk van de vereisten van de organisatie kunt u deze gebruiken 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

Mechanism Description Considerations
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 Certificaat kan worden opgeslagen in een sleutelkluis.
Ip-adressen van bellers beperken Filter (toestaan/weigeren) aanroepen van specifieke IP-adressen of adresbereiken. 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 abonnementssleutel is zelf 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 raden we u ten zeerste aan om een webtoepassingsfirewall upstream van het API Management-exemplaar te implementeren. Gebruik bijvoorbeeld Azure Application Gateway of Azure Front Door.

Opties aan de servicezijde

Mechanism Description Considerations
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 gescopeerde toegang tot een beveiligde back-endbron 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 een Key Vault.
Basisverificatie Verifiëren bij back-end-API met gebruikersnaam en wachtwoord die worden doorgegeven via een autorisatieheader. Afgeraden wanneer er veiligere authenticatieopties beschikbaar zijn (bijvoorbeeld beheerde identiteit, certificaten, inloggegevensbeheer). Als u deze optie kiest, gebruikt u benoemde waarden om referenties op te geven, met geheimen die zijn beveiligd in een sleutelkluis.

Verwante inhoud