Scenario: Daemon-toepassing die web-API's aanroept

In dit scenario leert u hoe u een daemon-toepassing bouwt die web-API's aanroept.

Overzicht

Uw toepassing kan een token verkrijgen om een web-API namens zichzelf aan te roepen (niet namens een gebruiker). Dit scenario is handig voor daemon-toepassingen. Er wordt gebruikgemaakt van de standaard-OAuth 2.0-clientreferenties verlenen.

Daemon apps

Enkele voorbeelden van use cases voor daemon-apps zijn;

  • Webtoepassingen die worden gebruikt voor het inrichten of beheren van gebruikers of het uitvoeren van batchprocessen in een directory
  • Bureaubladtoepassingen (zoals Windows-services in Windows- of daemonprocessen in Linux) die batchtaken uitvoeren of een besturingssysteemservice die op de achtergrond wordt uitgevoerd
  • Web-API's die mappen moeten bewerken, niet specifieke gebruikers

Er is nog een veelvoorkomend geval waarbij niet-daemon-toepassingen clientreferenties gebruiken, zelfs wanneer ze namens gebruikers handelen. Dit gebeurt wanneer ze om technische redenen toegang nodig hebben tot een web-API of een resource onder hun eigen identiteit. Een voorbeeld is toegang tot geheimen in Azure Key Vault of Azure SQL Database voor een cache.

U kunt een daemon-toepassing niet implementeren op het apparaat van een gewone gebruiker en een gewone gebruiker heeft geen toegang tot een daemon-toepassing. Alleen een beperkte set IT-beheerders heeft toegang tot apparaten waarop daemon-toepassingen worden uitgevoerd. Dit is zo dat een slechte actor geen toegang heeft tot een clientgeheim of token vanuit apparaatverkeer en namens de daemon-toepassing actie kan ondernemen. Het daemon-toepassingsscenario vervangt apparaatverificatie niet.

Voorbeelden van niet-daemon-toepassingen:

  • Een mobiele toepassing die namens een toepassing toegang heeft tot een webservice, maar niet namens een gebruiker.
  • Een IoT-apparaat dat namens een apparaat toegang heeft tot een webservice, maar niet namens een gebruiker.

Toepassingen die een token verkrijgen voor hun eigen identiteiten:

  • Vertrouwelijke clienttoepassingen, gezien het feit dat ze onafhankelijk van gebruikers toegang hebben tot resources, moeten hun identiteit bewijzen. Beheerders van Microsoft Entra-tenants moeten goedkeuring verlenen aan deze vrij gevoelige apps.
  • Heb een geheim (toepassingswachtwoord of certificaat) geregistreerd bij Microsoft Entra-id. Dit geheim wordt doorgegeven tijdens de aanroep van Microsoft Entra ID om een token op te halen.

Details

Gebruikers kunnen geen interactie hebben met een daemon-toepassing, omdat hiervoor een eigen identiteit is vereist. Dit type toepassing vraagt een toegangstoken aan met behulp van de toepassings-id en de bijbehorende toepassings-id, referentie (wachtwoord of certificaat) en toepassings-id-URI voor Microsoft Entra ID. Na een geslaagde verificatie ontvangt de daemon een toegangstoken (en een vernieuwingstoken) van het Microsoft Identity Platform. Dit token wordt vervolgens gebruikt om de web-API aan te roepen (en wordt indien nodig vernieuwd).

Omdat gebruikers niet kunnen communiceren met daemon-toepassingen, is incrementele toestemming niet mogelijk. Alle vereiste API-machtigingen moeten worden geconfigureerd bij de registratie van de toepassing. De code van de toepassing vraagt alleen statisch gedefinieerde machtigingen aan. Dit betekent ook dat daemon-toepassingen geen ondersteuning bieden voor incrementele toestemming.

Voor ontwikkelaars heeft de end-to-end-ervaring voor dit scenario de volgende aspecten:

  • Daemon-toepassingen kunnen alleen werken in Microsoft Entra-tenants. Het zou niet zinvol zijn om een daemon-toepassing te bouwen die probeert persoonlijke Microsoft-accounts te manipuleren. Als u een LOB-app-ontwikkelaar (Line-Of-Business) bent, maakt u uw daemon-app in uw tenant. Als u een ISV bent, kunt u een multitenant daemon-toepassing maken. Elke tenantbeheerder moet toestemming geven.
  • Tijdens de registratie van de toepassing is de antwoord-URI niet nodig. Geheimen of certificaten of ondertekende asserties delen met Microsoft Entra-id. U moet ook toepassingsmachtigingen aanvragen en beheerderstoestemming verlenen om deze app-machtigingen te gebruiken.
  • De toepassingsconfiguratie moet clientreferenties opgeven als gedeeld met Microsoft Entra-id tijdens de registratie van de toepassing.
  • Het bereik dat wordt gebruikt om een token met de clientreferentiestroom te verkrijgen, moet een statisch bereik zijn.

Als u nog niet bekend bent met identiteits- en toegangsbeheer (IAM) met OAuth 2.0 en OpenID Connect of nog niet met IAM op Microsoft identity platform, is het zeer raadzaam de volgende reeks artikelen te lezen.

Hoewel het niet vereist is deze te lezen voordat u uw eerste quickstart of zelfstudie voltooit, vindt u er onderwerpen die integraal zijn voor het platform en u helpen vertrouwd te raken met het ontwikkelen van complexere scenario's.

Volgende stappen

Ga verder met het volgende artikel in dit scenario: App-registratie.