Service-naar-service-apps

Waarschuwing

Deze inhoud is voor het oudere Azure AD v1.0-eindpunt. Gebruik het Microsoft Identity Platform voor nieuwe projecten.

Service-naar-servicetoepassingen kunnen daemon- of servertoepassingen zijn waarmee resources moeten worden opgehaald uit een web-API. Er zijn twee subscenario's van toepassing op deze sectie:

• Een daemon waarmee een web-API moet worden aangeroepen, gebouwd op basis van het toekenningstype OAuth 2.0-clientreferenties

  In dit scenario is het belangrijk om inzicht te hebben in een aantal zaken. Ten eerste is gebruikersinteractie niet mogelijk met een daemontoepassing, waardoor de toepassing een eigen identiteit moet hebben. Een voorbeeld van een daemontoepassing is een batchtaak of een besturingssysteemservice die op de achtergrond wordt uitgevoerd. Door dit type toepassingen wordt een toegangstoken aangevraagd met behulp van de toepassings-id en opgave bij Azure AD van de bijbehorende toepassings-id, referentie (wachtwoord of certificaat) en URI van de toepassings-id. Na een geslaagde verificatie ontvangt de daemon een toegangstoken van Azure AD, waarmee de web-API wordt aangeroepen.

• Een servertoepassing (zoals een web-API) waarmee een web-API moet worden aangeroepen, gebouwd op basis van de conceptspecificatie OAuth 2.0 On-Behalf-Of

  Stel dat een gebruiker in dit scenario is geverifieerd in een systeemeigen toepassing en dat deze systeemeigen toepassing een web-API moet aanroepen. In Azure AD wordt een JWT-toegangstoken uitgegeven om de web-API aan te roepen. Als vanuit de web-API een andere downstream-web-API moet worden aangeroepen, kan de On-Behalf-Of-stroom worden gebruikt om de identiteit van de gebruiker te delegeren en te verifiëren bij de web-API van de tweede laag.

Diagram

Protocolstroom

Toepassingsidentiteit met de toekenning OAuth 2.0-clientreferenties

1. Ten eerste moet de authenticiteit van de servertoepassing worden geverifieerd bij Azure AD, zonder menselijke interactie zoals een interactief aanmeldingsdialoogvenster. Vanuit de servertoepassing wordt een aanvraag ingediend bij het tokeneindpunt van Azure AD met opgave van de referenties, de toepassings-id en de URI van de toepassings-id.
2. In Azure AD wordt de toepassing geverifieerd en een JWT-toegangstoken geretourneerd om de web-API aan te roepen.
3. Via HTTPS wordt het geretourneerde JWT-toegangstoken gebruikt om de JWT-tekenreeks met de aanduiding Bearer toe te voegen aan de autorisatieheader van de aanvraag voor de web-API. In de web-API wordt vervolgens het JWT-token gevalideerd en als de validatie is geslaagd, wordt de gewenste resource geretourneerd.

Gedelegeerde gebruikersidentiteit met de conceptspecificatie OAuth 2.0 On-Behalf-Of

In de onderstaande stroom wordt ervan uitgegaan dat een gebruiker is geverifieerd in een andere toepassing (zoals een systeemeigen toepassing) en dat de gebruikersidentiteit is gebruikt om een toegangstoken te verkrijgen voor de web-API van de eerste laag.

1. Vanuit de systeemeigen toepassing wordt het toegangstoken verzonden naar de web-API van de eerste laag.
2. Vanuit de web-API van de eerste laag wordt een aanvraag verzonden naar het Azure AD-tokeneindpunt, waarbij de toepassings-id en referenties worden opgegeven, evenals het toegangstoken van de gebruiker. Verder wordt de aanvraag verzonden met een on_behalf_of-parameter die aangeeft dat vanuit de web-API nieuwe tokens worden aangevraagd om een downstream-web-API aan te roepen namens de oorspronkelijke gebruiker.
3. In Azure AD wordt gecontroleerd of de web-API van de eerste laag machtigingen heeft voor toegang tot de web-API van de tweede laag. Ook wordt de aanvraag gevalideerd en worden een JWT-toegangstoken en een JWT-vernieuwingstoken geretourneerd naar de web-API van de eerste laag.
4. Via HTTPS wordt door de web-API van de eerste laag vervolgens de web-API van de tweede laag aangeroepen door de tokentekenreeks toe te voegen aan de autorisatieheader in de aanvraag. Vanuit de web-API van de eerste laag kan de web-API van de tweede laag worden aanroepen zolang het toegangstoken en de vernieuwingstokens geldig zijn.

Codevoorbeelden

Bekijk de codevoorbeelden voor scenario's van daemon- of servertoepassingen naar web-API: Van server- of daemon-toepassing naar web-API

App-registratie

• Eén tenant: voor zowel de cases van de toepassings-id als de gedelegeerde gebruikersidentiteit moet de daemon- of servertoepassing worden geregistreerd in dezelfde map in Azure AD. De web-API kan worden geconfigureerd voor het beschikbaar maken van een set machtigingen om de toegang van de daemon of server tot de bijbehorende resources te beperken. Als het identiteitstype Gedelegeerde gebruiker wordt gebruikt, moeten de gewenste machtigingen worden geselecteerd in de servertoepassing. Ga naar de pagina API-machtiging voor de toepassingsregistratie. Nadat u Een machtiging toevoegen hebt geselecteerd en de API-familie hebt gekozen, kiest u Gedelegeerde machtigingen en selecteert u vervolgens uw machtigingen. Deze stap is niet vereist als het identiteitstype Toepassing wordt gebruikt.
• Multitenant: eerst wordt de daemon- of servertoepassing geconfigureerd om aan te geven welke machtigingen nodig zijn voor de functionaliteit ervan. Deze lijst met vereiste machtigingen wordt weergegeven in een dialoogvenster wanneer een gebruiker of beheerder in de doelmap toestemming geeft voor de toepassing, waardoor deze beschikbaar wordt gemaakt voor de organisatie. Voor sommige toepassingen zijn alleen machtigingen op gebruikersniveau vereist, waarvoor elke gebruiker in de organisatie toestemming kan geven. Voor andere toepassingen zijn machtigingen op beheerdersniveau vereist, waarvoor een gebruiker in de organisatie geen toestemming kan geven. Alleen een mapbeheerder kan toestemming geven voor toepassingen waarvoor dit machtigingsniveau is vereist. Wanneer de gebruiker of beheerder toestemming verleent, worden beide web-API's geregistreerd in de betreffende map.

Tokenverloop

Wanneer de autorisatiecode door de eerste toepassing wordt gebruikt om een JWT-toegangstoken op te halen, ontvangt deze toepassing ook een JWT-vernieuwingstoken. Wanneer het toegangstoken verloopt, kan het vernieuwingstoken worden gebruikt om de gebruiker opnieuw te verifiëren zonder om referenties te vragen. Dit vernieuwingstoken wordt vervolgens gebruikt om de gebruiker te verifiëren, wat resulteert in een nieuw toegangstoken en vernieuwingstoken.

Volgende stappen

• Meer informatie over andere toepassingstypen en scenario's
• Meer informatie over de basisbeginselen van de Azure AD-verificatie