Share via

Web-API

  • Artikel

Waarschuwing

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

Web-API-apps zijn webtoepassingen die resources moeten ophalen uit een web-API. In dit scenario zijn er twee identiteitstypen die de webtoepassing kan gebruiken om de web-API te verifiëren en aan te roepen:

  • Toepassingsidentiteit : in dit scenario wordt gebruikgemaakt van het verlenen van OAuth 2.0-clientreferenties om te verifiëren als de toepassing en toegang te krijgen tot de web-API. Wanneer u een toepassings-id gebruikt, kan de web-API alleen detecteren dat de webtoepassing deze aanroept, omdat de web-API geen informatie over de gebruiker ontvangt. Als de toepassing informatie over de gebruiker ontvangt, wordt deze verzonden via het toepassingsprotocol en niet ondertekend door Azure AD. De web-API vertrouwt erop dat de webtoepassing de gebruiker heeft geverifieerd. Daarom wordt dit patroon een vertrouwd subsysteem genoemd.
  • Gedelegeerde gebruikersidentiteit : dit scenario kan op twee manieren worden uitgevoerd: OpenID Connect en OAuth 2.0-autorisatiecode verlenen met een vertrouwelijke client. De webtoepassing verkrijgt een toegangstoken voor de gebruiker. Dit bewijst voor de web-API dat de gebruiker is geverifieerd bij de webtoepassing en dat de webtoepassing een gedelegeerde gebruikersidentiteit heeft verkregen om de web-API aan te roepen. Dit toegangstoken wordt in de aanvraag verzonden naar de web-API, die de gebruiker autoriseert en de gewenste resource retourneert.

In de onderstaande stroom worden zowel de toepassingsidentiteit als de gedelegeerde gebruikersidentiteitstypen besproken. Het belangrijkste verschil is dat de gedelegeerde gebruikersidentiteit eerst een autorisatiecode moet verkrijgen voordat de gebruiker zich kan aanmelden en toegang kan krijgen tot de web-API.

Diagram

Diagram van webtoepassing naar web-API

Protocolstroom

Toepassingsidentiteit met de toekenning OAuth 2.0-clientreferenties

  1. Een gebruiker is aangemeld bij Azure AD in de webtoepassing (zie de sectie Web-apps voor meer informatie).
  2. De webtoepassing moet een toegangstoken verkrijgen, zodat deze zich kan verifiëren bij de web-API en de gewenste resource kan ophalen. Er wordt een aanvraag ingediend bij het tokeneindpunt van Azure AD, waarbij de referentie, toepassings-id en toepassings-id-URI van de web-API worden opgegeven.
  3. In Azure AD wordt de toepassing geverifieerd en een JWT-toegangstoken geretourneerd om de web-API aan te roepen.
  4. 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 OpenID Connect

  1. Een gebruiker is aangemeld bij een webtoepassing met behulp van Azure AD (zie de sectie Webbrowser naar webtoepassing hierboven). Als de gebruiker van de webtoepassing nog geen toestemming heeft gegeven om de webtoepassing toe te staan de web-API namens de web-API aan te roepen, moet de gebruiker toestemming geven. De toepassing geeft de vereiste machtigingen weer. Als een van deze machtigingen beheerdersmachtigingen zijn, kan een normale gebruiker in de directory geen toestemming geven. Dit toestemmingsproces is alleen van toepassing op toepassingen met meerdere tenants, niet op toepassingen met één tenant, omdat de toepassing al over de benodigde machtigingen beschikt. Wanneer de gebruiker zich heeft aangemeld, heeft de webtoepassing een id-token ontvangen met informatie over de gebruiker, evenals een autorisatiecode.
  2. Met behulp van de autorisatiecode die is uitgegeven door Azure AD, verzendt de webtoepassing een aanvraag naar het tokeneindpunt van Azure AD met daarin de autorisatiecode, details over de clienttoepassing (toepassings-id en omleidings-URI) en de gewenste resource (toepassings-id-URI voor de web-API).
  3. De autorisatiecode en informatie over de webtoepassing en web-API worden gevalideerd door Azure AD. Na een geslaagde validatie retourneert Azure AD twee tokens: een JWT-toegangstoken en een JWT-vernieuwingstoken.
  4. 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 OAuth 2.0-autorisatiecodetoekenning

  1. Een gebruiker is al aangemeld bij een webtoepassing, waarvan het verificatiemechanisme onafhankelijk is van Azure AD.
  2. De webtoepassing vereist een autorisatiecode om een toegangstoken te verkrijgen. Daarom wordt via de browser een aanvraag verzonden naar het autorisatie-eindpunt van Azure AD, waarbij de toepassings-id en omleidings-URI voor de webtoepassing worden opgegeven nadat de verificatie is geslaagd. De gebruiker meldt zich aan bij Azure AD.
  3. Als de gebruiker van de webtoepassing nog geen toestemming heeft gegeven om de webtoepassing toe te staan de web-API namens de web-API aan te roepen, moet de gebruiker toestemming geven. De toepassing geeft de vereiste machtigingen weer. Als een van deze machtigingen beheerdersmachtigingen zijn, kan een normale gebruiker in de directory geen toestemming geven. Deze toestemming is van toepassing op zowel een toepassing met één tenant als een toepassing met meerdere tenants. In het geval van één tenant kan een beheerder beheerderstoestemming uitvoeren om namens de gebruikers toestemming te geven. U kunt dit doen met behulp van de Grant Permissions knop in de Azure Portal.
  4. Nadat de gebruiker toestemming heeft gegeven, ontvangt de webtoepassing de autorisatiecode die nodig is om een toegangstoken te verkrijgen.
  5. Met behulp van de autorisatiecode die is uitgegeven door Azure AD, verzendt de webtoepassing een aanvraag naar het tokeneindpunt van Azure AD met daarin de autorisatiecode, details over de clienttoepassing (toepassings-id en omleidings-URI) en de gewenste resource (toepassings-id-URI voor de web-API).
  6. De autorisatiecode en informatie over de webtoepassing en web-API worden gevalideerd door Azure AD. Na een geslaagde validatie retourneert Azure AD twee tokens: een JWT-toegangstoken en een JWT-vernieuwingstoken.
  7. 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.

Codevoorbeelden

Zie de codevoorbeelden voor webtoepassing naar web-API-scenario's. En kom regelmatig terug. Er worden regelmatig nieuwe voorbeelden toegevoegd. Webtoepassing 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: voor zowel de toepassingsidentiteit als de gedelegeerde gebruikersidentiteit moeten de webtoepassing en de web-API worden geregistreerd in dezelfde directory in Azure AD. De web-API kan worden geconfigureerd om een set machtigingen beschikbaar te maken, die worden gebruikt om de toegang van de webtoepassing tot de resources te beperken. Als een gedelegeerd gebruikersidentiteitstype wordt gebruikt, moet de webtoepassing de gewenste machtigingen selecteren in de vervolgkeuzelijst Machtigingen voor andere toepassingen in de Azure Portal. Deze stap is niet vereist als het identiteitstype Toepassing wordt gebruikt.
  • Multitenant: eerst wordt de webtoepassing 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, worden de webtoepassing en de web-API beide geregistreerd in hun directory.

Tokenverloop

Wanneer de webtoepassing 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