Anropa ett API från ett annat API

Hur ser du som utvecklare till Nolltillit 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 skulle granska anspråket för ämne (under) eller objekt-ID (oid) och klient-ID (tid) i åtkomsttoken som appen tillhandahåller när api:et anropas. API:et skulle inte förlita sig på den ej betrodda appen, vilket bara är ett anrop som kommer från någonstans i nätverket. I stället validerar 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 det API som vi anropar (vi kallar det underordnade API:et) följer den valideringsprocess som beskrivs ovan. 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 skulle det ursprungliga API:et bli den enda auktoritet som användarna kan uppnå, vilket resulterar mot api:et downstream. Det ursprungliga API:et kan avsiktligt (eller oavsiktligt) tillåta en användare att utföra en uppgift som användaren annars inte kunde 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.

Klientappen hämtar åtkomsttoken för att anropa ursprungligt API

Följande diagram visar klientappen och det ursprungliga API:et.

Diagramrubrik: Klientappen hämtade en åtkomsttoken för att anropa det ursprungliga API:et. Diagramrubrik: Klientprogrammet har en åtkomsttoken "A" som gör att den kan fungera för användaren som identifieras i token för att anropa det ursprungliga API:et.

Klientprogrammet förvärvade en delegerad behörighetsåtkomsttoken (som anges av pentagonformen med etiketten "A") 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.

Klientappen ger åtkomsttoken till det ursprungliga API:et

Följande animering visar klientappen som 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.

Det animerade diagrammet visar två diagram med en rörelseövergång mellan det första diagrammet och det andra diagrammet. Första diagramrubriken: Klientappen hämtade en åtkomsttoken för att anropa det ursprungliga API:et. Första diagramrubriken: Klientprogrammet har en åtkomsttoken "A" som gör att den kan fungera för användaren som identifieras i token för att anropa det ursprungliga API:et. Andra diagramrubriken: Klientappen ger åtkomsttoken till det ursprungliga API:et.

Det ursprungliga API:et utför tokenverifiering och tillämpning

Nästa animering visar att 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.

Det animerade diagrammet visar två diagram med en rörelseövergång mellan det första diagrammet och det andra diagrammet. Första diagramrubriken: Klientappen ger åtkomsttoken till det ursprungliga API:et. Andra diagramrubriken: Det ursprungliga API:et utför tokenverifiering och tillämpning. Om allt är bra fortsätter API:et och servar begäran.

Det ursprungliga API:et kan inte använda åtkomsttoken för att anropa nedströms-API

Följande animering visar att det ursprungliga API:et nu vill anropa ett underordnade API. Det ursprungliga API:et kan dock inte använda åtkomsttoken för att anropa underordnade API:et.

Det animerade diagrammet visar två diagram med en rörelseövergång mellan det första diagrammet och det andra diagrammet. Första diagramrubriken: Det ursprungliga API:et vill anropa ett underordnade API. Andra diagramrubriken: Det ursprungliga API:et kan inte använda token för att anropa api:et downstream.

Ursprungligt API går tillbaka till Microsoft Entra-ID

I följande animering måste det ursprungliga API:et 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 animerade diagrammet visar två diagram med en rörelseövergång mellan det första diagrammet och det andra diagrammet. Första diagramrubriken: Det ursprungliga API:et kan inte använda token för att anropa underordnade API:et. Andra diagramrubriken: Ursprungligt API går tillbaka till Microsoft Entra-ID. Andra diagramrubriken: Behöver en åtkomsttoken för att anropa api:et för nedströms för användarens räkning.

Nästa animering visar det ursprungliga API:et som tillhandahåller den token som det ursprungliga API:et tog emot från klientappen och det ursprungliga API:ets klientautentiseringsuppgifter.

Det animerade diagrammet visar två diagram med en rörelseövergång mellan det första diagrammet och det andra diagrammet. Första diagramrubriken: Det ursprungliga API:et återgår till Microsoft Entra-ID. Underrubrik för första diagrammet: Behöver en åtkomsttoken för att anropa underordnade API:et för användarens räkning. Andra diagramrubriken: Ursprungligt API går tillbaka till Microsoft Entra-ID. Andra diagramrubriken: Innehåller token från klientappen och autentiseringsuppgifterna för det ursprungliga API:et.

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 anspråksutmaningsprocess för att gå tillbaka till det anropande programmet med information om att samtycke inte tas emot (till exempel att vara relaterat till principer för villkorlig åtkomst).

Microsoft Entra ID utför kontroller

I följande animering utför Microsoft Entra ID sina kontroller. 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.

Det animerade diagrammet visar två diagram med en rörelseövergång mellan det första diagrammet och det andra diagrammet. Första diagramrubriken: Det ursprungliga API:et återgår till Microsoft Entra-ID. Första diagramrubriken: Innehåller token från klientappen och autentiseringsuppgifterna för det ursprungliga API:et. Andra diagramrubriken: Microsoft Entra-ID kontrollerar villkorlig åtkomst, medgivande osv. Andra diagramrubriken: Det ursprungliga API:et tar emot en egen åtkomsttoken för att anropa api:et nedströms för användaren som loggade in på klientappen.

Det ursprungliga API:et har användarkontext med on-behalf-of-flöde

Följande animering illustrerar OBO-processen (On-Behalf-Of Flow ) som gör att ett API kan fortsätta att ha användarkontexten när den anropar nedströms-API.

Det animerade diagrammet visar två diagram med en rörelseövergång mellan det första diagrammet och det andra diagrammet. Första diagramrubriken: Med flödesprocessen Å-Behalf-Of kan det ursprungliga API:et fortsätta att ha användarkontext när det anropar underordnade API:et. Andra diagramrubriken: Med flödesprocessen Å-Behalf-Of kan det ursprungliga API:et fortsätta att ha användarkontext när det anropar api:et för nedströms.

Ursprungliga API-anrop nedströms-API

I nästa animering anropar vi api:et downstream. Den token som api:et för nedströms tar emot har rätt målgruppsanspråk (aud) som anger api:et underordnad.

Det animerade diagrammet visar två diagram med en rörelseövergång mellan det första diagrammet och det andra diagrammet. Första diagramrubriken: Med flödesprocessen Å-Behalf-Of kan det ursprungliga API:et fortsätta att ha användarkontext när det anropar underordnade API:et. Andra diagramrubriken: Underordnade API:et anropas. Andra diagramrubriken: Den token som api:et underordnat har rätt anspråk för att identifiera användaren av klientappen.

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

Den senaste animeringen visar att 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.

Det animerade diagrammet visar två diagram med en rörelseövergång mellan det första diagrammet och det andra diagrammet. Första diagramrubriken: Underordnade API:et anropas. Underrubrik för första diagrammet: Den token som api:et underordnat har rätt anspråk för att identifiera användaren av klientappen. Andra diagramrubriken: Det bästa alternativet är att det ursprungliga API:et utför "för flödets räkning". 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

• Microsofts identitetsplattform autentiseringsflöden och 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 Nolltillit 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. Den förklarar hur du anpassar token för att förbättra flexibiliteten och kontrollen samtidigt som du ökar säkerheten för program utan förtroende med minsta möjliga behörighet.
• 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 (används för implicita flöden), certifikat och hemligheter, program-ID-URI och programägarskap.
• Microsofts identitetsplattform autentiseringsbibliotek beskriver microsofts autentiseringsbiblioteksstöd för olika programtyper.