Native apps

Waarschuwing

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

Systeemeigen apps zijn toepassingen die een web-API aanroepen namens een gebruiker. 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 verzonden in de aanvraag naar de web-API, die de gebruiker autoriseert en de gewenste resource retourneert.

Diagram

Systeemeigen toepassing naar web-API-diagram

Verloop van het protocol

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

  1. Met behulp van een pop-upvenster van de browser doet 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 wordt weergegeven in Azure Portal en de URI van de toepassings-id voor de web-API. Als de gebruiker zich nog niet heeft aangemeld, wordt hij of zij gevraagd zich opnieuw aan te melden
  2. Azure AD verifieert de gebruiker. Als het een toepassing met meerdere tenants is en toestemming is vereist voor het gebruik van de toepassing, 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 antwoord op autorisatiecode terug naar de omleidings-URI van de clienttoepassing.
  3. Wanneer Azure AD een antwoord op autorisatiecode teruggeeft naar de omleidings-URI, stopt de clienttoepassing de interactie van de browser en extraheert de autorisatiecode uit het antwoord. Met deze autorisatiecode verzendt de clienttoepassing een aanvraag naar het tokeneindpunt van Azure AD dat de autorisatiecode bevat, details over de clienttoepassing (toepassings-id en omleidings-URI) en de gewenste resource (toepassings-id-URI voor de web-API).
  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 hun weergavenaam en tenant-id.
  5. Via HTTPS gebruikt de clienttoepassing het geretourneerde JWT-toegangstoken om de JWT-tekenreeks toe te voegen met een 'Bearer'-aanduiding in de autorisatieheader van de aanvraag aan de web-API. De web-API valideert vervolgens het JWT-token en als de validatie is geslaagd, wordt de gewenste resource geretourneerd.
  6. Wanneer het toegangstoken verloopt, ontvangt de clienttoepassing een foutmelding die aangeeft dat de gebruiker zich opnieuw moet verifiëren. Als de toepassing een geldig vernieuwingstoken heeft, kan het worden gebruikt om een nieuw toegangstoken te verkrijgen zonder dat de gebruiker wordt gevraagd zich opnieuw aan te melden. Als het verversingstoken verloopt, moet de toepassing de gebruiker opnieuw interactief authenticeren.

Opmerking

Het vernieuwingstoken dat is uitgegeven door Azure AD, 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 naar de andere web-API op te halen.

Codevoorbeelden

Zie de codevoorbeelden voor scenario's voor systeemeigen toepassing 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 bijbehorende resources te beperken. De clienttoepassing selecteert vervolgens de gewenste machtigingen in de vervolgkeuzelijst Machtigingen voor andere toepassingen in Azure Portal.
  • Multitenant: Eerst werd de native applicatie alleen geregistreerd in de directory van de ontwikkelaar of uitgever. Ten tweede is de systeemeigen toepassing geconfigureerd om aan te geven welke machtigingen deze nodig heeft 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 is 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 directorybeheerder kan toestemming geven voor toepassingen waarvoor dit machtigingsniveau is vereist. Wanneer de gebruiker of beheerder toestemming verleent, wordt alleen de web-API geregistreerd in de map.

Verloop van Token

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 ze zich opnieuw hoeven aan te melden. Deze refresh token wordt vervolgens gebruikt om de gebruiker te authenticeren, wat resulteert in een nieuw toegangstoken en een nieuwe refresh token.

Volgende stappen

  • Last updated on