Share via

Systeemeigen apps

  • Artikel

Waarschuwing

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

Systeemeigen apps zijn toepassingen die namens een gebruiker een web-API aanroepen. Dit scenario is gebaseerd op het toekenningstype OAuth 2.0-autorisatiecode met een openbare client, zoals beschreven in sectie 4.1 van de OAuth 2.0-specificatie. De systeemeigen toepassing verkrijgt een toegangstoken voor de gebruiker met behulp van het OAuth 2.0-protocol. Dit toegangstoken wordt vervolgens in de aanvraag verzonden naar de web-API, die de gebruiker autoriseert en de gewenste resource retourneert.

Diagram

Diagram van systeemeigen toepassings-naar-web-API

Protocolstroom

Als u de AD-verificatiebibliotheken gebruikt, worden de meeste protocoldetails die hieronder worden beschreven, voor u afgehandeld, zoals de pop-up van de browser, het opslaan van tokens in de cache van tokens en het verwerken van vernieuwingstokens.

  1. Met behulp van een browserpop-up maakt de systeemeigen toepassing een aanvraag naar het autorisatie-eindpunt in Azure AD. Deze aanvraag omvat de toepassings-id en de omleidings-URI van de systeemeigen toepassing, zoals weergegeven in de Azure Portal, en de toepassings-id-URI voor de web-API. Als de gebruiker zich nog niet heeft aangemeld, wordt deze gevraagd zich opnieuw aan te melden
  2. Azure AD verifieert de gebruiker. Als het een toepassing met meerdere tenants is en toestemming is vereist om de toepassing te gebruiken, moet de gebruiker toestemming geven als deze dit nog niet heeft gedaan. Na het verlenen van toestemming en na een geslaagde verificatie geeft Azure AD een autorisatiecodeantwoord terug naar de omleidings-URI van de clienttoepassing.
  3. Wanneer Azure AD een autorisatiecode reageert op de omleidings-URI, stopt de clienttoepassing de browserinteractie en extraheert de autorisatiecode uit het antwoord. Met behulp van deze autorisatiecode verzendt de clienttoepassing een aanvraag naar het tokeneindpunt van Azure AD dat de autorisatiecode, details over de clienttoepassing (toepassings-id en omleidings-URI) en de gewenste resource (toepassings-id-URI voor de web-API) bevat.
  4. De autorisatiecode en informatie over de clienttoepassing en web-API worden gevalideerd door Azure AD. Na een geslaagde validatie retourneert Azure AD twee tokens: een JWT-toegangstoken en een JWT-vernieuwingstoken. Daarnaast retourneert Azure AD basisinformatie over de gebruiker, zoals de weergavenaam en tenant-id.
  5. Via HTTPS gebruikt de clienttoepassing het geretourneerde JWT-toegangstoken om de JWT-tekenreeks met de aanduiding Bearer toe te voegen in de autorisatieheader van de aanvraag aan de web-API. In de web-API wordt vervolgens het JWT-token gevalideerd en als de validatie is geslaagd, wordt de gewenste resource geretourneerd.
  6. Wanneer het toegangstoken verloopt, ontvangt de clienttoepassing een fout die aangeeft dat de gebruiker opnieuw moet worden geverifieerd. Als de toepassing een geldig vernieuwingstoken heeft, kan dit worden gebruikt om een nieuw toegangstoken te verkrijgen zonder dat de gebruiker zich opnieuw hoeft aan te melden. Als het vernieuwingstoken verloopt, moet de toepassing de gebruiker opnieuw interactief verifiëren.

Notitie

Het vernieuwingstoken dat door Azure AD is uitgegeven, kan worden gebruikt voor toegang tot meerdere resources. Als u bijvoorbeeld een clienttoepassing hebt die gemachtigd is om twee web-API's aan te roepen, kan het vernieuwingstoken worden gebruikt om ook een toegangstoken op te halen voor de andere web-API.

Codevoorbeelden

Zie de codevoorbeelden voor scenario's met een systeemeigen toepassings-naar-web-API. En kom regelmatig terug. We voegen regelmatig nieuwe voorbeelden toe. Systeemeigen toepassing naar web-API.

App-registratie

Zie Een app registreren als u een toepassing wilt registreren bij het Azure AD v1.0-eindpunt.

  • Eén tenant: zowel de systeemeigen toepassing als de web-API moeten worden geregistreerd in dezelfde map in Azure AD. De web-API kan worden geconfigureerd om een set machtigingen beschikbaar te maken, die worden gebruikt om de toegang van de systeemeigen toepassing tot de resources te beperken. De clienttoepassing selecteert vervolgens de gewenste machtigingen in de vervolgkeuzelijst Machtigingen voor andere toepassingen in de Azure Portal.
  • Multitenant: ten eerste wordt de systeemeigen toepassing alleen geregistreerd in de map van de ontwikkelaar of uitgever. Ten tweede wordt de systeemeigen toepassing geconfigureerd om de machtigingen aan te geven die nodig zijn om functioneel te zijn. 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 geeft, wordt alleen de web-API geregistreerd in de directory.

Tokenverloop

Wanneer de systeemeigen toepassing de autorisatiecode gebruikt om een JWT-toegangstoken op te halen, ontvangt deze ook een JWT-vernieuwingstoken. Wanneer het toegangstoken verloopt, kan het vernieuwingstoken worden gebruikt om de gebruiker opnieuw te verifiëren zonder dat deze zich opnieuw hoeft aan te melden. Dit vernieuwingstoken wordt vervolgens gebruikt om de gebruiker te verifiëren, wat resulteert in een nieuw toegangstoken en vernieuwingstoken.

Volgende stappen