Procedure: Een Azure Active Directory-gebruiker aanmelden met behulp van het patroon voor multitenant-toepassingenHow to: Sign in any Azure Active Directory user using the multi-tenant application pattern

Als u een SaaS-toepassing (Software as a Service) aan een groot aantal organisaties levert, kunt u uw toepassing zo configureren dat deze aanmeldingen accepteert van elke Azure Active Directory-Tenant (Azure AD).If you offer a Software as a Service (SaaS) application to many organizations, you can configure your application to accept sign-ins from any Azure Active Directory (Azure AD) tenant. Deze configuratie heet het maken van uw toepassing met meerdere tenants.This configuration is called making your application multi-tenant. Gebruikers in een Azure AD-Tenant kunnen zich aanmelden bij uw toepassing nadat deze hebben ingestemd om hun account bij uw toepassing te gebruiken.Users in any Azure AD tenant will be able to sign in to your application after consenting to use their account with your application.

Als u een bestaande toepassing hebt met een eigen account systeem of andere soorten aanmeldingen van andere cloud providers ondersteunt, is het toevoegen van Azure AD-aanmelding vanuit een wille keurige Tenant eenvoudig.If you have an existing application that has its own account system, or supports other kinds of sign-ins from other cloud providers, adding Azure AD sign-in from any tenant is simple. U hoeft alleen maar uw app te registreren, aanmeldings code toe te voegen via OAuth2, OpenID Connect Connect of SAML en de knop ' Aanmelden met Microsoft ' te plaatsen in uw toepassing.Just register your app, add sign-in code via OAuth2, OpenID Connect, or SAML, and put a "Sign in with Microsoft" button in your application.

Notitie

In dit artikel wordt ervan uitgegaan dat u al bekend bent met het bouwen van een toepassing met één Tenant voor Azure AD.This article assumes you’re already familiar with building a single-tenant application for Azure AD. Als dat niet het geval is, kunt u beginnen met een van de Quick starts op de Start pagina voor de ontwikkelaars handleiding.If you’re not, start with one of the quickstarts on the developer guide homepage.

Er zijn vier stappen om uw toepassing te converteren naar een Azure AD-App voor meerdere tenants:There are four steps to convert your application into an Azure AD multi-tenant app:

  1. De registratie van uw toepassing bijwerken naar multi tenantUpdate your application registration to be multi-tenant
  2. Uw code bijwerken om aanvragen naar het/veelvoorkomende-eind punt te verzendenUpdate your code to send requests to the /common endpoint
  3. Uw code bijwerken om meerdere uitgevers waarden te verwerkenUpdate your code to handle multiple issuer values
  4. Meer informatie over de toestemming van gebruikers en beheerders en het maken van passende code wijzigingenUnderstand user and admin consent and make appropriate code changes

Laten we eens kijken naar elke stap.Let’s look at each step in detail. U kunt ook direct naar het voor beeld gaan met een multi tenant SaaS-webtoepassing die Microsoft Graph aanroept met behulp van Azure AD en OpenID Connect Connect.You can also jump straight to the sample Build a multi-tenant SaaS web application that calls Microsoft Graph using Azure AD and OpenID Connect.

Registratie bijwerken naar multi tenantUpdate registration to be multi-tenant

Web app/API-registraties in azure AD zijn standaard één Tenant.By default, web app/API registrations in Azure AD are single-tenant. U kunt uw registratie meerdere tenants maken door de optie ondersteunde account typen te vinden in het deel venster verificatie van de registratie van uw toepassing in de Azure Portal en in te stellen op accounts in elke organisatie Directory.You can make your registration multi-tenant by finding the Supported account types switch on the Authentication pane of your application registration in the Azure portal and setting it to Accounts in any organizational directory.

Voordat een toepassing kan worden gemaakt met meerdere tenants, moet Azure AD de App-ID-URI van de toepassing globaal uniek zijn.Before an application can be made multi-tenant, Azure AD requires the App ID URI of the application to be globally unique. De URI van de app-id is een van de manieren waarop een toepassing wordt geïdentificeerd in protocolberichten.The App ID URI is one of the ways an application is identified in protocol messages. Voor een toepassing met één tenant is het voldoende dat de URI van de app-id uniek is binnen die tenant.For a single-tenant application, it is sufficient for the App ID URI to be unique within that tenant. Voor een multitenant toepassing moet deze wereldwijd uniek zijn, zodat Azure Active Directory de toepassing in alle tenants kan vinden.For a multi-tenant application, it must be globally unique so Azure AD can find the application across all tenants. Wereldwijde uniekheid wordt afgedwongen door te vereisen dat de URI van de app-id een hostnaam heeft die overeenkomt met een geverifieerd domein van de Azure Active Directory-tenant.Global uniqueness is enforced by requiring the App ID URI to have a host name that matches a verified domain of the Azure AD tenant.

Apps die zijn gemaakt via de Azure Portal, hebben standaard een wereld wijd unieke App-ID-URI die is ingesteld voor het maken van apps, maar u kunt deze waarde wijzigen.By default, apps created via the Azure portal have a globally unique App ID URI set on app creation, but you can change this value. Als de naam van uw Tenant bijvoorbeeld contoso.onmicrosoft.com is, zou een geldige App-ID-URI zouden zijn https://contoso.onmicrosoft.com/myapp .For example, if the name of your tenant was contoso.onmicrosoft.com then a valid App ID URI would be https://contoso.onmicrosoft.com/myapp. Als uw Tenant een geverifieerd domein van heeft contoso.com , zou er ook een geldige App-ID-URI zijn https://contoso.com/myapp .If your tenant had a verified domain of contoso.com, then a valid App ID URI would also be https://contoso.com/myapp. Als de URI van de app-id dit patroon niet volgt, mislukt het instellen van een multitenant toepassing.If the App ID URI doesn’t follow this pattern, setting an application as multi-tenant fails.

Uw code bijwerken om aanvragen te verzenden naar/veelvoorkomendeUpdate your code to send requests to /common

Bij een toepassing met één Tenant worden aanmeldings aanvragen verzonden naar het aanmeldings eindpunt van de Tenant.In a single-tenant application, sign-in requests are sent to the tenant’s sign-in endpoint. Voor contoso.onmicrosoft.com is het eind punt bijvoorbeeld: https://login.microsoftonline.com/contoso.onmicrosoft.com .For example, for contoso.onmicrosoft.com the endpoint would be: https://login.microsoftonline.com/contoso.onmicrosoft.com. Aanvragen die worden verzonden naar het eind punt van een Tenant kunnen gebruikers (of gasten) in die Tenant aanmelden bij toepassingen in die Tenant.Requests sent to a tenant’s endpoint can sign in users (or guests) in that tenant to applications in that tenant.

Met een multi tenant-toepassing kent de toepassing niet de voor zijde van de Tenant van de gebruiker. Daarom kunt u geen aanvragen verzenden naar het eind punt van een Tenant.With a multi-tenant application, the application doesn’t know up front what tenant the user is from, so you can’t send requests to a tenant’s endpoint. In plaats daarvan worden aanvragen verzonden naar een eind punt dat multiplext voor alle Azure AD-tenants: https://login.microsoftonline.com/commonInstead, requests are sent to an endpoint that multiplexes across all Azure AD tenants: https://login.microsoftonline.com/common

Wanneer het micro soft Identity-platform een aanvraag ontvangt in het/veelvoorkomende-eind punt, wordt de gebruiker in en als gevolg hiervan gedetecteerd welke Tenant de gebruiker is.When the Microsoft identity platform receives a request on the /common endpoint, it signs the user in and, as a consequence, discovers which tenant the user is from. Het/veelvoorkomende-eind punt werkt met alle verificatie protocollen die worden ondersteund door Azure AD: OpenID Connect Connect, OAuth 2,0, SAML 2,0 en WS-Federation.The /common endpoint works with all of the authentication protocols supported by the Azure AD: OpenID Connect, OAuth 2.0, SAML 2.0, and WS-Federation.

Het aanmeldings antwoord voor de toepassing bevat vervolgens een token dat de gebruiker vertegenwoordigt.The sign-in response to the application then contains a token representing the user. De waarde van de verlener in het token geeft aan op welke toepassing de gebruiker zich bevindt.The issuer value in the token tells an application what tenant the user is from. Wanneer een antwoord wordt geretourneerd vanuit het/veelvoorkomende-eind punt, komt de waarde van de verlener in het token overeen met de Tenant van de gebruiker.When a response returns from the /common endpoint, the issuer value in the token corresponds to the user’s tenant.

Belangrijk

Het/veelvoorkomende-eind punt is geen Tenant en is geen verlener, het is alleen een multiplexer.The /common endpoint is not a tenant and is not an issuer, it’s just a multiplexer. Wanneer u/veelvoorkomende gebruikt, moet de logica in uw toepassing om tokens te valideren worden bijgewerkt om rekening te houden.When using /common, the logic in your application to validate tokens needs to be updated to take this into account.

Uw code bijwerken om meerdere uitgevers waarden te verwerkenUpdate your code to handle multiple issuer values

Webtoepassingen en Web-Api's ontvangen en valideren tokens van het micro soft Identity-platform.Web applications and web APIs receive and validate tokens from the Microsoft identity platform.

Notitie

Hoewel systeem eigen client toepassingen tokens van het micro soft Identity-platform aanvragen en ontvangen, kunnen ze ze verzenden naar Api's, waar ze worden gevalideerd.While native client applications request and receive tokens from the Microsoft identity platform, they do so to send them to APIs, where they are validated. Systeem eigen toepassingen valideren geen toegangs tokens en moeten ze als dekkend behandelen.Native applications do not validate access tokens and must treat them as opaque.

Laten we eens kijken hoe tokens die de toepassing ontvangt, worden gevalideerd van het micro soft Identity-platform.Let’s look at how an application validates tokens it receives from the Microsoft identity platform. Een toepassing met één Tenant heeft normaal gesp roken een eindpunt waarde als:A single-tenant application normally takes an endpoint value like:

https://login.microsoftonline.com/contoso.onmicrosoft.com

... en gebruikt deze om een meta gegevens-URL te maken (in dit geval OpenID Connect Connect), zoals:...and uses it to construct a metadata URL (in this case, OpenID Connect) like:

https://login.microsoftonline.com/contoso.onmicrosoft.com/.well-known/openid-configuration

voor het downloaden van twee belang rijke stukjes informatie die worden gebruikt voor het valideren van tokens: de handtekening sleutels en de waarde van de verlener van de Tenant.to download two critical pieces of information that are used to validate tokens: the tenant’s signing keys and issuer value.

Elke Azure AD-Tenant heeft een unieke Issuer-waarde van de vorm:Each Azure AD tenant has a unique issuer value of the form:

https://sts.windows.net/31537af4-6d77-4bb9-a681-d2394888ea26/

... de GUID-waarde is de naam van de Tenant-ID van de Tenant....where the GUID value is the rename-safe version of the tenant ID of the tenant. Als u de voor gaande meta gegevens koppeling voor hebt geselecteerd contoso.onmicrosoft.com , ziet u de waarde van deze verlener in het document.If you select the preceding metadata link for contoso.onmicrosoft.com, you can see this issuer value in the document.

Wanneer een toepassing met één Tenant een token valideert, wordt de hand tekening van het token gecontroleerd op basis van de handtekening sleutels uit het meta gegevens document.When a single-tenant application validates a token, it checks the signature of the token against the signing keys from the metadata document. Met deze test kunt u ervoor zorgen dat de naam van de verlener in het token overeenkomt met de waarde die is gevonden in het meta gegevens document.This test allows it to make sure the issuer value in the token matches the one that was found in the metadata document.

Omdat het/veelvoorkomende-eind punt niet overeenkomt met een Tenant en geen verlener is, controleert u de waarde van de verlener in de meta gegevens voor/veelvoorkomende deze een URL met sjabloon heeft in plaats van een werkelijke waarde:Because the /common endpoint doesn’t correspond to a tenant and isn’t an issuer, when you examine the issuer value in the metadata for /common it has a templated URL instead of an actual value:

https://sts.windows.net/{tenantid}/

Daarom kan een toepassing met meerdere tenants geen tokens valideren door te voldoen aan de waarde van de verlener in de meta gegevens met de issuer waarde in het token.Therefore, a multi-tenant application can’t validate tokens just by matching the issuer value in the metadata with the issuer value in the token. Een toepassing met meerdere tenants heeft logica nodig om te bepalen welke Issuer-waarden geldig zijn en die niet zijn gebaseerd op het Tenant-ID-gedeelte van de waarde van de verlener.A multi-tenant application needs logic to decide which issuer values are valid and which are not based on the tenant ID portion of the issuer value.

Als bijvoorbeeld een multi tenant-toepassing alleen aanmelding toestaat vanuit specifieke tenants die zich hebben geregistreerd voor hun service, dan moet de waarde van de verlener of tid claim waarde in het token worden gecontroleerd om ervoor te zorgen dat de Tenant zich in de lijst met abonnees bevindt.For example, if a multi-tenant application only allows sign-in from specific tenants who have signed up for their service, then it must check either the issuer value or the tid claim value in the token to make sure that tenant is in their list of subscribers. Als een toepassing met meerdere tenants alleen met individuen werkt en geen toegangs beslissingen maakt op basis van tenants, dan kan de waarde van de verlener worden genegeerd.If a multi-tenant application only deals with individuals and doesn’t make any access decisions based on tenants, then it can ignore the issuer value altogether.

In de voor beelden met meerdere tenantswordt de verlener uitgeschakeld om een Azure AD-Tenant in te scha kelen om zich aan te melden.In the multi-tenant samples, issuer validation is disabled to enable any Azure AD tenant to sign in.

Een gebruiker kan zich alleen aanmelden bij een toepassing in azure AD als de toepassing wordt weer gegeven in de Tenant van de gebruiker.For a user to sign in to an application in Azure AD, the application must be represented in the user’s tenant. Zo kan de organisatie acties uitvoeren zoals het Toep assen van een uniek beleid wanneer gebruikers van hun Tenant zich aanmelden bij de toepassing.This allows the organization to do things like apply unique policies when users from their tenant sign in to the application. Voor een toepassing met één Tenant is deze registratie eenvoudiger; Dit is de versie die wordt uitgevoerd wanneer u de toepassing registreert in de Azure Portal.For a single-tenant application, this registration easier; it’s the one that happens when you register the application in the Azure portal.

Voor een toepassing met meerdere tenants is de initiële registratie voor de toepassing in de Azure AD-Tenant die wordt gebruikt door de ontwikkelaar.For a multi-tenant application, the initial registration for the application lives in the Azure AD tenant used by the developer. Wanneer een gebruiker van een andere Tenant zich voor de eerste keer aanmeldt bij de toepassing, vraagt Azure AD ze om toestemming te geven aan de machtigingen die de toepassing heeft aangevraagd.When a user from a different tenant signs in to the application for the first time, Azure AD asks them to consent to the permissions requested by the application. Als ze toestemming geven, wordt een weer gave van de toepassing die een Service-Principal wordt genoemd, gemaakt in de Tenant van de gebruiker en kan de aanmelding worden voortgezet.If they consent, then a representation of the application called a service principal is created in the user’s tenant, and sign-in can continue. Er wordt ook een delegering in de Directory gemaakt die de toestemming van de gebruiker registreert voor de toepassing.A delegation is also created in the directory that records the user’s consent to the application. Zie toepassings objecten en Service-Principal-objectenvoor meer informatie over de toepassings-en ServicePrincipal-objecten van de toepassing en hoe ze met elkaar zijn verbonden.For details on the application's Application and ServicePrincipal objects, and how they relate to each other, see Application objects and service principal objects.

Illustreert de toestemming voor app met één laag

Deze bestemmings ervaring wordt beïnvloed door de machtigingen die de toepassing heeft aangevraagd.This consent experience is affected by the permissions requested by the application. Het micro soft Identity-platform ondersteunt twee soorten machtigingen: alleen app en gedelegeerd.The Microsoft identity platform supports two kinds of permissions, app-only and delegated.

  • Een gedelegeerde machtiging verleent een toepassing de mogelijkheid om te fungeren als een aangemelde gebruiker voor een subset van de dingen die de gebruiker kan doen.A delegated permission grants an application the ability to act as a signed in user for a subset of the things the user can do. U kunt bijvoorbeeld een toepassing de gedelegeerde machtiging verlenen voor het lezen van de agenda van de aangemelde gebruiker.For example, you can grant an application the delegated permission to read the signed in user’s calendar.
  • Een machtiging alleen voor apps wordt rechtstreeks verleend aan de identiteit van de toepassing.An app-only permission is granted directly to the identity of the application. U kunt bijvoorbeeld een toepassing de machtiging alleen voor de app verlenen om de lijst met gebruikers in een Tenant te lezen, ongeacht wie zich heeft aangemeld bij de toepassing.For example, you can grant an application the app-only permission to read the list of users in a tenant, regardless of who is signed in to the application.

Sommige machtigingen kunnen worden doorgestuurd naar een gewone gebruiker, terwijl anderen toestemming van de Tenant beheerder vereisen.Some permissions can be consented to by a regular user, while others require a tenant administrator’s consent.

Zie de beheerder toestemming werk stroom configurerenvoor meer informatie over de toestemming van de gebruiker en de beheerder.To learn more about user and admin consent, see Configure the admin consent workflow.

Bij app-specifieke machtigingen is er altijd toestemming van een tenantbeheerder nodig.App-only permissions always require a tenant administrator’s consent. Als uw toepassing een machtiging voor een app aanvraagt en een gebruiker zich probeert aan te melden bij de toepassing, wordt een fout bericht weer gegeven met de melding dat de gebruiker geen toestemming kan geven.If your application requests an app-only permission and a user tries to sign in to the application, an error message is displayed saying the user isn’t able to consent.

Bepaalde gedelegeerde machtigingen vereisen ook de toestemming van een Tenant beheerder.Certain delegated permissions also require a tenant administrator’s consent. Het is bijvoorbeeld mogelijk om terug te schrijven naar Azure AD, omdat de aangemelde gebruiker toestemming van de Tenant beheerder nodig heeft.For example, the ability to write back to Azure AD as the signed in user requires a tenant administrator’s consent. Net als alleen app-machtigingen geldt dat als een gewone gebruiker zich probeert aan te melden bij een toepassing die een gedelegeerde machtiging aanvraagt die toestemming van de beheerder vereist, uw toepassing een fout bericht ontvangt.Like app-only permissions, if an ordinary user tries to sign in to an application that requests a delegated permission that requires administrator consent, your application receives an error. Of een machtiging beheerders toestemming vereist, wordt bepaald door de ontwikkelaar die de resource heeft gepubliceerd en kan worden gevonden in de documentatie voor de resource.Whether a permission requires admin consent is determined by the developer that published the resource, and can be found in the documentation for the resource. De machtigingen documentatie voor de Microsoft Graph-API geven aan welke machtigingen beheerders toestemming nodig heeft.The permissions documentation for the Microsoft Graph API indicate which permissions require admin consent.

Als uw toepassing machtigingen gebruikt waarvoor beheerders toestemming is vereist, moet u een penbeweging hebben zoals een knop of koppeling waar de beheerder de actie kan initiëren.If your application uses permissions that require admin consent, have a gesture such as a button or link where the admin can initiate the action. De aanvraag die uw toepassing verzendt voor deze actie is het gebruikelijke OAuth2/OpenID Connect Connect-autorisatie verzoek dat ook de prompt=admin_consent query teken reeks parameter bevat.The request your application sends for this action is the usual OAuth2/OpenID Connect authorization request that also includes the prompt=admin_consent query string parameter. Zodra de beheerder toestemming heeft gegeven en de Service-Principal is gemaakt in de Tenant van de klant, hebben volgende aanmeldings aanvragen de prompt=admin_consent para meter niet nodig.Once the admin has consented and the service principal is created in the customer’s tenant, subsequent sign-in requests do not need the prompt=admin_consent parameter. Omdat de beheerder heeft vastgesteld dat de aangevraagde machtigingen acceptabel zijn, worden er geen andere gebruikers in de Tenant om vanaf dat moment toestemming gevraagd.Since the administrator has decided the requested permissions are acceptable, no other users in the tenant are prompted for consent from that point forward.

Tenantbeheerders kunnen uitschakelen dat normale gebruikers toestemming kunnen geven voor toepassingen.A tenant administrator can disable the ability for regular users to consent to applications. Als dit wordt uitgeschakeld, is er altijd beheerderstoestemming nodig om een toepassing in een tenant te kunnen gebruiken.If this capability is disabled, admin consent is always required for the application to be used in the tenant. Als u uw toepassing wilt testen wanneer de toestemming van de eind gebruiker is uitgeschakeld, kunt u de configuratie-switch vinden in de Azure Portal in de sectie gebruikers instellingen onder bedrijfs toepassingen.If you want to test your application with end-user consent disabled, you can find the configuration switch in the Azure portal in the User settings section under Enterprise applications.

De prompt=admin_consent para meter kan ook worden gebruikt door toepassingen die machtigingen aanvragen waarvoor geen beheerder toestemming nodig is.The prompt=admin_consent parameter can also be used by applications that request permissions that do not require admin consent. Een voor beeld van wanneer de toepassing wordt gebruikt, is een ervaring waarbij de Tenant beheerder één keer meldt en er geen andere gebruikers om toestemming wordt gevraagd van dat punt op.An example of when this would be used is if the application requires an experience where the tenant admin “signs up” one time, and no other users are prompted for consent from that point on.

Als een toepassing beheerders toestemming vereist en een beheerder zich aanmeldt zonder de prompt=admin_consent para meter die wordt verzonden, wordt de beheerder alleen van toepassing op hun gebruikers account.If an application requires admin consent and an admin signs in without the prompt=admin_consent parameter being sent, when the admin successfully consents to the application it will apply only for their user account. Gewone gebruikers kunnen zich nog steeds niet aanmelden of toestemming geven voor de toepassing.Regular users will still not be able to sign in or consent to the application. Deze functie is handig als u de Tenant beheerder de mogelijkheid wilt geven om uw toepassing te verkennen voordat u andere gebruikers toegang verleent.This feature is useful if you want to give the tenant administrator the ability to explore your application before allowing other users access.

Uw toepassing heeft mogelijk meerdere lagen, die elk worden vertegenwoordigd door een eigen registratie in azure AD.Your application may have multiple tiers, each represented by its own registration in Azure AD. Bijvoorbeeld een systeem eigen toepassing die een web-API aanroept, of een webtoepassing die een web-API aanroept.For example, a native application that calls a web API, or a web application that calls a web API. In beide gevallen vraagt de client (systeem eigen app of web-app) machtigingen voor het aanroepen van de bron (Web-API).In both of these cases, the client (native app or web app) requests permissions to call the resource (web API). De client kan alleen worden doorgestuurd naar de Tenant van een klant als alle resources waaraan het verzoek is toegewezen, al bestaan in de Tenant van de klant.For the client to be successfully consented into a customer’s tenant, all resources to which it requests permissions must already exist in the customer’s tenant. Als niet aan deze voor waarde wordt voldaan, retourneert Azure AD een fout melding dat de resource eerst moet worden toegevoegd.If this condition isn’t met, Azure AD returns an error that the resource must be added first.

Meerdere lagen in één TenantMultiple tiers in a single tenant

Dit kan een probleem zijn als uw logische toepassing bestaat uit twee of meer toepassings registraties, bijvoorbeeld een afzonderlijke client en resource.This can be a problem if your logical application consists of two or more application registrations, for example a separate client and resource. Hoe wordt de resource eerst in de Tenant van de klant weer geven?How do you get the resource into the customer tenant first? Azure AD bestrijkt deze situatie door de client en resource in te scha kelen in één stap.Azure AD covers this case by enabling client and resource to be consented in a single step. De gebruiker ziet het totaal van de machtigingen die zijn aangevraagd door de client en de resource op de pagina toestemming.The user sees the sum total of the permissions requested by both the client and resource on the consent page. Als u dit gedrag wilt inschakelen, moet de toepassings registratie van de resource de App-ID van de client knownClientApplications in het toepassings manifestvan de bron bevatten.To enable this behavior, the resource’s application registration must include the client’s App ID as a knownClientApplications in its application manifest. Bijvoorbeeld:For example:

"knownClientApplications": ["94da0930-763f-45c7-8d26-04d5938baab2"]

Dit wordt geïllustreerd in een native client voor het aanroepen van een web-API met meerdere lagen in de sectie gerelateerde inhoud aan het einde van dit artikel.This is demonstrated in a multi-tier native client calling web API sample in the Related content section at the end of this article. In het volgende diagram vindt u een overzicht van de toestemming voor een app met meerdere lagen die is geregistreerd in één Tenant.The following diagram provides an overview of consent for a multi-tier app registered in a single tenant.

Illustreert de instemming met de bekende client-app met meerdere lagen

Meerdere lagen in meerdere tenantsMultiple tiers in multiple tenants

Een vergelijkbaar geval treedt op als de verschillende lagen van een toepassing in verschillende tenants worden geregistreerd.A similar case happens if the different tiers of an application are registered in different tenants. Denk bijvoorbeeld aan het bouwen van een systeem eigen client toepassing die de Exchange Online API aanroept.For example, consider the case of building a native client application that calls the Exchange Online API. Voor het ontwikkelen van de systeem eigen toepassing en later voor het uitvoeren van de systeem eigen toepassing in de Tenant van een klant, moet de service-principal van Exchange Online zijn.To develop the native application, and later for the native application to run in a customer’s tenant, the Exchange Online service principal must be present. In dit geval moet de ontwikkelaar en klant Exchange Online kopen voor de service-principal die in hun tenants moet worden gemaakt.In this case, the developer and customer must purchase Exchange Online for the service principal to be created in their tenants.

Als het een API is die door een andere organisatie dan micro soft is gebouwd, moet de ontwikkelaar van de API een manier bieden om hun klanten de toepassing te laten toestemming geven aan de tenants van hun klanten.If it's an API built by an organization other than Microsoft, the developer of the API needs to provide a way for their customers to consent the application into their customers' tenants. Het aanbevolen ontwerp is voor de ontwikkelaar van derden om de API te bouwen, zodat deze ook kan worden gebruikt als een webclient voor het implementeren van de registratie.The recommended design is for the third-party developer to build the API such that it can also function as a web client to implement sign-up. Om dit te doen:To do this:

  1. Volg de eerdere secties om te controleren of de API de vereisten voor multi tenant-toepassingen registreren/code implementeert.Follow the earlier sections to ensure the API implements the multi-tenant application registration/code requirements.
  2. Naast het weer geven van de scopes/rollen van de API, moet u ervoor zorgen dat de registratie de machtiging ' aanmelden en gebruikers profiel lezen ' bevat (standaard).In addition to exposing the API's scopes/roles, make sure the registration includes the "Sign in and read user profile" permission (provided by default).
  3. Implementeer een pagina voor aanmelden/aanmelden in de webclient en volg de instructies voor de beheerder .Implement a sign-in/sign-up page in the web client and follow the admin consent guidance.
  4. Zodra de gebruiker aan de toepassing heeft gerefereerd, worden de koppelingen Service-Principal en overdracht van toestemming in hun Tenant gemaakt. de systeem eigen toepassing kan tokens voor de API ophalen.Once the user consents to the application, the service principal and consent delegation links are created in their tenant, and the native application can get tokens for the API.

In het volgende diagram vindt u een overzicht van de toestemming voor een app met meerdere lagen die is geregistreerd in verschillende tenants.The following diagram provides an overview of consent for a multi-tier app registered in different tenants.

Illustreert de toestemming voor multi-party-apps met meerdere lagen

Gebruikers en beheerders kunnen de toestemming voor uw toepassing op elk gewenst moment intrekken:Users and administrators can revoke consent to your application at any time:

Als een beheerder een toepassing voor alle gebruikers in een Tenant toestuurt, kunnen gebruikers de toegang niet afzonderlijk intrekken.If an administrator consents to an application for all users in a tenant, users cannot revoke access individually. Alleen de beheerder kan de toegang intrekken en alleen voor de hele toepassing.Only the administrator can revoke access, and only for the whole application.

Toepassingen voor meerdere tenants en toegangs tokens in de cacheMulti-tenant applications and caching access tokens

Toepassingen met meerdere tenants kunnen ook toegangs tokens krijgen om Api's aan te roepen die door Azure AD worden beveiligd.Multi-tenant applications can also get access tokens to call APIs that are protected by Azure AD. Een veelvoorkomende fout bij het gebruik van de micro soft Authentication Library (MSAL) met een toepassing met meerdere tenants is om eerst een token aan te vragen voor een gebruiker met behulp van/veelvoorkomende, een reactie te ontvangen en vervolgens een volgend token aan te vragen voor diezelfde gebruiker met behulp van/common.A common error when using the Microsoft Authentication Library (MSAL) with a multi-tenant application is to initially request a token for a user using /common, receive a response, then request a subsequent token for that same user also using /common. Omdat het antwoord van Azure AD afkomstig is van een Tenant, niet/veelvoorkomende, MSAL het token in de cache van de Tenant opgeslagen.Because the response from Azure AD comes from a tenant, not /common, MSAL caches the token as being from the tenant. De volgende aanroep van/veelvoorkomende voor het ophalen van een toegangs token voor de gebruiker heeft de cache vermelding missen en de gebruiker wordt gevraagd zich opnieuw aan te melden.The subsequent call to /common to get an access token for the user misses the cache entry, and the user is prompted to sign in again. Om te voor komen dat de cache ontbreekt, moet u ervoor zorgen dat de volgende aanroepen voor een al aangemelde gebruiker worden gemaakt aan het eind punt van de Tenant.To avoid missing the cache, make sure subsequent calls for an already signed in user are made to the tenant’s endpoint.

Volgende stappenNext steps

In dit artikel hebt u geleerd hoe u een toepassing bouwt die kan worden aangemeld bij een gebruiker vanuit een Azure AD-Tenant.In this article, you learned how to build an application that can sign in a user from any Azure AD tenant. Nadat u eenmalige Sign-On (SSO) tussen uw app en Azure AD hebt ingeschakeld, kunt u uw toepassing ook bijwerken om toegang te krijgen tot Api's die beschikbaar worden gesteld door micro soft-resources, zoals Microsoft 365.After enabling Single Sign-On (SSO) between your app and Azure AD, you can also update your application to access APIs exposed by Microsoft resources like Microsoft 365. Zo kunt u een persoonlijke ervaring bieden in uw toepassing, zoals het weer geven van contextuele informatie aan de gebruikers, zoals de profiel afbeelding of de volgende agenda-afspraak.This lets you offer a personalized experience in your application, such as showing contextual information to the users, like their profile picture or their next calendar appointment.

Ga voor meer informatie over het maken van API-aanroepen naar Azure AD en Microsoft 365 services zoals Exchange, share point, OneDrive, OneNote en meer naar Microsoft Graph-API.To learn more about making API calls to Azure AD and Microsoft 365 services like Exchange, SharePoint, OneDrive, OneNote, and more, visit Microsoft Graph API.