OAuth 2.0-verbindingen in referentiebeheer - procesdetails en stromen

VAN TOEPASSING OP: Alle API Management-lagen

Dit artikel bevat informatie over de processtromen voor het beheren van OAuth 2.0-verbindingen met behulp van referentiebeheer in Azure API Management. De processtromen zijn onderverdeeld in twee delen: beheer en runtime.

Zie Referentiebeheer en API-referenties in API Management voor achtergrondinformatie over referentiebeheer en API-referenties in API Management.

Beheer van verbindingen

Het beheergedeelte van verbindingen in referentiebeheer zorgt voor het instellen en configureren van een referentieprovider voor OAuth 2.0-tokens, het inschakelen van de toestemmingsstroom voor de provider en het instellen van een of meer verbindingen met de referentieprovider voor toegang tot de referenties.

In de volgende afbeelding ziet u een overzicht van de processtroom voor het maken van een verbinding in API Management die gebruikmaakt van het toekenningstype autorisatiecode.

Diagram met de processtroom voor het maken van referenties.

Stap Omschrijving
1 Client verzendt een aanvraag om een referentieprovider te maken
2 De referentieprovider wordt gemaakt en er wordt een antwoord teruggestuurd
3 Client verzendt een aanvraag om een verbinding te maken
4 Verbinding maken wordt gemaakt en er wordt een antwoord teruggestuurd met de informatie dat de verbinding niet 'verbonden' is
5 Client verzendt een aanvraag om een aanmeldings-URL op te halen om de OAuth 2.0-toestemming te starten bij de referentieprovider. De aanvraag bevat een omleidings-URL die in de laatste stap moet worden gebruikt
6 Antwoord wordt geretourneerd met een aanmeldings-URL die moet worden gebruikt om de toestemmingsstroom te starten.
7 Client opent een browser met de aanmeldings-URL die in de vorige stap is opgegeven. De browser wordt omgeleid naar de OAuth 2.0-toestemmingsstroom van de referentieprovider
8 Nadat de toestemming is goedgekeurd, wordt de browser omgeleid met een autorisatiecode naar de omleidings-URL die is geconfigureerd bij de referentieprovider
9 API Management gebruikt de autorisatiecode om toegangs- en vernieuwingstokens op te halen
10 API Management ontvangt de tokens en versleutelt ze
11 API Management wordt omgeleid naar de opgegeven URL vanuit stap 5

Referentieprovider

Wanneer u uw referentieprovider configureert, kunt u kiezen tussen verschillende OAuth-providers en typen verlenen (autorisatiecode of clientreferenties). Voor elke provider zijn specifieke configuraties vereist. Belangrijke dingen om rekening mee te houden:

  • Een configuratie van een referentieprovider kan slechts één toekenningstype hebben.
  • De configuratie van één referentieprovider kan meerdere verbindingen hebben.

Notitie

Met de Generic OAuth 2.0-provider kunnen andere id-providers die de standaarden van de OAuth 2.0-stroom ondersteunen, worden gebruikt.

Wanneer u een referentieprovider configureert, maakt referentiebeheer achter de schermen een referentiearchief dat wordt gebruikt om de OAuth 2.0-toegangstokens van de provider in de cache op te slaan en tokens te vernieuwen.

Verbinding maken ion naar een referentieprovider

Voor toegang tot tokens voor een provider hebben client-apps een verbinding met de referentieprovider nodig. Een bepaalde verbinding is toegestaan door toegangsbeleid op basis van Microsoft Entra ID-identiteiten. U kunt meerdere verbindingen voor een provider configureren.

Het proces voor het configureren van een verbinding verschilt op basis van de geconfigureerde toekenning en is specifiek voor de configuratie van de referentieprovider. Als u bijvoorbeeld Microsoft Entra-id wilt configureren voor het gebruik van beide toekenningstypen, zijn er twee configuraties van de referentieprovider nodig. De volgende tabel bevat een overzicht van de twee toekenningstypen.

Toekenningstype Beschrijving
Autorisatiecode Afhankelijk van een gebruikerscontext, wat betekent dat een gebruiker toestemming moet geven voor de verbinding. Zolang het vernieuwingstoken geldig is, kan API Management nieuwe toegangs- en vernieuwingstokens ophalen. Als het vernieuwingstoken ongeldig wordt, moet de gebruiker opnieuw worden geverifieerd. Alle referentieproviders ondersteunen autorisatiecode. Meer informatie
Clientreferenties Is niet gebonden aan een gebruiker en wordt vaak gebruikt in toepassings-naar-toepassingsscenario's. Er is geen toestemming vereist voor het verlenen van clientreferenties en de verbinding wordt niet ongeldig. Meer informatie

Voor verbindingen op basis van het type autorisatiecodetoekenning moet u zich verifiëren bij de provider en toestemming geven voor autorisatie. Na een geslaagde aanmelding en autorisatie door de referentieprovider retourneert de provider geldige toegangs- en vernieuwingstokens, die zijn versleuteld en opgeslagen door API Management.

Toegangsbeleid

U configureert een of meer toegangsbeleidsregels voor elke verbinding. Het toegangsbeleid bepaalt welke Microsoft Entra ID-identiteiten tijdens runtime toegang kunnen krijgen tot uw referenties. Verbinding maken ions bieden momenteel ondersteuning voor toegang met behulp van service-principals, de identiteit, gebruikers en groepen van uw API Management-exemplaar.

Identiteit Beschrijving Vergoedingen Overwegingen
Service-principal Identiteit waarvan tokens kunnen worden gebruikt om te verifiëren en toegang te verlenen tot specifieke Azure-resources wanneer een organisatie Gebruikmaakt van Microsoft Entra-id. Door een service-principal te gebruiken, vermijden organisaties het maken van fictieve gebruikers om verificatie te beheren wanneer ze toegang nodig hebben tot een resource. Een service-principal is een Microsoft Entra-identiteit die een geregistreerde Microsoft Entra-toepassing vertegenwoordigt. Hiermee kunt u nauwer toegang krijgen tot verbindings- en gebruikersdelegeringsscenario's. Is niet gekoppeld aan een specifiek API Management-exemplaar. Is afhankelijk van Microsoft Entra ID voor het afdwingen van machtigingen. Voor het ophalen van de autorisatiecontext is een Microsoft Entra ID-token vereist.
Beheerde identiteit <Your API Management instance name> Deze optie komt overeen met een beheerde identiteit die is gekoppeld aan uw API Management-exemplaar. Standaard wordt toegang verleend aan de door het systeem toegewezen beheerde identiteit voor het bijbehorende API Management-exemplaar. Identiteit is gekoppeld aan uw API Management-exemplaar. Iedereen met inzendertoegang tot het API Management-exemplaar heeft toegang tot elke verbinding die machtigingen voor beheerde identiteiten verleent.
Gebruikers of groepen Gebruikers of groepen in uw Microsoft Entra ID-tenant. Hiermee kunt u de toegang beperken tot specifieke gebruikers of groepen gebruikers. Vereist dat gebruikers een Microsoft Entra ID-account hebben.

Runtime van verbindingen

Voor het runtime-onderdeel moet een back-end-OAuth 2.0-API worden geconfigureerd met het get-authorization-context beleid. Tijdens runtime haalt het beleid toegangs- en vernieuwingstokens op uit het referentiearchief dat API Management heeft ingesteld voor de provider. Wanneer een aanroep binnenkomt in API Management en het get-authorization-context beleid wordt uitgevoerd, wordt eerst gevalideerd of het bestaande autorisatietoken geldig is. Als het autorisatietoken is verlopen, gebruikt API Management een OAuth 2.0-stroom om de opgeslagen tokens van de referentieprovider te vernieuwen. Vervolgens wordt het toegangstoken gebruikt om toegang tot de back-endservice te autoriseren.

Tijdens de uitvoering van het beleid wordt de toegang tot de tokens ook gevalideerd met behulp van toegangsbeleid.

In de volgende afbeelding ziet u een voorbeeldprocesstroom voor het ophalen en opslaan van autorisatie- en vernieuwingstokens op basis van een verbinding die gebruikmaakt van het type autorisatiecodetoekenning. Nadat de tokens zijn opgehaald, wordt er een aanroep uitgevoerd naar de back-end-API.

Diagram met de processtroom voor het ophalen van tokens tijdens runtime.

Stap Omschrijving
1 Client verzendt een aanvraag naar het API Management-exemplaar
2 Het get-authorization-context beleid controleert of het toegangstoken geldig is voor de huidige verbinding
3 Als het toegangstoken is verlopen, maar het vernieuwingstoken geldig is, probeert API Management nieuwe toegangs- en vernieuwingstokens op te halen van de geconfigureerde referentieprovider
4 De referentieprovider retourneert zowel een toegangstoken als een vernieuwingstoken, dat is versleuteld en opgeslagen in API Management
5 Nadat de tokens zijn opgehaald, wordt het toegangstoken gekoppeld met behulp van het set-header beleid als autorisatieheader voor de uitgaande aanvraag naar de back-end-API
6 Antwoord wordt geretourneerd naar API Management
7 Antwoord wordt geretourneerd aan de client