Een API aanroepen vanuit een andere API

Hoe zorgt u, als ontwikkelaar, voor Zero Trust wanneer u één API hebt die een andere API moet aanroepen? In dit artikel leert u hoe u uw toepassing veilig kunt ontwikkelen wanneer deze namens een gebruiker werkt.

Wanneer een gebruiker de gebruikersinterface van een app aanstuurt, kan de app een gedelegeerde machtiging gebruiken, zodat de API weet welke gebruiker namens de app werkt. Het inspecteert de claim van het onderwerp (sub) of de object-id (oid) en de tenant-id (tid) in het toegangstoken dat de app biedt bij het aanroepen van de API. De API zou niet afhankelijk zijn van de niet-vertrouwde app. Dit is slechts een aanroep die ergens in het netwerk afkomstig is. In plaats daarvan wordt het token gevalideerd om ervoor te zorgen dat de API alleen werkt namens de app-gebruiker die door Microsoft Entra ID is geverifieerd.

Wanneer de ene API (we verwijzen ernaar als de oorspronkelijke API) een andere API aanroept, is het essentieel dat de API die we aanroepen (we verwijzen ernaar als de Downstream-API) het hierboven beschreven validatieproces volgt. De downstream-API kan niet vertrouwen op een niet-vertrouwde netwerkbron. De gebruikersidentiteit moet worden opgehaald uit een correct gevalideerd toegangstoken.

Als de downstream-API niet het juiste validatieproces volgt, moet de downstream-API afhankelijk zijn van de oorspronkelijke API om de identiteit van de gebruiker op een andere manier op te geven. De downstream-API gebruikt mogelijk onjuist een toepassingsmachtiging om de bewerking uit te voeren. Vervolgens wordt de oorspronkelijke API de enige autoriteit waarmee gebruikers resultaten kunnen bereiken op basis van de downstream-API. Met de oorspronkelijke API kan een gebruiker opzettelijk (of onbedoeld) een taak uitvoeren die de gebruiker anders niet kon uitvoeren. Eén gebruiker kan bijvoorbeeld de details van een andere gebruiker wijzigen of documenten lezen en bijwerken die de gebruiker niet heeft gemachtigd om toegang te krijgen. Onjuiste validatie kan ernstige beveiligingsproblemen veroorzaken.

Voor betere beveiliging verkrijgt de oorspronkelijke API een gedelegeerd toegangstoken voor machtigingen dat aan de downstream-API wordt verstrekt wanneer de oorspronkelijke API de aanroep doet. Laten we eens bekijken hoe dit werkt.

Client-app verkrijgt toegangstoken om de oorspronkelijke API aan te roepen

In het volgende diagram ziet u de client-app en de oorspronkelijke API.

Diagramtitel: De client-app heeft een toegangstoken verkregen om de oorspronkelijke API aan te roepen. Subtitel diagram: De clienttoepassing heeft een toegangstoken 'A' waarmee het kan werken namens de gebruiker die is geïdentificeerd in het token om de oorspronkelijke API aan te roepen.

De clienttoepassing heeft een gedelegeerde machtigingstoegangstoken verkregen (aangegeven door de vijfhoekshape met het label A) aan de oorspronkelijke API. Met het gedelegeerde machtigingstoegangstoken kan het namens de gebruiker werken om de oorspronkelijke API aan te roepen waarvoor autorisatie is vereist.

Client-app geeft toegangstoken aan de oorspronkelijke API

In de volgende animatie ziet u de client-app die het toegangstoken aan de oorspronkelijke API geeft. De oorspronkelijke API valideert en inspecteert het toegangstoken volledig om de identiteit van de gebruiker van de client-app te bepalen.

Het animatiediagram toont twee diagrammen met een bewegingsovergang tussen het eerste diagram en het tweede diagram. Eerste diagramtitel: De client-app heeft een toegangstoken verkregen om de oorspronkelijke API aan te roepen. Eerste diagramondertitel: De clienttoepassing heeft een toegangstoken 'A' waarmee het kan werken namens de gebruiker die is geïdentificeerd in het token om de oorspronkelijke API aan te roepen. Tweede diagramtitel: De client-app geeft het toegangstoken aan de oorspronkelijke API.

De oorspronkelijke API voert tokenvalidatie en afdwinging uit

In de volgende animatie ziet u dat nadat de client-app het toegangstoken aan de oorspronkelijke API heeft opgegeven, de oorspronkelijke API tokenvalidatie en afdwinging uitvoert. Als alles goed is, wordt de API voortgezet en wordt de aanvraag voor de client-app verwerkt.

Het animatiediagram toont twee diagrammen met een bewegingsovergang tussen het eerste diagram en het tweede diagram. Titel van het eerste diagram: De client-app geeft het toegangstoken aan de oorspronkelijke API. Tweede diagramtitel: De oorspronkelijke API voert tokenvalidatie en afdwinging uit. Als alles goed is, wordt de API voortgezet en wordt de aanvraag verwerkt.

De oorspronkelijke API kan geen toegangstoken gebruiken om downstream-API aan te roepen

In de volgende animatie ziet u dat de oorspronkelijke API nu een downstream-API wil aanroepen. De oorspronkelijke API kan het toegangstoken echter niet gebruiken om de downstream-API aan te roepen.

Het animatiediagram toont twee diagrammen met een bewegingsovergang tussen het eerste diagram en het tweede diagram. Titel van het eerste diagram: de oorspronkelijke API wil een downstream-API aanroepen. Tweede diagramtitel: de oorspronkelijke API kan het token niet gebruiken om de downstream-API aan te roepen.

Oorspronkelijke API gaat terug naar Microsoft Entra-id

In de volgende animatie moet de Oorspronkelijke API teruggaan naar De Microsoft Entra-id. Er is een toegangstoken nodig om de downstream-API namens de gebruiker aan te roepen.

Het animatiediagram toont twee diagrammen met een bewegingsovergang tussen het eerste diagram en het tweede diagram. Eerste diagramtitel: de oorspronkelijke API kan het token niet gebruiken om de downstream-API aan te roepen. Tweede diagramtitel: De oorspronkelijke API gaat terug naar Microsoft Entra-id. Tweede diagramondertitel: Heeft een toegangstoken nodig om de downstream-API namens de gebruiker aan te roepen.

In de volgende animatie ziet u de oorspronkelijke API die het token opgeeft dat de oorspronkelijke API heeft ontvangen van de client-app en de clientreferenties van de oorspronkelijke API.

Het animatiediagram toont twee diagrammen met een bewegingsovergang tussen het eerste diagram en het tweede diagram. Titel van eerste diagram: de oorspronkelijke API gaat terug naar Microsoft Entra-id. Eerste diagramondertitel: Heeft een toegangstoken nodig om de downstream-API namens de gebruiker aan te roepen. Tweede diagramtitel: De oorspronkelijke API gaat terug naar Microsoft Entra-id. Tweede diagramondertitel: Biedt het token van de client-app en de referenties voor de oorspronkelijke API.

Microsoft Entra ID controleert op zaken zoals het afdwingen van toestemming of voorwaardelijke toegang. Mogelijk moet u teruggaan naar uw aanroepende client en een reden opgeven om het token niet te kunnen ophalen. Normaal gesproken gebruikt u een claimvraagproces om terug te gaan naar de aanroepende toepassing met informatie over het niet ontvangen van toestemming (zoals gerelateerd aan beleid voor voorwaardelijke toegang).

Microsoft Entra ID voert controles uit

In de volgende animatie voert Microsoft Entra ID de controles uit. Als alles in orde is, geeft Microsoft Entra ID een toegangstoken uit aan de oorspronkelijke API om de downstream-API namens de gebruiker aan te roepen.

Het animatiediagram toont twee diagrammen met een bewegingsovergang tussen het eerste diagram en het tweede diagram. Titel van eerste diagram: de oorspronkelijke API gaat terug naar Microsoft Entra-id. Eerste diagramondertitel: biedt het token van de client-app en de referenties voor de oorspronkelijke API. Tweede diagramtitel: Microsoft Entra ID controleert voorwaardelijke toegang, toestemming, enzovoort. Tweede diagramondertitel: De oorspronkelijke API ontvangt een eigen toegangstoken om de downstream-API aan te roepen namens de gebruiker die zich heeft aangemeld bij de client-app.

De oorspronkelijke API heeft gebruikerscontext met on-Behalf-Of-stroom

De volgende animatie illustreert het OBO-proces (On-Behalf-Of flow ) waarmee een API de gebruikerscontext kan blijven gebruiken terwijl downstream-API wordt aangeroepen.

Het animatiediagram toont twee diagrammen met een bewegingsovergang tussen het eerste diagram en het tweede diagram. Titel van het eerste diagram: Met het proces On-Behalf-Of-Flow kan de oorspronkelijke API gebruikerscontext blijven hebben terwijl deze de downstream-API aanroept. Tweede diagramtitel: Met het proces On-Behalf-Of-Flow kan de oorspronkelijke API gebruikerscontext blijven hebben terwijl deze de downstream-API aanroept.

Oorspronkelijke API-aanroepen downstream-API

In de volgende animatie roepen we de Downstream-API aan. Het token dat de Downstream-API ontvangt, heeft de juiste doelgroepclaim (aud) die de downstream-API aangeeft.

Het animatiediagram toont twee diagrammen met een bewegingsovergang tussen het eerste diagram en het tweede diagram. Titel van het eerste diagram: Met het proces On-Behalf-Of-Flow kan de oorspronkelijke API gebruikerscontext blijven hebben terwijl deze de downstream-API aanroept. Tweede diagramtitel: De downstream-API wordt aangeroepen. Tweede diagramondertitel: het token dat de downstream-API ontvangt, heeft de juiste claims om de gebruiker van de client-app te identificeren.

Het token bevat de bereiken voor verleende toestemming en de oorspronkelijke app-gebruikersidentiteit. De downstream-API kan effectieve machtigingen implementeren om ervoor te zorgen dat de geïdentificeerde gebruiker gemachtigd is om de aangevraagde taak uit te voeren. U wilt de namens de stroom gebruiken om tokens te verkrijgen voor een API om een andere API aan te roepen om ervoor te zorgen dat de gebruikerscontext wordt doorgegeven aan alle downstream-API's.

Beste optie: de oorspronkelijke API voert on-Behalf-Of-stroom uit

Deze laatste animatie laat zien dat de beste optie is voor de Oorspronkelijke API om On-Behalf-Of flow (OBO) uit te voeren. Als de downstream-API het juiste token ontvangt, kan deze correct reageren.

Het animatiediagram toont twee diagrammen met een bewegingsovergang tussen het eerste diagram en het tweede diagram. Eerste diagramtitel: De downstream-API wordt aangeroepen. Eerste diagramondertitel: het token dat de downstream-API ontvangt, heeft de juiste claims om de gebruiker van de client-app te identificeren. Tweede diagramtitel: De beste optie is dat de oorspronkelijke API 'namens stroom' wordt uitgevoerd. Als de downstream-API het juiste token ontvangt, kan deze correct reageren.

Wanneer een API namens een gebruiker optreedt en een andere API moet aanroepen, moet de API OBO gebruiken om een gedelegeerde machtigingstoken te verkrijgen om de Downstream-API namens de gebruiker aan te roepen. API's mogen nooit toepassingsmachtigingen gebruiken om downstream-API's aan te roepen wanneer de API namens een gebruiker handelt.

Volgende stappen

• Verificatiestromen en app-scenario's van Microsoft Identity Platform beschrijven verificatiestromen en de toepassingsscenario's waarin ze worden gebruikt.
• API Protection beschrijft aanbevolen procedures voor het beveiligen van uw API via registratie, het definiëren van machtigingen en toestemming en het afdwingen van toegang om uw Zero Trust-doelstellingen te bereiken.
• Voorbeeld van API die wordt beveiligd door het Microsoft Identity Consent Framework helpt u bij het ontwerpen van strategieën voor toepassingsmachtigingen met minimale bevoegdheden voor de beste gebruikerservaring.
• Tokens aanpassen beschrijft de informatie die u kunt ontvangen in Microsoft Entra-tokens. In dit artikel wordt uitgelegd hoe u tokens aanpast om de flexibiliteit en controle te verbeteren en tegelijkertijd de beveiliging van nul vertrouwensrelaties met minimale bevoegdheden te verhogen.
• In de module Beveiligde aangepaste API's met Microsoft Identity Learn wordt uitgelegd hoe u een web-API beveiligt met Microsoft-identiteit en hoe u deze kunt aanroepen vanuit een andere toepassing.
• Aanbevolen beveiligingsprocedures voor toepassingseigenschappen beschrijven omleidings-URI, toegangstokens (gebruikt voor impliciete stromen), certificaten en geheimen, de URI van de toepassings-id en het eigendom van de toepassing.
• Microsoft Identity Platform-verificatiebibliotheken beschrijft ondersteuning voor Microsoft Authentication Library voor verschillende toepassingstypen .