Toepassingstypen in v1.0

Azure Active Directory (Azure AD) ondersteunt verificatie voor verschillende 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:

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

• Single-page application (SPA): een gebruiker moet zich aanmelden bij een door Azure AD beveiligde Single-page application.
• webbrowser naar webtoepassing: een gebruiker moet zich aanmelden bij een webtoepassing die wordt beveiligd door Azure AD.
• systeemeigen toepassing voor web-API-: een systeemeigen toepassing die wordt uitgevoerd op een telefoon, tablet of pc, moet een gebruiker verifiëren om resources op te halen uit een web-API die wordt beveiligd door Azure AD.
• webtoepassing naar web-API-: een webtoepassing moet resources ophalen uit een web-API die wordt beveiligd door Azure AD.
• Daemon- of servertoepassing voor web-API-: een daemon-toepassing of een servertoepassing zonder webgebruikersinterface moet resources ophalen uit een web-API die wordt beveiligd door Azure AD.

Volg de koppelingen voor meer informatie over elk type app en krijg inzicht in de scenario's op hoog niveau voordat u met de code aan de slag gaat. U kunt ook meer te weten komen over de verschillen die u moet weten bij het schrijven van een bepaalde app die werkt met het v1.0-eindpunt of v2.0-eindpunt.

U kunt alle apps en scenario's ontwikkelen die hier worden beschreven 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 die functionaliteit in de meeste gevallen 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

Elke toepassing die verificatie uitbesteedt aan Azure AD, moet worden geregistreerd in een directory. Deze stap omvat het vertellen van Azure AD 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 aanmelding of het uitwisselen van tokens. De informatie die wordt doorgegeven tussen Azure AD en de toepassing, bevat het volgende:

  • URI van de 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 aanroeper een token wil. Daarnaast is deze waarde opgenomen in het token, zodat de toepassing weet dat het het beoogde doel is.
  • antwoord-URL en omleidings-URI-: voor een web-API of webtoepassing is de antwoord-URL voor antwoorden 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 waarmee Azure AD de gebruikersagent in een OAuth 2.0-aanvraag omleidt.
  • 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 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 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:

• toepassing met één tenant: één tenanttoepassing is bedoeld voor gebruik in één organisatie. Dit zijn doorgaans Line-Of-Business-toepassingen (LoB) die zijn geschreven door een bedrijfsontwikkelaar. Eén tenanttoepassing hoeft alleen te worden geopend door gebruikers in één directory en als gevolg hiervan hoeft deze slechts in één map te worden ingericht. Deze toepassingen worden doorgaans geregistreerd door een ontwikkelaar in de organisatie.
• multitenanttoepassing: een toepassing met meerdere tenants is bedoeld voor gebruik in veel organisaties, niet slechts één organisatie. Dit zijn doorgaans SaaS-toepassingen (software-as-a-service) die zijn geschreven door een onafhankelijke softwareleverancier (ISV). Toepassingen met meerdere tenants moeten worden ingericht in elke map waar ze worden gebruikt. Hiervoor moeten gebruikers- of beheerderstoestemming worden vereist om ze te registreren. Dit toestemmingsproces wordt gestart wanneer een toepassing is geregistreerd in de map en toegang krijgt tot de Graph API of misschien een andere web-API. Wanneer een gebruiker of beheerder van een andere organisatie zich registreert om de toepassing te gebruiken, krijgt deze een dialoogvenster te zien waarin de machtigingen worden weergegeven 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 directory. Zie Overzicht van het Consent Frameworkvoor 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 één tenanttoepassing. Als u uw toepassing bijvoorbeeld beschikbaar maakt voor gebruikers in meerdere mappen, hebt u een mechanisme nodig om te bepalen in welke tenant ze zich bevinden. Een toepassing met één tenant hoeft alleen in een eigen map te zoeken voor een gebruiker, terwijl een toepassing met meerdere tenants een specifieke gebruiker moet identificeren uit alle directory's in Azure AD. Om deze taak uit te voeren, biedt Azure AD een gemeenschappelijk verificatie-eindpunt waarin elke toepassing met meerdere tenants aanmeldingsaanvragen kan doorsturen in plaats van een tenantspecifiek eindpunt. Dit eindpunt is https://login.microsoftonline.com/common voor alle directory's in Azure AD, terwijl een tenantspecifiek eindpunt mogelijk https://login.microsoftonline.com/contoso.onmicrosoft.comis. Het algemene eindpunt is vooral belangrijk om rekening mee te houden bij het ontwikkelen van uw toepassing, omdat u de benodigde logica nodig hebt voor het afhandelen van meerdere tenants 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 in één tenant of toepassing met meerdere tenants opgeeft.

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 informatie over het inrichten van een toepassing in Azure AD en de verschillen tussen toepassingen met één en meerdere tenants. Lees verder om inzicht te hebben in de algemene toepassingsscenario's in Azure AD.

Volgende stappen

• Meer informatie over andere basisbeginselen van Azure AD -verificatie