Share via

Toepassingstypen in v1.0

  • Artikel

Waarschuwing

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

Azure Active Directory (Azure AD) ondersteunt verificatie voor diverse moderne app-architecturen, allemaal op basis van industriestandaard protocollen OAuth 2.0 of OpenID Connect.

In het volgende diagram ziet u de scenario's en toepassingstypen en hoe verschillende onderdelen kunnen worden toegevoegd:

Toepassingstypen en -scenario's

Dit zijn de vijf primaire toepassingsscenario's die worden ondersteund door Azure AD:

Volg de links om meer te leren over elk type app en de scenario's op hoog niveau te begrijpen voordat u met de code aan de slag gaat. U kunt ook meer informatie krijgen over de verschillen die u moet kennen bij het schrijven van een bepaalde app die werkt met het v1.0-eindpunt of v2.0-eindpunt.

Notitie

Het v2.0-eindpunt biedt geen ondersteuning voor alle Azure AD scenario's en functies. Lees meer over de beperkingen van v2.0 om te bepalen of u het v2.0-eindpunt moet gebruiken.

U kunt alle apps en scenario's die hier worden beschreven, ontwikkelen met behulp van verschillende talen en platforms. Ze worden allemaal ondersteund door volledige codevoorbeelden die beschikbaar zijn in de handleiding voor codevoorbeelden: v1.0-codevoorbeelden per scenario en v2.0-codevoorbeelden per scenario. U kunt de codevoorbeelden ook rechtstreeks downloaden uit de bijbehorende GitHub-voorbeeldopslagplaatsen.

Als uw toepassing bovendien een specifiek deel of segment van een end-to-end-scenario nodig heeft, kan in de meeste gevallen die functionaliteit onafhankelijk worden toegevoegd. Als u bijvoorbeeld een systeemeigen toepassing hebt die een web-API aanroept, kunt u eenvoudig een webtoepassing toevoegen die ook de web-API aanroept.

App-registratie

Een app registreren die gebruikmaakt van het Azure AD v1.0-eindpunt

Als een toepassing het verifiëren uitbesteedt aan Azure AD, moet deze in een map zijn geregistreerd. Deze stap omvat het Azure AD vertellen over uw toepassing, inclusief de URL waar deze zich bevindt, de URL voor het verzenden van antwoorden na verificatie, de URI om uw toepassing te identificeren en meer. Deze informatie is om enkele belangrijke redenen vereist:

  • Azure AD moet communiceren met de toepassing bij het verwerken van aanmeldingen of het uitwisselen van tokens. De informatie die wordt doorgegeven tussen Azure AD en de toepassing bevat het volgende:

    • URI voor toepassings-id - de id voor een toepassing. Deze waarde wordt tijdens de verificatie naar Azure AD verzonden om aan te geven voor welke toepassing de oproepende functie een token wil. Bovendien wordt deze waarde opgenomen in het token, zodat de toepassing weet dat dit het beoogde doel was.
    • Antwoord-URL en omleidings-URI: voor een web-API of webtoepassing is de antwoord-URL de locatie waar Azure AD het verificatieantwoord verzendt, inclusief een token als de verificatie is geslaagd. Voor een systeemeigen toepassing is de omleidings-URI een unieke id waarnaar de gebruikersagent in een OAuth 2.0-aanvraag wordt omgeleid met Azure AD.
    • Toepassings-id - de id voor een toepassing, die wordt gegenereerd door Azure AD wanneer de toepassing is geregistreerd. Wanneer u een autorisatiecode of token aanvraagt, worden de toepassings-id en -sleutel tijdens de verificatie naar Azure AD verzonden.
    • Sleutel - de sleutel die samen met een toepassings-id wordt verzonden bij het verifiëren bij Azure AD om een web-API aan te roepen.

  • Azure AD moet ervoor zorgen dat de toepassing over de vereiste machtigingen beschikt voor toegang tot uw adreslijstgegevens, andere toepassingen in uw organisatie, enzovoort.

Zie Een app registreren voor meer informatie.

Apps met één tenant en apps met meerdere tenants

Inrichten wordt duidelijker wanneer u begrijpt dat er twee categorieën toepassingen zijn die kunnen worden ontwikkeld en geïntegreerd met Azure AD:

  • Een toepassing met één tenant - Een toepassing met één tenant is bedoeld voor gebruik in één organisatie. Deze is doorgaans een LOB-toepassing (Line-of-business) die is geschreven door een bedrijfsontwikkelaar. Er hoeft slechts één tenanttoepassing te worden geopend door gebruikers in één map. Als gevolg hiervan hoeft deze slechts in één map te worden ingericht. Deze toepassingen worden doorgaans geregistreerd door een ontwikkelaar in de organisatie.
  • Toepassing met meerdere tenants - Toepassingen met meerdere tenants kunnen in vele organisatie worden gebruikt en niet slechts in één organisatie. Dit zijn normaliter Software-as-a-Service-toepassingen (SaaS), geschreven door een onafhankelijke softwareleverancier (ISV). Toepassingen met meerdere tenants moeten worden ingericht in elke map waar ze worden gebruikt, waarvoor gebruikers- of beheerderstoestemming nodig is om ze te registreren. Het toestemmingsproces begint wanneer een toepassing in de map is geregistreerd en toegang verkrijgt tot de Graph-API of wellicht zelfs een andere web-API. Wanneer een gebruiker of beheerder van een andere organisatie zich registreert voor gebruik van de toepassing, wordt er een dialoogvenster weergegeven met de machtigingen die de toepassing nodig heeft. De gebruiker of beheerder kan vervolgens toestemming geven voor de toepassing, die de toepassing toegang geeft tot de vermelde gegevens en de toepassing ten slotte registreert in de map. Zie Overzicht van het Toestemmingsframework voor meer informatie.

Aanvullende overwegingen bij het ontwikkelen van apps met één tenant of meerdere tenants

Er zijn enkele aanvullende overwegingen bij het ontwikkelen van een toepassing met meerdere tenants in plaats van toepassing met één tenant. Als u uw toepassing beschikbaar maakt voor gebruikers in meerdere mappen, hebt u een mechanisme nodig om te bepalen in welke tenant deze zich bevinden. Een toepassing met één tenant hoeft alleen in een eigen map te zoeken naar een gebruiker, terwijl een toepassing met meerdere tenants een specifieke gebruiker moet identificeren uit alle mappen in Azure AD. Om deze taak uit te voeren, biedt Azure AD een algemeen verificatie-eindpunt waar toepassingen met meerdere tenants aanmeldingsaanvragen naartoe kunnen sturen (in plaats van een tenant-specifiek eindpunt). Dit eindpunt is https://login.microsoftonline.com/common bedoeld voor alle mappen in Azure AD, terwijl een tenant-specifiek eindpunt mogelijk ishttps://login.microsoftonline.com/contoso.onmicrosoft.com. Het algemene eindpunt is vooral belangrijk om te overwegen bij het ontwikkelen van uw toepassing, omdat u de benodigde logica nodig hebt om meerdere tenants te verwerken tijdens het aanmelden, afmelden en tokenvalidatie.

Als u momenteel een toepassing met één tenant ontwikkelt maar deze beschikbaar wilt maken voor veel organisaties, kunt u eenvoudig wijzigingen aanbrengen in de toepassing en de configuratie ervan in Azure AD om deze geschikt te maken voor meerdere tenants. Daarnaast gebruikt Azure AD dezelfde ondertekeningssleutel voor alle tokens in alle mappen, ongeacht of u verificatie opgeeft in toepassing voor één tenant of voor meerdere tenants.

Elk scenario dat in dit document wordt vermeld, bevat een subsectie waarin de inrichtingsvereisten worden beschreven. Zie Toepassingen integreren met Azure Active Directory voor meer diepgaande informatie over het inrichten van een toepassing in Azure AD en de verschillen tussen toepassingen met één en meerdere tenants. Lees verder om de algemene toepassingsscenario's in Azure AD te begrijpen.

Volgende stappen