Gewusst wie: Anmelden von Azure Active Directory-Benutzern mit dem mehrinstanzenfähigen AnwendungsmusterHow to: Sign in any Azure Active Directory user using the multi-tenant application pattern

Wenn Sie vielen Organisationen eine Software-as-a-Service-Anwendung (SaaS) anbieten, können Sie Ihre Anwendung so konfigurieren, dass Anmeldungen von beliebigen Azure Active Directory-Mandanten (Azure AD) akzeptiert werden.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. Diese Konfiguration wird als mehrinstanzenfähige Anwendung bezeichnet.This configuration is called making your application multi-tenant. Benutzer eines Azure AD-Mandanten können sich bei Ihrer Anwendung anmelden, nachdem sie zugestimmt haben, ihr Konto mit Ihrer Anwendung zu verwenden.Users in any Azure AD tenant will be able to sign in to your application after consenting to use their account with your application.

Wenn Sie eine Anwendung besitzen, die mit einem eigenen Kontosystem ausgestattet ist oder andere Arten von Anmeldungen über andere Cloudanbieter unterstützt, erweist sich das Hinzufügen der Azure AD-Anmeldung über beliebige Mandanten als einfach.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. Registrieren Sie einfach Ihre App, fügen Sie den Anmeldecode über OAuth2, OpenID Connect oder SAML hinzu, und implementieren Sie die Schaltfläche „Mit Microsoft anmelden“ in Ihrer Anwendung.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.

Hinweis

In diesem Artikel wird davon ausgegangen, dass Sie mit der Erstellung einer Anwendung für einen Mandanten für Azure AD bereits vertraut sind.This article assumes you’re already familiar with building a single-tenant application for Azure AD. Falls nicht, beginnen Sie mit einer der Schnellstartanleitungen, die auf der Startseite des Entwicklerhandbuchs verfügbar sind.If you’re not, start with one of the quickstarts on the developer guide homepage.

Sie müssen vier Schritte zum Konvertieren der Anwendung in eine mehrinstanzenfähige Azure AD-App ausführen:There are four steps to convert your application into an Azure AD multi-tenant app:

  1. Aktualisieren der Anwendungsregistrierung, sodass sie mehrinstanzenfähig istUpdate your application registration to be multi-tenant
  2. Aktualisieren des Codes zum Senden von Anforderungen an den Endpunkt „/common“Update your code to send requests to the /common endpoint
  3. Aktualisieren des Codes zum Verarbeiten mehrerer AusstellerwerteUpdate your code to handle multiple issuer values
  4. Interpretieren der Benutzer- und Administratorzustimmung und Vornehmen der entsprechenden CodeänderungenUnderstand user and admin consent and make appropriate code changes

Betrachten wir jeden Schritt im Detail.Let’s look at each step in detail. Sie können auch direkt zum Beispiel Erstellen einer mehrinstanzenfähigen SaaS-Anwendung, die Microsoft Graph mithilfe von Azure AD und OpenID Connect aufruft wechseln.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.

Aktualisieren der Registrierung, sodass sie mehrinstanzenfähig istUpdate registration to be multi-tenant

Standardmäßig gelten Web-App-/API-Registrierungen in Azure AD für einen einzelnen Mandanten.By default, web app/API registrations in Azure AD are single-tenant. Sie können Ihre Registrierung mehrinstanzenfähig machen, indem Sie im Azure-Portal im Bereich Authentifizierung Ihrer Anwendungsregistrierung den Schalter Unterstützte Kontotypen auf Konten in einem beliebigen Organisationsverzeichnis festlegen.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.

Damit eine Anwendung mehrinstanzenfähig sein kann, muss der App-ID-URI der Anwendung in Azure AD global eindeutig sein.Before an application can be made multi-tenant, Azure AD requires the App ID URI of the application to be globally unique. Der App-ID-URI ist eine der Methoden, mit der eine Anwendung in Protokollmeldungen identifiziert wird.The App ID URI is one of the ways an application is identified in protocol messages. Bei einer Anwendung mit einem einzelnen Mandanten muss der App-ID-URI nur in diesem Mandanten eindeutig sein.For a single-tenant application, it is sufficient for the App ID URI to be unique within that tenant. Bei einer mehrinstanzenfähigen Anwendung muss er global eindeutig sein, damit Azure AD die Anwendung in allen Mandanten finden kann.For a multi-tenant application, it must be globally unique so Azure AD can find the application across all tenants. Globale Eindeutigkeit wird durch die Anforderung erzwungen, dass der App-ID-URI einen Hostnamen aufweisen muss, der mit einer überprüften Domäne des Azure AD-Mandanten übereinstimmt.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.

Standardmäßig verfügen Apps, die über das Azure-Portal erstellt werden, über einen global eindeutigen App-ID-URI, der bei der Erstellung der App festgelegt wird. Sie können diesen Wert aber ändern.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. Wenn der Name Ihres Mandanten beispielsweise „contoso.onmicrosoft.com“ lautet, wäre https://contoso.onmicrosoft.com/myappein gültiger App-ID-URI.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. Enthält Ihr Mandant die überprüfte Domäne contoso.com, wäre auch ein gültiger App-ID-URI 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. Wenn der App-ID-URI nicht diesem Muster folgt, schlägt das Festlegen einer Anwendung als mehrinstanzenfähig fehl.If the App ID URI doesn’t follow this pattern, setting an application as multi-tenant fails.

Aktualisieren des Codes zum Senden von Anforderungen an „/common“Update your code to send requests to /common

Bei einer Anwendung mit einem einzelnen Mandanten werden Anmeldeanforderungen an den Anmeldeendpunkt des Mandanten gesendet.In a single-tenant application, sign-in requests are sent to the tenant’s sign-in endpoint. Für „contoso.onmicrosoft.com“ würde der Endpunkt beispielsweise wie folgt lauten: https://login.microsoftonline.com/contoso.onmicrosoft.com.For example, for contoso.onmicrosoft.com the endpoint would be: https://login.microsoftonline.com/contoso.onmicrosoft.com. Mit Anforderungen, die an den Endpunkt eines Mandanten gesendet werden, können Benutzer (oder Gäste) in diesem Mandanten für Anwendungen dieses Mandanten angemeldet werden.Requests sent to a tenant’s endpoint can sign in users (or guests) in that tenant to applications in that tenant.

Bei einer mehrinstanzenfähigen Anwendung weiß die Anwendung zunächst nicht, von welchem Mandanten der Benutzer stammt. Deshalb können Sie keine Anforderungen an den Endpunkt eines Mandanten senden.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. Stattdessen werden Anforderungen an einen Endpunkt gesendet, der sie per Multiplexverfahren an alle Azure AD-Mandanten verteilt: https://login.microsoftonline.com/commonInstead, requests are sent to an endpoint that multiplexes across all Azure AD tenants: https://login.microsoftonline.com/common

Wenn Microsoft Identity Platform eine Anforderung am Endpunkt „/common“ erhält, wird der Benutzer angemeldet, und dadurch wird der Mandant ermittelt, von dem der Benutzer stammt.When 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. Der Endpunkt „/common“ funktioniert mit allen von Azure AD unterstützten Authentifizierungsprotokollen: OpenID Connect, OAuth 2.0, SAML 2.0 und WS-Verbund.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.

Die Anmeldeantwort an die Anwendung enthält dann ein Token, das den Benutzer darstellt.The sign-in response to the application then contains a token representing the user. Anhand des Ausstellerwerts im Token erfährt eine Anwendung, von welchem Mandanten der Benutzer stammt.The issuer value in the token tells an application what tenant the user is from. Wenn eine Antwort vom Endpunkt „/common“ zurückgegeben wird, entspricht der Ausstellerwert im Token dem Mandanten des Benutzers.When a response returns from the /common endpoint, the issuer value in the token corresponds to the user’s tenant.

Wichtig

Der Endpunkt „/common“ ist kein Mandant und kein Aussteller, sondern lediglich ein Multiplexer.The /common endpoint is not a tenant and is not an issuer, it’s just a multiplexer. Bei Verwendung von „/common“ muss die Logik zum Überprüfen von Token in Ihrer Anwendung aktualisiert werden, um dies zu berücksichtigen.When using /common, the logic in your application to validate tokens needs to be updated to take this into account.

Aktualisieren des Codes zum Verarbeiten mehrerer AusstellerwerteUpdate your code to handle multiple issuer values

Webanwendungen und Web-APIs empfangen und überprüfen Token von Microsoft Identity Platform.Web applications and web APIs receive and validate tokens from the Microsoft identity platform.

Hinweis

Wenn native Clientanwendungen Token von Microsoft Identity Platform anfordern und empfangen, werden diese zur Überprüfung an APIs weitergeleitet.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. Native Anwendungen überprüfen Zugriffstoken nicht und müssen sie als nicht transparent behandeln.Native applications do not validate access tokens and must treat them as opaque.

Sehen wir uns an, wie eine Anwendung Token überprüft, die sie von Microsoft Identity Platform erhält.Let’s look at how an application validates tokens it receives from the Microsoft identity platform. Eine Anwendung mit einem einzigen Mandanten verwendet normalerweise einen Endpunktwert wie den folgenden:A single-tenant application normally takes an endpoint value like:

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

Hieraus wird eine Metadaten-URL (in diesem Fall OpenID Connect) wie die folgende erstellt:...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

Damit können zwei wichtige Informationen heruntergeladen werden, die zum Überprüfen von Token verwendet werden: die Signaturschlüssel und der Ausstellerwert des Mandanten.to download two critical pieces of information that are used to validate tokens: the tenant’s signing keys and issuer value.

Jeder Azure AD-Mandant weist einen eindeutigen Ausstellerwert in folgender Form auf:Each Azure AD tenant has a unique issuer value of the form:

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

Dabei ist der GUID-Wert die nicht änderbare Version der Mandanten-ID des Mandanten....where the GUID value is the rename-safe version of the tenant ID of the tenant. Wenn Sie den vorhergehenden Metadatenlink für contoso.onmicrosoft.com wählen, können Sie diesen Ausstellerwert im Dokument sehen.If you select the preceding metadata link for contoso.onmicrosoft.com, you can see this issuer value in the document.

Wenn eine Anwendung mit einem einzelnen Mandanten ein Token überprüft, wird die Signatur des Tokens anhand der Signaturschlüssel aus dem Metadatendokument geprüft.When a single-tenant application validates a token, it checks the signature of the token against the signing keys from the metadata document. Hierdurch kann sichergestellt werden, dass der Ausstellerwert im Token dem Wert im Metadatendokument entspricht.This test allows it to make sure the issuer value in the token matches the one that was found in the metadata document.

Da der Endpunkt „/common“ keinem Mandanten entspricht und kein Aussteller ist, hat der Ausstellerwert in den Metadaten für „/common“ eine Vorlagen-URL anstatt eines tatsächlichen Werts: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}/

Aus diesem Grund kann eine mehrinstanzenfähige Anwendung keine Token überprüfen, indem einfach der Ausstellerwert in den Metadaten mit dem issuer -Wert im Token abgeglichen wird.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. Eine mehrinstanzenfähige Anwendung benötigt Logik, um basierend auf der Mandanten-ID im Ausstellerwert zu entscheiden, welche Ausstellerwerte zulässig sind.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.

Wenn eine mehrinstanzenfähige Anwendung nur Anmeldungen von bestimmten Mandanten zulässt, die sich für den Dienst registriert haben, muss der Ausstellerwert oder der Anspruchswert tid im Token überprüft werden. So wird sichergestellt, dass dieser Mandant in der Liste der Abonnenten enthalten ist.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. Wenn eine mehrinstanzenfähige Anwendung nur von Personen genutzt wird und keine Zugriffsentscheidungen basierend auf Mandanten trifft, kann der Ausstellerwert vollständig ignoriert werden.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 den Beispielen für Mehrinstanzenfähigkeit ist die Überprüfung des Ausstellers deaktiviert, damit sich alle Azure AD-Mandanten anmelden können.In the multi-tenant samples, issuer validation is disabled to enable any Azure AD tenant to sign in.

Damit sich ein Benutzer bei einer Anwendung in Azure AD anmelden kann, muss die Anwendung im Mandanten des Benutzers dargestellt werden.For a user to sign in to an application in Azure AD, the application must be represented in the user’s tenant. Dies ermöglicht es der Organisation beispielsweise, eindeutige Richtlinien anzuwenden, wenn sich Benutzer ihres Mandanten bei der Anwendung anmelden.This allows the organization to do things like apply unique policies when users from their tenant sign in to the application. Bei einer Anwendung mit einem einzelnen Mandanten ist diese Registrierung einfacher. Es handelt sich um die Registrierung, die erfolgt, wenn Sie die Anwendung im Azure-Portal registrieren.For a single-tenant application, this registration easier; it’s the one that happens when you register the application in the Azure portal.

Bei einer mehrinstanzenfähigen Anwendung erfolgt die erste Registrierung für die Anwendung in dem Azure AD-Mandanten, der vom Entwickler verwendet wurde.For a multi-tenant application, the initial registration for the application lives in the Azure AD tenant used by the developer. Wenn sich ein Benutzer von einem anderen Mandanten zum ersten Mal bei der Anwendung anmeldet, fordert Azure AD ihn auf, den von der Anwendung angeforderten Berechtigungen zuzustimmen.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. Wenn er zustimmt, wird eine Darstellung der Anwendung, die als Dienstprinzipal bezeichnet wird, im Mandanten des Benutzers erstellt, und die Anmeldung kann fortgesetzt werden.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. Im Verzeichnis, das die Zustimmung des Benutzers zur Anwendung erfasst, wird auch eine Delegierung erstellt.A delegation is also created in the directory that records the user’s consent to the application. Ausführliche Informationen zu Anwendungsobjekten und Dienstprinzipalobjekten der Anwendung und deren Beziehungen zueinander finden Sie unter Anwendungsobjekte und Dienstprinzipalobjekte.For details on the application's Application and ServicePrincipal objects, and how they relate to each other, see Application objects and service principal objects.

Darstellung der Zustimmung zur App mit einer Ebene

Dieser Zustimmungsprozess wird durch die von der Anwendung angeforderten Berechtigungen beeinflusst.This consent experience is affected by the permissions requested by the application. Microsoft Identity Platform unterstützt zwei Arten von Berechtigungen – nur für eine App geltende und delegierte Berechtigungen.Microsoft identity platform supports two kinds of permissions, app-only and delegated.

  • Eine delegierte Berechtigung gewährt einer Anwendung die Möglichkeit, für einen Teil der Funktionen, die der Benutzer ausführen kann, als angemeldeter Benutzer zu agieren.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. Sie können einer Anwendung z.B. die delegierte Berechtigung zum Lesen des Kalenders des angemeldeten Benutzers erteilen.For example, you can grant an application the delegated permission to read the signed in user’s calendar.
  • Eine nur für die App geltende Berechtigung wird der Identität der Anwendung direkt gewährt.An app-only permission is granted directly to the identity of the application. Beispielsweise können Sie einer Anwendung die nur für die App geltende Berechtigung zum Lesen der Liste der Benutzer in einem Mandanten erteilen, unabhängig davon, wer sich bei der Anwendung angemeldet hat.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.

Einigen Berechtigungen kann ein regulärer Benutzer zustimmen, während andere die Zustimmung eines Mandantenadministrators erfordern.Some permissions can be consented to by a regular user, while others require a tenant administrator’s consent.

Weitere Informationen zur Benutzer- und Administratoreinwilligung finden Sie unter Konfigurieren des Workflows für die Administratoreinwilligung.To learn more about user and admin consent, see Configure the admin consent workflow.

Nur für die App geltende Berechtigungen erfordern immer die Zustimmung eines Mandantenadministrators.App-only permissions always require a tenant administrator’s consent. Wenn die Anwendung eine nur für die App geltende Berechtigung anfordert und ein Benutzer versucht, sich bei der Anwendung anzumelden, wird eine Fehlermeldung angezeigt, die besagt, dass der Benutzer nicht zustimmen kann.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.

Bestimmte delegierte Berechtigungen erfordern ebenfalls die Zustimmung eines Mandantenadministrators.Certain delegated permissions also require a tenant administrator’s consent. Beispielsweise erfordert die Funktion zum Zurückschreiben in Azure AD als der angemeldete Benutzer die Zustimmung eines Mandantenadministrators.For example, the ability to write back to Azure AD as the signed in user requires a tenant administrator’s consent. Wenn ein normaler Benutzer versucht, sich bei einer Anwendung anzumelden, die eine delegierte Berechtigung anfordert, für die die Zustimmung des Administrators erforderlich ist, wird in Ihrer Anwendung ein Fehler angezeigt, wie es auch bei nur für die App geltenden Berechtigungen der Fall ist.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. Ob für eine Berechtigung die Zustimmung des Administrators erforderlich ist, wird durch den Entwickler bestimmt, der die Ressource veröffentlicht hat. Sie können dies in der Dokumentation für die Ressource nachlesen.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. In der Berechtigungsdokumentation für die Microsoft Graph-API ist angegeben, für welche Berechtigungen die Zustimmung des Administrators erforderlich ist.The permissions documentation for the Microsoft Graph API indicate which permissions require admin consent.

Wenn Ihre Anwendung Berechtigungen nutzt, die die Zustimmung des Administrators erfordern, müssen Sie z.B. eine Schaltfläche oder einen Link implementieren, damit der Administrator die Aktion initiieren kann.If your application uses permissions that require admin consent, you need to have a gesture such as a button or link where the admin can initiate the action. Die Anforderung, die die Anwendung für diese Aktion sendet, ist die reguläre OAuth2/OpenID Connect-Autorisierungsanforderung, die zusätzlich den Abfragezeichenfolgen-Parameter prompt=admin_consent enthält.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. Nachdem der Administrator zugestimmt hat und der Dienstprinzipal im Mandanten des Kunden erstellt wurde, ist für nachfolgende Anmeldeanforderungen der Parameter prompt=admin_consent nicht mehr erforderlich.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. Da der Administrator entschieden hat, dass die angeforderten Berechtigungen zulässig sind, werden von diesem Zeitpunkt an keine anderen Benutzer im Mandanten zur Zustimmung aufgefordert.Since the administrator has decided the requested permissions are acceptable, no other users in the tenant are prompted for consent from that point forward.

Ein Mandantenadministrator kann die Funktion deaktivieren, dass reguläre Benutzer Anwendungen zustimmen.A tenant administrator can disable the ability for regular users to consent to applications. Wenn diese Funktion deaktiviert ist, ist die Zustimmung des Administrators immer erforderlich, damit die Anwendung im Mandanten verwendet werden kann.If this capability is disabled, admin consent is always required for the application to be used in the tenant. Wenn Sie Ihre Anwendung mit deaktivierter Endbenutzerzustimmung testen möchten, können Sie die Konfigurationsoption im Azure-Portal im Abschnitt Benutzereinstellungen unter Unternehmensanwendungen verwenden.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.

Der Parameter prompt=admin_consent kann auch von Anwendungen verwendet werden, die Berechtigungen anfordern, die nicht die Zustimmung des Administrators erfordern.The prompt=admin_consent parameter can also be used by applications that request permissions that do not require admin consent. Ein Beispiel für einen Anwendungsfall lautet wie folgt: Für die Anwendung ist ein Vorgang erforderlich, bei dem sich der Administrator des Mandanten einmal registriert, und danach werden keine anderen Benutzer mehr zur Zustimmung aufgefordert.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.

Wenn für eine Anwendung die Zustimmung des Administrators erforderlich ist und sich ein Administrator anmeldet, ohne dass der Parameter prompt=admin_consent gesendet wird, gilt die erfolgreiche Zustimmung des Administrators nur für sein Benutzerkonto.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. Reguläre Benutzer können sich weiterhin nicht anmelden und der Anwendung nicht zustimmen.Regular users will still not be able to sign in or consent to the application. Diese Funktion ist sinnvoll, wenn Sie dem Mandantenadministrator die Möglichkeit geben möchten, Ihre Anwendung zu untersuchen, bevor Sie anderen Benutzern Zugriff gewähren.This feature is useful if you want to give the tenant administrator the ability to explore your application before allowing other users access.

Ihre Anwendung weist möglicherweise mehrere Ebenen auf, die in Azure AD jeweils durch eine eigene Registrierung dargestellt werden.Your application may have multiple tiers, each represented by its own registration in Azure AD. Beispielsweise eine native Anwendung, die eine Web-API aufruft, oder eine Webanwendung, die eine Web-API aufruft.For example, a native application that calls a web API, or a web application that calls a web API. In beiden Fällen fordert der Client (native App oder Web-App) Berechtigungen an, um die Ressource (Web-API) aufzurufen.In both of these cases, the client (native app or web app) requests permissions to call the resource (web API). Damit dem Client erfolgreich die Zustimmung im Mandanten eines Kunden erteilt werden kann, müssen alle Ressourcen, für die Berechtigungen angefordert werden, bereits im Mandanten des Kunden vorhanden sein.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. Wenn diese Bedingung nicht erfüllt ist, gibt Azure AD einen Fehler zurück, der besagt, dass die Ressource zuerst hinzugefügt werden muss.If this condition isn’t met, Azure AD returns an error that the resource must be added first.

Mehrere Ebenen in einem einzelnen MandantenMultiple tiers in a single tenant

Dies kann ein Problem sein, wenn die logische Anwendung aus zwei oder mehr Anwendungsregistrierungen besteht, z.B. separate Clients und Ressourcen.This can be a problem if your logical application consists of two or more application registrations, for example a separate client and resource. Wie sorgen Sie zuerst dafür, dass die Ressource im Mandanten des Kunden vorhanden ist?How do you get the resource into the customer tenant first? Azure AD behandelt diesen Fall, indem der Client und die Ressource, der zugestimmt werden soll, in einem einzigen Schritt aktiviert werden.Azure AD covers this case by enabling client and resource to be consented in a single step. Der Benutzer sieht die Gesamtsumme der Berechtigungen, die sowohl vom Client als auch von der Ressource auf der Seite „Zustimmung“ angefordert werden.The user sees the sum total of the permissions requested by both the client and resource on the consent page. Um dieses Verhalten zu ermöglichen, muss die Anwendungsregistrierung der Ressource die App-ID des Clients als knownClientApplications im Anwendungsmanifest enthalten.To enable this behavior, the resource’s application registration must include the client’s App ID as a knownClientApplications in its application manifest. Beispiel:For example:

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

Dies wird in einem Beispiel eines nativen Clients mit mehreren Ebenen, der eine Web-API aufruft, im Abschnitt Verwandte Inhalte am Ende dieses Artikels veranschaulicht.This is demonstrated in a multi-tier native client calling web API sample in the Related content section at the end of this article. Die folgende Abbildung zeigt eine Übersicht über die Zustimmung für eine Mehrparteien-App, die in einem einzigen Mandanten registriert wurde.The following diagram provides an overview of consent for a multi-tier app registered in a single tenant.

Darstellung der Zustimmung zur bekannten Client-App mit mehreren Ebenen

Mehrere Ebenen in mehreren MandantenMultiple tiers in multiple tenants

Ein ähnlicher Fall tritt ein, wenn die verschiedenen Ebenen einer Anwendung in verschiedenen Mandanten registriert sind.A similar case happens if the different tiers of an application are registered in different tenants. Betrachten Sie z.B. die Erstellung einer nativen Clientanwendung, die die Exchange Online-API aufruft.For example, consider the case of building a native client application that calls the Exchange Online API. Um die native Anwendung zu entwickeln und sie später im Mandanten eines Kunden auszuführen, muss der Exchange Online-Dienstprinzipal vorhanden sein.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 diesem Fall müssen der Entwickler und der Kunde Exchange Online erwerben, damit der Dienstprinzipal in seinen Mandanten erstellt wird.In this case, the developer and customer must purchase Exchange Online for the service principal to be created in their tenants.

Falls die API von einer anderen Organisation als Microsoft erstellt wurde, muss der Entwickler der API für Kunden eine Möglichkeit bieten, der Anwendung in den Mandanten der Kunden die Zustimmung zu erteilen.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. Der empfohlene Entwurf gilt für externe Entwickler, um die API so zu erstellen, dass sie auch als Webclient zur Implementierung der Registrierung fungieren kann.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. Gehen Sie dazu folgendermaßen vor:To do this:

  1. Führen Sie die Schritte in den vorherigen Abschnitten durch, um sicherzustellen, dass die API die Registrierungs-/Codeanforderungen für mehrinstanzenfähige Anwendungen erfüllt.Follow the earlier sections to ensure the API implements the multi-tenant application registration/code requirements.
  2. Stellen Sie neben der Bereitstellung der API-Bereiche/-Rollen sicher, dass die Registrierung die (standardmäßig bereitgestellte) Berechtigung „Anmelden und Benutzerprofil lesen“ beinhaltet.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. Implementieren Sie eine Anmelde-/Registrierungsseite im Webclient gemäß den Schritten unter Administratorzustimmung.Implement a sign-in/sign-up page in the web client and follow the admin consent guidance.
  4. Nach der Zustimmung des Benutzers bei der Anwendung werden die Dienstprinzipal- und Zustimmungsdelegierungsverknüpfungen in dessen Mandanten erstellt, und die systemeigene Anwendung kann Tokens für die API abrufen.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.

Die folgende Abbildung zeigt eine Übersicht über die Zustimmung für eine App mit mehreren Ebenen, die in verschiedenen Mandanten registriert wurde.The following diagram provides an overview of consent for a multi-tier app registered in different tenants.

Darstellung der Zustimmung zur Mehrparteien-App mit mehreren Ebenen

Benutzer und Administratoren können die Zustimmung zu Ihrer Anwendung jederzeit widerrufen:Users and administrators can revoke consent to your application at any time:

Wenn ein Administrator einer Anwendung für alle Benutzer in einem Mandanten seine Zustimmung gibt, können Benutzer den Zugriff nicht einzeln widerrufen.If an administrator consents to an application for all users in a tenant, users cannot revoke access individually. Nur der Administrator kann den Zugriff widerrufen, und dies nur für die gesamte Anwendung.Only the administrator can revoke access, and only for the whole application.

Mehrinstanzenfähige Anwendungen und Zwischenspeichern von ZugriffstokenMulti-tenant applications and caching access tokens

Mehrinstanzenfähige Anwendungen können auch Zugriffstoken abrufen, um APIs aufzurufen, die von Azure AD geschützt sind.Multi-tenant applications can also get access tokens to call APIs that are protected by Azure AD. Ein häufiger Fehler bei der Verwendung der Microsoft-Authentifizierungsbibliothek (Microsoft Authentication Library, MSAL) mit einer mehrinstanzenfähigen Anwendung ist, zuerst ein Token für einen Benutzer mithilfe von „/common“ anzufordern, eine Antwort zu erhalten und dann ein weiteres Token für denselben Benutzer ebenfalls mit „/common“ anzufordern.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. Da die Antwort von Azure AD von einem Mandanten stammt (und nicht von „/common“), speichert MSAL das Token als Token vom Mandanten zwischen.Because the response from Azure AD comes from a tenant, not /common, MSAL caches the token as being from the tenant. Beim nachfolgenden Aufruf von „/common“ zum Abrufen eines Zugriffstokens für den Benutzer wird der Cacheeintrag übersehen, und der Benutzer wird aufgefordert, sich erneut anzumelden.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. Um zu vermeiden, dass Cacheeinträge übersehen werden, stellen Sie sicher, dass nachfolgende Aufrufe für einen bereits angemeldeten Benutzer dem Endpunkt des Mandanten gelten.To avoid missing the cache, make sure subsequent calls for an already signed in user are made to the tenant’s endpoint.

Nächste SchritteNext steps

In diesem Artikel haben Sie gelernt, wie Sie eine Anwendung erstellen, die einen Benutzer über einen beliebigen Azure AD-Mandanten anmelden kann.In this article, you learned how to build an application that can sign in a user from any Azure AD tenant. Nach der Aktivierung der einmaligen Anmeldung (SSO) zwischen Ihrer App und Azure AD können Sie auch Ihre Anwendung aktualisieren, um auf von Microsoft-Ressourcen bereitgestellte APIs wie Microsoft 365 zuzugreifen.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. Auf diese Weise können Sie in Ihrer Anwendung für ein personalisiertes Benutzererlebnis sorgen, um den Benutzern beispielsweise Kontextinformationen anzuzeigen, z.B. ihr Profilfoto oder ihren nächsten Kalendertermin.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.

Weitere Informationen zu API-Aufrufen von Azure AD und Microsoft 365-Diensten wie Exchange, SharePoint, OneDrive, OneNote usw. finden Sie unter 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.