Tjänst-till-tjänst-appar

Tjänst-till-tjänst-program kan vara en daemon eller ett serverprogram som behöver hämta resurser från ett webb-API. Det finns två underscenarier som gäller för det här avsnittet:

• En daemon som måste anropa ett webb-API som bygger på tilldelningstypen OAuth 2.0-klientautentiseringsuppgifter

  I det här scenariot är det viktigt att förstå några saker. För det första är användarinteraktion inte möjligt med ett daemonprogram, vilket kräver att programmet har en egen identitet. Ett exempel på ett daemonprogram är ett batchjobb eller en operativsystemtjänst som körs i bakgrunden. Den här typen av program begär en åtkomsttoken med hjälp av dess programidentitet och presenterar dess program-ID, autentiseringsuppgifter (lösenord eller certifikat) och program-ID-URI för att Azure AD. Efter lyckad autentisering tar daemon emot en åtkomsttoken från Azure AD, som sedan används för att anropa webb-API:et.

• Ett serverprogram (till exempel ett webb-API) som behöver anropa ett webb-API som bygger på OAuth 2.0 On-Behalf-Of-utkastspecifikation

  I det här scenariot kan du tänka dig att en användare har autentiserats för ett inbyggt program och att det här inbyggda programmet måste anropa ett webb-API. Azure AD utfärdar en JWT-åtkomsttoken för att anropa webb-API:et. Om webb-API:et behöver anropa ett annat underordnat webb-API kan det använda flödet för att delegera användarens identitet och autentisera till webb-API:et på andra nivån.

Diagram

Protokollflöde

Programidentitet med OAuth 2.0-klientautentiseringsuppgifter

1. Först måste serverprogrammet autentiseras med Azure AD som sig själv, utan mänsklig interaktion, till exempel en interaktiv inloggningsdialogruta. Den skickar en begäran om att Azure AD tokenslutpunkt, med autentiseringsuppgifter, program-ID och program-ID-URI.
2. Azure AD autentiserar programmet och returnerar en JWT-åtkomsttoken som används för att anropa webb-API:et.
3. Via HTTPS använder webbprogrammet den returnerade JWT-åtkomsttoken för att lägga till JWT-strängen med en "ägarbeteckning" i auktoriseringshuvudet för begäran till webb-API:et. Webb-API:et verifierar sedan JWT-token och returnerar önskad resurs om valideringen lyckas.

Delegerad användaridentitet med OAuth 2.0 För utkastspecifikation

Flödet som beskrivs nedan förutsätter att en användare har autentiserats i ett annat program (till exempel ett internt program) och att deras användaridentitet har använts för att hämta en åtkomsttoken till webb-API:et på första nivån.

1. Det interna programmet skickar åtkomsttoken till webb-API:et på första nivån.
2. Webb-API:et på första nivån skickar en begäran till Azure AD tokenslutpunkt, med dess program-ID och autentiseringsuppgifter samt användarens åtkomsttoken. Dessutom skickas begäran med en on_behalf_of parameter som anger att webb-API:et begär nya token för att anropa ett underordnat webb-API för den ursprungliga användarens räkning.
3. Azure AD verifierar att webb-API:et på första nivån har behörighet att komma åt webb-API:et på andra nivån och verifierar begäran, returnerar en JWT-åtkomsttoken och en JWT-uppdateringstoken till webb-API:et på första nivån.
4. Via HTTPS anropar webb-API:et på första nivån webb-API:et på andra nivån genom att lägga till tokensträngen i auktoriseringshuvudet i begäran. Webb-API:et på den första nivån kan fortsätta att anropa webb-API:et på andra nivån så länge åtkomsttoken och uppdateringstoken är giltiga.

Kodexempel

Se kodexemplen för daemon- eller serverprogram till webb-API-scenarier: Server- eller daemonprogram till webb-API

Appregistrering

• Enskild klient – För både programidentitets- och delegerade användaridentitetsfall måste daemon- eller serverprogrammet registreras i samma katalog i Azure AD. Webb-API:et kan konfigureras för att exponera en uppsättning behörigheter som används för att begränsa daemonens eller serverns åtkomst till dess resurser. Om en delegerad användaridentitetstyp används måste serverprogrammet välja önskade behörigheter. På sidan API-behörighet för programregistreringen, när du har valt Lägg till en behörighet och valt API-familjen, väljer du Delegerade behörigheter och väljer sedan dina behörigheter. Det här steget krävs inte om programidentitetstypen används.
• Flera klientorganisationer – Först konfigureras daemon- eller serverprogrammet för att ange de behörigheter som krävs för att fungera. Den här listan över nödvändiga behörigheter visas i en dialogruta när en användare eller administratör i målkatalogen ger sitt medgivande till programmet, vilket gör det tillgängligt för organisationen. Vissa program kräver endast behörigheter på användarnivå, vilket alla användare i organisationen kan godkänna. Andra program kräver behörigheter på administratörsnivå som en användare i organisationen inte kan godkänna. Endast en katalogadministratör kan ge medgivande till program som kräver den här behörighetsnivån. När användaren eller administratören samtycker registreras båda webb-API:erna i deras katalog.

Förfallodatum för token

När det första programmet använder sin auktoriseringskod för att hämta en JWT-åtkomsttoken får det även en JWT-uppdateringstoken. När åtkomsttoken upphör att gälla kan uppdateringstoken användas för att autentisera användaren igen utan att fråga efter autentiseringsuppgifter. Den här uppdateringstoken används sedan för att autentisera användaren, vilket resulterar i en ny åtkomsttoken och uppdateringstoken.

Nästa steg

• Läs mer om andra programtyper och scenarier
• Lär dig mer om grunderna för Azure AD autentisering