Konfigurieren Ihrer App Service- oder Azure Functions-App zur Verwendung der Microsoft Entra-Anmeldung

Wählen Sie einen anderen Authentifizierungsanbieter aus, um zu diesem zu springen.

Dieser Artikel zeigt Ihnen, wie Sie die Authentifizierung für Azure App Service oder Azure Functions so konfigurieren, dass Ihre App Benutzer und Benutzerinnen mit der Microsoft Identity Platform (Microsoft Entra) als Authentifizierungsanbieter anmeldet.

Wählen Sie einen Mandanten für Ihre Anwendung und deren Benutzer aus.

Bevor Ihre Anwendung Benutzende anmelden kann, müssen Sie sie in einem Mitarbeitermandanten oder einem externen Mandanten registrieren. Wenn Sie Ihre App Mitarbeitenden oder geschäftlichen Gästen zur Verfügung stellen möchten, registrieren Sie Ihre App in einem Unternehmensmandanten. Wenn Ihre App für Consumer und Geschäftskunden bestimmt ist, registrieren Sie sie in einem externen Mandanten.

1. Melden Sie sich beim Azure-Portal an, und wechseln Sie zu Ihrer App App Service- oder Funktionen-App.

2. Wählen Sie im linken Menü Ihrer App Einstellungen>Authentifizierungaus, und wählen Sie dann Identitätsanbieter hinzufügenaus.

3. Wählen Sie auf der Seite " Identitätsanbieter hinzufügen " Microsoft als Identitätsanbieterwert aus, um sich bei Microsoft- und Microsoft Entra-Identitäten anzumelden.

4. Wählen Sie unter "Mandanten für Ihre Anwendung und deren Benutzer auswählen" eine der folgenden Optionen aus:

   • Personalkonfiguration (aktueller Mandant) für Mitarbeitende und Geschäftsgäste
   • Externe Konfiguration für Verbraucher und Geschäftskunden

Auswählen der App-Registrierung

Das App Service-Authentifizierungsfeature kann automatisch eine App-Registrierung für Sie erstellen. Sie können auch eine Registrierung verwenden, die Sie oder ein Verzeichnisadministrator separat erstellt.

Erstellen Sie automatisch eine neue App-Registrierung, es sei denn, Sie müssen eine App-Registrierung separat erstellen. Sie können die App-Registrierung im Microsoft Entra Admin Center später anpassen, wenn Sie möchten.

Die folgenden Situationen sind die häufigsten Fälle für die Verwendung einer vorhandenen App-Registrierung:

• Ihr Konto verfügt nicht über Berechtigungen zum Erstellen von App-Registrierungen in Ihrem Microsoft Entra-Mandanten.
• Sie möchten eine App-Registrierung von einem anderen Microsoft Entra-Mandanten verwenden als dem, in dem sich Ihre App befindet. Dies ist immer der Fall, wenn Sie beim Auswählen eines Mandanten die externe Konfiguration ausgewählt haben.
• Die Option zum Erstellen einer neuen Registrierung ist für Regierungs-Clouds nicht verfügbar.

Konfigurieren zusätzlicher Prüfungen

Zusätzliche Prüfungen bestimmen, welche Anfragen auf Ihre Anwendung zugreifen dürfen. Sie können dieses Verhalten jetzt anpassen, oder Sie können diese Einstellungen später über die Hauptauthentifizierungsseite anpassen, indem Sie neben den Authentifizierungseinstellungen"Bearbeiten" auswählen.

Wählen Sie für Clientanwendungsanforderung Folgendes aus:

• Lassen Sie Anforderungen nur von dieser Anwendung selbst zu.
• Anforderungen von bestimmten Clientanwendungen zulassen.
• Anforderungen von einer beliebigen Anwendung zulassen (nicht empfohlen).

Wählen Sie für Identitätsanforderung Folgendes aus:

• Lassen Sie Anforderungen von einer beliebigen Identität zu.
• Lassen Sie Anforderungen von bestimmten Identitäten zu.

Wählen Sie für Mandantenanforderung Folgendes aus:

• Lassen Sie Anforderungen nur vom Ausstellermandanten zu.
• Lassen Sie Anforderungen von bestimmten Mandanten zu.
• Verwenden Sie Standardeinschränkungen basierend auf dem Aussteller.

Ihre App muss möglicherweise noch andere Autorisierungsentscheidungen im Code treffen. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Verwenden einer integrierten Autorisierungsrichtlinie .

Konfigurieren von Authentifizierungseinstellungen

Authentifizierungseinstellungen bestimmen, wie Ihre Anwendung auf nicht authentifizierte Anforderungen reagiert. Die Standardeinstellungen leiten alle Anfragen zur Anmeldung mit diesem neuen Anbieter um. Sie können dieses Verhalten jetzt anpassen, oder Sie können diese Einstellungen später über die Hauptauthentifizierungsseite anpassen, indem Sie neben den Authentifizierungseinstellungen"Bearbeiten" auswählen. Weitere Informationen finden Sie unter Authentifizierungsflow.

Entscheiden Sie für Zugriff einschränken, ob Sie folgende Einstellung aktivieren:

• Authentifizierung erforderlich.
• Zulassen des nicht authentifizierten Zugriffs.

Wählen Sie für nicht authentifizierte Anforderungen Fehleroptionen aus:

• HTTP 302 Found redirect: empfohlen für Websites
• HTTP 401 Unauthorized: empfohlen für APIs
• HTTP 403 Forbidden
• HTTP 404 Not found

Wählen Sie Tokenspeicher aus (empfohlen). Der Tokenspeicher sammelt, speichert und aktualisiert Token für Ihre Anwendung. Sie können dieses Verhalten später deaktivieren, wenn Ihre App keine Token benötigt oder wenn Sie die Leistung optimieren müssen.

Hinzufügen des Identitätsanbieters

Wenn Sie die Konfiguration der Mitarbeiter ausgewählt haben, können Sie "Weiter" auswählen: Berechtigungen und hinzufügen alle Microsoft Graph-Berechtigungen, die die Anwendung benötigt. Diese Berechtigungen werden der App-Registrierung hinzugefügt, Sie können Sie jedoch später auch ändern. Wenn Sie eine externe Konfiguration ausgewählt haben, können Sie später Microsoft Graph-Berechtigungen hinzufügen.

• Wählen Sie Hinzufügen aus.

Sie sind nun bereit, die Microsoft Identity Platform für die Authentifizierung in Ihrer App zu verwenden. Der Anbieter wird auf der Seite "Authentifizierung " aufgeführt. Von dort aus können Sie diese Anbieterkonfiguration bearbeiten oder löschen.

Ein Beispiel für die Konfiguration der Microsoft Entra-Anmeldung für eine Web-App, die auf Azure Storage und Microsoft Graph zugreift, finden Sie unter Hinzufügen der App-Authentifizierung zu Ihrer Web-App.

Anfragen autorisieren

Standardmäßig behandelt die App Service-Authentifizierung nur die Authentifizierung. Sie bestimmt, ob der Anrufer die Person ist, die sie behaupten, zu sein. Autorisierung, um zu bestimmen, ob dieser Aufrufer Zugriff auf eine Ressource haben soll, ist ein Schritt über die Authentifizierung hinaus. Weitere Informationen finden Sie unter Autorisierungsgrundlagen.

Ihre App kann Autorisierungsentscheidungen im Code treffen. Die App-Dienstauthentifizierung bietet einige integrierte Überprüfungen, die ihnen helfen können, aber sie allein reichen möglicherweise nicht aus, um die Autorisierungsanforderungen Ihrer App abzudecken. In den folgenden Abschnitten werden diese Funktionen behandelt.

Durchführen von Überprüfungen im Anwendungscode

Wenn Sie Autorisierungsprüfungen in Ihrem App-Code durchführen, können Sie die Anspruchsinformationen verwenden, die die App Service-Authentifizierung zur Verfügung stellt. Weitere Informationen finden Sie unter Zugriff auf Benutzeransprüche im App Code.

Der eingefügte x-ms-client-principal-Header enthält ein Base64-codiertes JSON-Objekt mit den Ansprüchen, die über den Aufrufer geltend gemacht werden. Standardmäßig durchlaufen diese Ansprüche eine Anspruchszuordnung, sodass die Anspruchsnamen möglicherweise nicht immer mit dem übereinstimmen, was im Token angezeigt wird. Der Anspruch tid wird beispielsweise stattdessen zu http://schemas.microsoft.com/identity/claims/tenantid zugeordnet.

Sie können auch direkt mit dem zugrunde liegenden Zugriffstoken aus dem eingefügten x-ms-token-aad-access-token-Header arbeiten.

Verwenden einer integrierten Autorisierungsrichtlinie

Die erstellte App-Registrierung authentifiziert ankommende Anfragen für Ihren Microsoft Entra Mandanten. Standardmäßig kann jeder innerhalb des Mandanten auf die Anwendung zugreifen. Dieser Ansatz ist für viele Anwendungen in Ordnung. Einige Anwendungen müssen den Zugriff durch Autorisierungsentscheidungen weiter einschränken.

Ihr Anwendungscode ist häufig der beste Ort, um benutzerdefinierte Autorisierungslogik zu verarbeiten. Für häufige Szenarien bietet die Microsoft-Identitätsplattform jedoch integrierte Überprüfungen, mit denen Sie den Zugriff einschränken können.

In diesem Abschnitt wird gezeigt, wie Sie integrierte Prüfungen mithilfe der App Service-Authentifizierungs-V2-API aktivieren. Derzeit besteht die einzige Möglichkeit zur Konfiguration dieser integrierten Überprüfungen in der Verwendung von Azure Resource Manager-Vorlagen oder der REST-API.

Innerhalb des API-Objekts verfügt die Konfiguration des Microsoft Entra-Identitätsanbieters über einen validation Abschnitt, der ein defaultAuthorizationPolicy Objekt enthalten kann, wie in der folgenden Struktur dargestellt:

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}

Darüber hinaus können Sie einige Überprüfungen über eine Anwendungseinstellung konfigurieren, unabhängig von der verwendeten API-Version. Sie können die WEBSITE_AUTH_AAD_ALLOWED_TENANTS Anwendungseinstellung mit einer durch Trennzeichen getrennten Liste von bis zu 10 Mandanten-IDs konfigurieren, aaaabbbb-0000-cccc-1111-dddd2222eeeez. B. . Diese Einstellung kann erfordern, dass das eingehende Token von einem der angegebenen Mandanten stammt, wie durch den tid-Anspruch angegeben ist.

Sie können die WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL-Anwendungseinstellung auf true oder 1 konfigurieren, um zu verlangen, dass das eingehende Token einen oid-Anspruch enthält. Wenn Sie allowedPrincipals.identities konfiguriert haben, wird diese Einstellung ignoriert und als wahr betrachtet, da der oid Anspruch dieser bereitgestellten Identitätsliste gegenüber geprüft wird.

Anforderungen, bei denen diese integrierten Prüfungen fehlschlagen, erhalten eine HTTP-Antwort 403 Forbidden .

Verwenden einer verwalteten Identität anstelle eines geheimen Schlüssels (Vorschau)

Anstatt einen geheimen Clientschlüssel für Ihre App-Registrierung zu konfigurieren, können Sie eine Anwendung so konfigurieren, dass sie einer verwalteten Identität vertraut. Die Verwendung einer Identität anstelle eines geheimen Schlüssels bedeutet, dass Sie keinen geheimen Schlüssel verwalten müssen. Sie verfügen nicht über geheime Ablaufereignisse, die behandelt werden sollen, und Sie haben nicht das gleiche Risiko, das möglicherweise mit dem Offenlegen oder Preisgeben dieses Geheimen verbunden ist.

Mit der Identität können Sie einen verbundenen Identitätsnachweis erstellen, der anstelle eines Client-Geheimnisses als Client-Aussage verwendet werden kann. Dieser Ansatz ist nur für Personalkonfigurationen verfügbar. Das integrierte Authentifizierungsfeature unterstützt derzeit Verbundidentitätsanmeldeinformationen als Vorschau.

Sie können die Schritte in diesem Abschnitt verwenden, um Ihre App Service- oder Azure Functions-Ressource für die Verwendung dieses Musters zu konfigurieren. Bei den hier beschriebenen Schritten wird davon ausgegangen, dass Sie bereits eine App-Registrierung mithilfe einer der unterstützten Methoden eingerichtet haben und dass Sie bereits einen geheimen Schlüssel definiert haben.

1. Folgen Sie zum Erstellen einer benutzerseitig verwalteten Identitätsressource diesen Anweisungen.

2. Weisen Sie diese Identität Ihrer App Service- oder Azure Functions-Ressource zu.

   Von Bedeutung

   Die vom Benutzer zugewiesene verwaltete Identität, die Sie erstellen, sollte nur über diese Registrierung der App Service- oder Azure Functions-Anwendung zugewiesen werden. Wenn Sie die Identität einer anderen Ressource zuweisen, geben Sie dieser Ressource unnötigen Zugriff auf Ihre App-Registrierung.

3. Notieren Sie sich die Werte der Objekt-ID und der Client-ID der verwalteten Identität. Sie benötigen die Objekt-ID, um im nächsten Schritt eine Verbundidentitäts-Anmeldeinformationen zu erstellen. Sie verwenden die Client-ID der verwalteten Identität in einem späteren Schritt.

4. Befolgen Sie die Anweisungen der Microsoft Entra-ID , um eine Verbundidentitäts-Anmeldeinformation für eine vorhandene Anwendung zu konfigurieren. Diese Anweisungen enthalten auch Abschnitte zum Aktualisieren von Anwendungscode, die Sie überspringen können.

5. Fügen Sie eine neue Anwendungseinstellung mit dem Namen hinzu OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID. Legen Sie den Wert auf den Client-ID-Wert der verwalteten Identität fest, den Sie in einem vorherigen Schritt abgerufen haben. Verwenden Sie nicht die Client-ID der Registrierung Ihrer App. Stellen Sie sicher, dass Sie diese Anwendungseinstellung als „Slot-Sticky“ markieren.

6. Legen Sie in den integrierten Authentifizierungseinstellungen für Ihre App-Ressource den Namen der geheimen Clientschlüsseleinstellung auf OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.

   So nehmen Sie diese Änderung mithilfe des Azure-Portals vor:

   1. Wechseln Sie zurück zur Ressource "App Service" oder "Azure Functions", und wählen Sie die Registerkarte " Authentifizierung " aus.
   2. Wählen Sie im Abschnitt "Identitätsanbieter " für den Microsoft-Eintrag das Symbol in der Spalte "Bearbeiten" aus.
   3. Öffnen Sie im Dialogfeld " Identitätsanbieter bearbeiten " die Dropdownliste für den Namen der geheimen Clientschlüsseleinstellung , und wählen Sie " OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.
   4. Wählen Sie Speichern aus.

   So nehmen Sie diese Änderung mithilfe der REST-API vor:

   • Legen Sie die clientSecretSettingName-Eigenschaft auf OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID fest. Sie finden diese Eigenschaft unter properties>identityProviders>azureActiveDirectory>registration.

7. Stellen Sie sicher, dass die Anwendung wie erwartet funktioniert. Sie sollten in der Lage sein, eine neue Anmeldeaktion erfolgreich auszuführen.

Wenn Sie mit dem Verhalten mit einer verwalteten Identität zufrieden sind, entfernen Sie den vorhandenen geheimen Schlüssel:

1. Stellen Sie sicher, dass Der App-Code keine Abhängigkeit von der Anwendungseinstellung hat. Befolgen Sie in diesem Fall die Anweisungen zum Aktualisieren des Anwendungscodes, um ein Zugriffstoken anzufordern.

2. Entfernen Sie die Anwendungseinstellung, die zuvor Ihren geheimen Schlüssel gehalten hat. Der Name dieser Anwendungseinstellung ist der vorherige Wert für Name der geheimen Clientschlüsseleinstellung, bevor Sie ihn auf OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID festgelegt haben.

3. Melden Sie sich mit dem Mandanten, der Ihre App-Registrierung enthält, beim Microsoft Entra Admin Center an. Wechseln Sie erneut zur App-Registrierung.

4. Wählen Sie unter "Zertifikate und Geheime Schlüssel" die Option "Geheime Clientschlüssel " aus, und entfernen Sie den geheimen Clientschlüssel.

Ihre App ist jetzt für die Verwendung der Microsoft Entra ID-Authentifizierung ohne geheime Schlüssel konfiguriert.

Konfigurieren von Client-Apps für den Zugriff auf App Service

In früheren Abschnitten haben Sie Ihre App Service- oder Azure Functions-App registriert, um Benutzer zu authentifizieren. In den folgenden Abschnitten wird erläutert, wie Systemeigene Clients oder Daemon-Apps in Microsoft Entra registriert werden. Diese Clients oder Apps können den Zugriff auf APIs anfordern, die vom App-Dienst im Auftrag von Benutzern oder selbst verfügbar gemacht werden, z. B. in einer N-Ebene-Architektur. Wenn Sie nur Benutzer authentifizieren möchten, sind die Schritte in den folgenden Abschnitten nicht erforderlich.

Native Clientanwendung

Sie können systemeigene Clients registrieren, um den Zugriff auf die APIs Ihrer App Service-App im Namen eines angemeldeten Benutzers anzufordern:

1. Wählen Sie im Azure-Portalmenü Die Microsoft Entra-ID aus.

2. Wählen Sie im linken Bereich "App-Registrierungen>" aus. Wählen Sie dann "Neue Registrierung" aus.

3. Geben Sie im Bereich "Anwendung registrieren " für "Name" einen Namen für Ihre App-Registrierung ein.

4. Wählen Sie im Umleitungs-URIden öffentlichen Client/nativen Client (Mobil und Desktop) aus, und geben Sie die Umleitungs-URL ein. Geben Sie z. B. https://contoso.azurewebsites.net/.auth/login/aad/callback ein.

5. Wählen Sie Registrieren.

6. Sobald die App-Registrierung erstellt wurde, kopieren Sie den Wert von Anwendungs-ID (Client) .

   Hinweis

   Für eine Microsoft Store-Anwendung verwenden Sie stattdessen die Paket-SID als URI.

7. Wählen Sie im linken Bereich "API-Berechtigungen>" aus. Wählen Sie dann Berechtigung hinzufügen>Meine APIs aus.

8. Wählen Sie die App-Registrierung aus, die Sie zuvor für Ihre App Service-App erstellt haben. Wenn die App-Registrierung nicht angezeigt wird, müssen Sie den Bereich user_impersonation in der App-Registrierung hinzufügen.

9. Wählen Sie unter Delegierte Berechtigungen den Eintrag user_impersonation aus, und wählen Sie dann Berechtigungen hinzufügen aus.

Sie haben nun eine systemeigene Clientanwendung konfiguriert, die den Zugriff auf Ihre App Service-App im Namen eines Benutzers anfordern kann.

Daemon-Clientanwendung (Dienst-zu-Dienst-Aufrufe)

In einer N-Ebenen-Architektur kann Ihre Clientanwendung ein Token abrufen, um eine App Service- oder Azure Functions-App im Auftrag der Client-App selbst und nicht im Auftrag eines Benutzers aufzurufen. Dieses Szenario ist nützlich für nicht interaktive Daemonanwendungen, die Aufgaben ohne angemeldeten Benutzer ausführen. Es verwendet die Standardzuweisung für Clientanmeldeinformationen von OAuth 2.0. Weitere Informationen finden Sie unter Microsoft Identity Platform und der Fluss von OAuth 2.0-Clientanmeldeinformationen.

1. Wählen Sie im Azure-Portalmenü Die Microsoft Entra-ID aus.

2. Wählen Sie im linken Bereich "App-Registrierungen>" aus. Wählen Sie dann "Neue Registrierung" aus.

3. Geben Sie im Bereich "Anwendung registrieren " für "Name" einen Namen für Ihre App-Registrierung ein.

4. Für eine Daemonanwendung benötigen Sie keinen Umleitungs-URI, sodass Sie das Feld "Umleitungs-URI " leer lassen können.

5. Wählen Sie Registrieren.

6. Sobald die App-Registrierung erstellt wurde, kopieren Sie den Wert von Anwendungs-ID (Client) .

7. Wählen Sie im linken Bereich "Zertifikate und Geheime Schlüssel> aus. Wählen Sie dann geheimen Clientschlüssel>Neuen geheimen Clientschlüsselaus.

8. Geben Sie eine Beschreibung und ein Ablaufdatum ein, und wählen Sie dann Hinzufügen aus.

9. Kopieren Sie im Feld Wert den Wert des geheimen Clientschlüssels. Nachdem Sie sich von dieser Seite entfernt haben, wird sie nicht mehr angezeigt.

Sie können jetzt ein Zugriffstoken anfordern, indem Sie die Client-ID und den geheimen Clientschlüssel verwenden. Legen Sie den resource Parameter auf den Anwendungs-ID-URI-Wert der Ziel-App fest. Das resultierende Zugriffstoken kann dann über den Standardmäßigen OAuth 2.0-Autorisierungsheader der Ziel-App angezeigt werden. Die App-Dienstauthentifizierung überprüft und verwendet das Token, um anzugeben, dass der Aufrufer authentifiziert ist. In diesem Fall ist der Anrufer eine Anwendung, nicht ein Benutzer.

Dieser Ansatz ermöglicht es jeder Clientanwendung in Ihrem Microsoft Entra-Mandanten, ein Zugriffstoken anzufordern und sich bei der Ziel-App zu authentifizieren. Wenn Sie auch die Autorisierung erzwingen möchten, um nur bestimmte Clientanwendungen zuzulassen, müssen Sie zusätzliche Konfigurationen ausführen.

1. Definieren Sie eine App-Rolle im Manifest der App-Registrierung, die den App-Dienst oder die Azure Functions-App darstellt, die Sie schützen möchten.

2. Wählen Sie in der App-Registrierung, die den Client darstellt, der autorisiert werden muss, API-Berechtigungen>Berechtigung hinzufügen>Meine APIs aus.

3. Wählen Sie die App-Registrierung aus, die Sie zuvor erstellt haben. Wenn die App-Registrierung nicht angezeigt wird, stellen Sie sicher, dass Sie eine App-Rolle hinzugefügt haben.

4. Wählen Sie unter Anwendungsberechtigungen die App-Rolle aus, die Sie zuvor erstellt haben. Wählen Sie dann Berechtigungen hinzufügen aus.

5. Wählen Sie "Administratorzustimmung erteilen" aus, um die Clientanwendung zum Anfordern der Berechtigung zu autorisieren.

   Ähnlich wie im vorherigen Szenario (vor dem Hinzufügen von Rollen) können Sie jetzt ein Zugriffstoken für dieselbe Zielressource anfordern. Das Zugriffstoken enthält einen roles Anspruch, der die App-Rollen enthält, die für die Clientanwendung autorisiert wurden.

Im App-Code für den Ziel-App-Dienst oder azure Functions können Sie jetzt überprüfen, ob das Token über die erwarteten Rollen verfügt. Die App Service-Authentifizierung führt diese Überprüfung nicht durch. Weitere Informationen finden Sie unter Zugriff auf Benutzeransprüche im App Code.

Sie haben nun eine Daemon-Clientanwendung konfiguriert, die über eine eigene Identität auf Ihre App Service-App zugreifen kann.

Bewährte Methoden

Unabhängig von der Konfiguration, die Sie zum Einrichten der Authentifizierung verwenden, sorgen Die folgenden bewährten Methoden dafür, dass Ihr Mandant und Ihre Anwendungen sicherer sind:

• Konfigurieren Sie jede App Service-App mit einer eigenen App-Registrierung in Microsoft Entra.
• Erteilen Sie jeder einzelnen App Service-App individuelle Berechtigungen und Einwilligungen.
• Vermeiden Sie das Teilen von Berechtigungen zwischen Umgebungen. Verwenden Sie separate App-Registrierungen für separate Bereitstellungsplätze. Wenn Sie neuen Code testen, kann dies dazu beitragen, probleme zu verhindern, die sich auf die Produktions-App auswirken.

Migrieren zu Microsoft Graph

Einige ältere Apps sind möglicherweise mit einer Abhängigkeit von Azure AD Graph eingerichtet, das veraltet ist und dessen vollständige Abschaltung geplant ist. Beispielsweise könnte Ihr App-Code Azure AD-Graph aufgerufen haben, um die Gruppenmitgliedschaft als Teil eines Autorisierungsfilters in einer Middlewarepipeline zu überprüfen. Apps sollten zu Microsoft Graph wechseln. Weitere Informationen finden Sie unter Migrieren Ihrer Apps von Azure AD Graph zu Microsoft Graph.

Während dieser Migration müssen Sie möglicherweise einige Änderungen an Ihrer Konfiguration der App Service-Authentifizierung vornehmen. Nachdem Sie Ihrer App-Registrierung Microsoft Graph-Berechtigungen hinzugefügt haben, können Sie Folgendes ausführen:

• Aktualisieren Sie den Aussteller-URL-Wert so, dass es das /v2.0 Suffix enthält, wenn er noch nicht vorhanden ist.

• Entfernen Sie Anforderungen für Azure AD Graph-Berechtigungen aus Ihrer Anmeldekonfiguration. Die zu ändernden Eigenschaften hängen von der verwendeten Version der Verwaltungs-API ab:

  • Wenn Sie die V1-API (/authsettings) verwenden, befindet sich diese Einstellung im additionalLoginParams Array.
  • Wenn Sie die V2-API (/authsettingsV2) verwenden, befindet sich diese Einstellung im loginParameters Array.

  Sie müssen zum Beispiel jeden Verweis auf https://graph.windows.net entfernen. Diese Änderung umfasst den resource Parameter, den der /v2.0 Endpunkt nicht unterstützt. Sie enthält auch alle Bereiche, die Sie speziell von Azure AD Graph anfordern.

  Außerdem müssen Sie die Konfiguration aktualisieren, um die neuen Microsoft Graph-Berechtigungen anzufordern, die Sie für die Anwendungsregistrierung eingerichtet haben. In vielen Fällen können Sie den Standardbereich verwenden, um dieses Setup zu vereinfachen. Fügen Sie dazu einen neuen Anmeldeparameter hinzu: scope=openid profile email https://graph.microsoft.com/.default.

Wenn die App Service-Authentifizierung versucht, sich anzumelden, werden bei diesen Änderungen keine Berechtigungen mehr an Azure AD Graph gesendet. Stattdessen erhält es ein Token für Microsoft Graph. Jede Verwendung dieses Tokens aus Ihrem Anwendungscode muss ebenfalls aktualisiert werden, wie unter Migrieren Ihrer Apps von Azure AD Graph zu Microsoft Graph beschrieben ist.

Verwandte Inhalte

• Authentifizierung und Autorisierung in Azure App Service und Azure Functions
• Tutorial: Benutzer durchgehend in Azure App Service authentifizieren und autorisieren

• Schnellstart: Hinzufügen der App-Authentifizierung zu Ihrer Web-App, die auf Azure App Service ausgeführt wird