Anropa ett API från ett annat API

Hur säkerställer du som utvecklare Zero Trust när du har ett API som behöver anropa ett annat API? I den här artikeln får du lära dig hur du på ett säkert sätt utvecklar ditt program när det fungerar för en användares räkning.

När en användare kör en apps användargränssnitt kan appen använda en delegerad behörighet så att API:et vet vilken användare för vars räkning appen fungerar. Den inspekterar ämnesanspråket (sub), objekt-ID (oid) och tenant-ID (tid) i åtkomsttokenet som appen tillhandahåller när API:et anropas. API:et förlitar sig inte på den ej betrodda appen, vilket bara är ett anrop som kommer från någonstans i nätverket. I stället verifierar den token för att säkerställa att API:et endast fungerar för den appanvändare som Microsoft Entra-ID:t har verifierat.

När ett API (vi refererar till det som det ursprungliga API:et) anropar ett annat är det viktigt att api:et som vi anropar (vi kallar det underordnade API:et) följer valideringsprocessen. Underordnade API:et kan inte förlita sig på en nätverkskälla som inte är betrodd. Den måste hämta användaridentiteten från en korrekt verifierad åtkomsttoken.

Om det underordnade API:et inte följer rätt valideringsprocess måste underordnade API:et förlita sig på det ursprungliga API:et för att tillhandahålla användarens identitet på ett annat sätt. Api:et för nedströms kan felaktigt använda en programbehörighet för att utföra åtgärden. Sedan blir det ursprungliga API:et den enda auktoriteten över vilka resultat användarna kan uppnå mot Downstream-API:et. Det ursprungliga API:et kan avsiktligt (eller oavsiktligt) tillåta en användare att utföra en uppgift som användaren annars inte kan utföra. En användare kan till exempel ändra information om en annan användare eller läsa och uppdatera dokument som användaren inte har behörighet att komma åt. Felaktig validering kan orsaka allvarliga säkerhetsproblem.

För bättre säkerhet hämtar det ursprungliga API:et en delegerad behörighetsåtkomsttoken som ska tillhandahållas till api:et nedströms när det ursprungliga API:et gör anropet. Låt oss gå igenom hur det här fungerar.

1. Klientappen hämtar åtkomsttoken för att anropa ursprungligt API. Klientprogrammet hämtar en delegerad behörighetsåtkomsttoken till det ursprungliga API:et. Den delegerade behörighetsåtkomsttoken gör att den kan fungera åt användaren för att anropa det ursprungliga API:et som kräver auktorisering.
2. Klientappen ger åtkomsttoken till det ursprungliga API:et. Klientappen ger åtkomsttoken till det ursprungliga API:et. Det ursprungliga API:et verifierar och inspekterar åtkomsttoken för att fastställa identiteten för klientappens användare.
3. Det ursprungliga API:et utför tokenverifiering och tillämpning. När klientappen ger åtkomsttoken till det ursprungliga API:et utför det ursprungliga API:et tokenverifiering och tvingande. Om allt är bra fortsätter API:et och skickar begäran för klientappen.
4. Det ursprungliga API:et kan inte använda åtkomsttoken för att anropa underordnade API:er. Det ursprungliga API:et vill anropa ett underordnade API. Det ursprungliga API:et kan dock inte använda åtkomsttoken för att anropa underordnade API:et.
5. Det ursprungliga API:et återgår till Microsoft Entra-ID. Det ursprungliga API:et måste gå tillbaka till Microsoft Entra-ID. Den behöver en åtkomsttoken för att anropa nedströms-API:et för användarens räkning. Det ursprungliga API:et tillhandahåller den token som det ursprungliga API:et tog emot från klientappen och det ursprungliga API:ets klientautentiseringsuppgifter.
6. Microsoft Entra ID utför kontroller. Microsoft Entra-ID söker efter saker som medgivande eller tillämpning av villkorsstyrd åtkomst. Du kan behöva gå tillbaka till den anropande klienten och ange en anledning till att inte kunna hämta token. Du använder vanligtvis en utmaningsprocess för anspråk för att gå tillbaka till det anropande programmet med information om att samtycke inte har mottagits (till exempel relaterat till villkorliga åtkomstprinciper). Om allt är okej utfärdar Microsoft Entra-ID en åtkomsttoken till det ursprungliga API:et för att anropa nedströms-API:et för användarens räkning.
7. Det ursprungliga API:et har användarkontext med on-Behalf-Of-flöde. Med OBO-processen (On-Behalf-Of flow ) kan ett API fortsätta att ha användarkontexten när den anropar underordnade API.
8. Det ursprungliga API:et anropar underordnade API:er. Anropa nedströms-API:et. Den token som api:et för nedströms tar emot har rätt målgruppsanspråk (aud) som anger api:et underordnad. Token innehåller omfången för beviljat medgivande och den ursprungliga appanvändaridentiteten. Underordnade API:et kan implementera effektiva behörigheter korrekt för att säkerställa att den identifierade användaren har behörighet att utföra den begärda uppgiften. Du vill använda för flödets räkning för att hämta token för ett API för att anropa ett annat API för att se till att användarkontexten skickas till alla underordnade API:er.

Bästa alternativet: Det ursprungliga API:et utför flödet För räkning

Det bästa alternativet är att det ursprungliga API:et utför OBO (On-Behalf-Of flow). Om api:et Downstream tar emot rätt token kan det svara korrekt. När ett API agerar för en användares räkning och behöver anropa ett annat API måste API:et använda OBO för att hämta en delegerad behörighetsåtkomsttoken för att anropa nedströms-API:et för användarens räkning. API:er bör aldrig använda programbehörigheter för att anropa underordnade API:er när API:et agerar för en användares räkning.

Nästa steg

• Autentiseringsflöden för Microsofts identitetsplattform & appscenarier beskriver autentiseringsflöden och de programscenarier där de används.
• API Protection beskriver metodtips för att skydda ditt API genom registrering, definiera behörigheter och medgivande samt framtvinga åtkomst för att uppnå dina Noll förtroende-mål.
• Exempel på API som skyddas av Microsofts ramverk för identitetsmedgivande hjälper dig att utforma strategier för programbehörigheter med lägsta behörighet för bästa användarupplevelse.
• Anpassa token beskriver den information som du kan ta emot i Microsoft Entra-token. Det förklarar hur du anpassar tokens för att förbättra flexibiliteten och kontrollen samtidigt som du ökar säkerheten för Zero Trust med minsta möjliga privilegium.
• Modulen Skydda anpassade API:er med Microsoft Identity Learn förklarar hur du skyddar ett webb-API med Microsoft-identitet och hur du anropar det från ett annat program.
• Metodtips för säkerhet för programegenskaper beskriver omdirigerings-URI, åtkomsttoken, certifikat och hemligheter, program-ID-URI och programägarskap.
• Microsofts autentiseringsbibliotek för identitetsplattform beskriver microsofts autentiseringsbiblioteksstöd för olika programtyper.