Freigeben über

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

  • Artikel

Hinweis

Ab dem 1. Juni 2024 können neu erstellte App Service-Apps einen eindeutigen Standardhostnamen mit der Namenskonvention <app-name>-<random-hash>.<region>.azurewebsites.net erstellen. Vorhandene App-Namen bleiben unverändert. Zum Beispiel:

myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Weitere Informationen finden Sie unter Eindeutiger Standardhostname für App Service-Ressourcen.

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.

Auswählen eines Mandanten für Ihre Anwendung und deren Benutzer und Benutzerinnen

Bevor Ihre Anwendung Benutzer und Benutzerinnen anmelden kann, müssen Sie sie in einem Mitarbeitermandanten oder einem externen Mandanten registrieren. Wenn Sie Ihre App für Mitarbeiter- oder Geschäftsgäste verfügbar machen, registrieren Sie Ihre App in einem Mitarbeitermandanten. Wenn Ihre App für Consumer und Geschäftskunden bestimmt ist, registrieren Sie sie in einem externen Mandanten.

  1. Melden Sie sich am Azure-Portal an und navigieren Sie zu Ihrer 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 die Option Microsoft als Identitätsanbieter aus, um Microsoft- und Microsoft Entra ID-Identitäten anzumelden.

  4. Wählen Sie unter Wählen Sie einen Mandanten für Ihre Anwendung und deren Benutzeraus, wählen Sie Personalkonfiguration (aktueller Mandant) für Mitarbeiter und Geschäftsgäste aus, oder wählen Sie externe Konfiguration für Verbraucher und Geschäftskunden aus.

Auswählen der App-Registrierung

Das Feature „App Service-Authentifizierung“ kann automatisch eine App-Registrierung für Sie erstellen, oder Sie können eine Registrierung verwenden, die Sie oder ein Verzeichnisadministrator bzw. -administratorin separat erstellt haben.

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.
  • Die Option zum Erstellen einer neuen Registrierung ist für Regierungs-Clouds nicht verfügbar.

Sie können eine neue App-Registrierung (Option 1) erstellen und verwenden oder eine vorhandene Registrierung verwenden, die separat erstellt wurde (Option 2).

Option 1: Erstellen und Verwenden einer neuen App-Registrierung

Verwenden Sie diese Option, es sei denn, Sie müssen eine App-Registrierung separat erstellen. Sie können die App-Registrierung nach dem Erstellen in Microsoft Entra anpassen.

Hinweis

Die Option zum automatischen Erstellen einer neuen Registrierung ist für Regierungs-Clouds nicht verfügbar. Definieren Sie stattdessen eine Registrierung separat.

  1. Wählen Sie Neue App-Registrierung erstellenaus.

  2. Geben Sie den Namen für die neue App-Registrierung ein.

  3. Wählen Sie den Unterstützten Kontotyp aus:

    • Aktueller Mandant – Einzelner Mandant Nur Konten in diesem Organisationsverzeichnis. Alle Benutzer‑ und Gastkonten in Ihrem Verzeichnis können Ihre Anwendung oder API verwenden. Verwenden Sie diese Option, wenn sich Ihre Zielgruppe innerhalb Ihrer Organisation befindet.
    • Jedes Microsoft Entra-Verzeichnis – Multitenant Konten in einem beliebigen Organisationsverzeichnis Alle Benutzer mit einem Geschäfts-, Schul- oder Unikonto von Microsoft können Ihre Anwendung oder API verwenden. Zu diesen Konten gehören Schulen und Unternehmen, die Office 365 verwenden. Verwenden Sie diese Option, wenn Ihre Zielgruppe Kunden aus dem Unternehmens- oder Bildungsbereich sind und Sie die Mehrinstanzenfähigkeit aktivieren möchten.
    • Jedes Microsoft Entra-Verzeichnis und persönliche Microsoft-Konten Konten in einem beliebigen Organisationsverzeichnis und persönliche Microsoft-Konten (z. B. Skype, Xbox) Alle Benutzer mit einem Geschäfts-, Schul- oder Unikonto bzw. einem persönlichen Microsoft-Konto können Ihre Anwendung oder API verwenden. Dazu gehören Bildungseinrichtungen und Unternehmen, die Office 365 nutzen, sowie persönliche Konten, mit denen die Anmeldung bei Diensten wie Xbox und Skype erfolgt. Mit dieser Option beziehen Sie die umfassendste Gruppe von Microsoft-Identitäten ein und aktivieren die Mehrinstanzenfähigkeit.
    • Nur persönliche Microsoft-Konten Persönliche Konten, die für die Anmeldung bei Diensten wie Xbox und Skype verwendet werden Mit dieser Option beziehen Sie die umfassendste Gruppe von Microsoft-Identitäten ein.

Sie können den Namen der Registrierung oder die unterstützten Kontotypen ändern, wenn Sie möchten.

Ein geheimer Clientschlüssel wird als Slot-Sticky-Anwendungseinstellung namens MICROSOFT_PROVIDER_AUTHENTICATION_SECRET erstellt. Wenn Sie den geheimen Schlüssel in Azure Key Vault verwalten möchten, können Sie diese Einstellung später aktualisieren, um Key Vault-Verweisezu verwenden.

Option 2: Verwenden einer vorhandenen, separat erstellten Registrierung

Wählen Sie eins von beiden:

  • Wählen Sie eine vorhandene App-Registrierung in diesem Verzeichnis aus, und wählen Sie eine App-Registrierung aus der Dropdownliste aus.

  • Geben Sie die Details einer vorhandenen App-Registrierung an, und stellen Sie Folgendes bereit:

    • Anwendungs-ID (Client).
    • Geheimer Clientschlüssel (empfohlen). Ein geheimer Wert, der von der Anwendung verwendet wird, um ihre Identität beim Anfordern eines Tokens nachzuweisen. Dieser Wert wird in der Konfiguration Ihrer App als eine Slot-Sticky-Anwendungseinstellung namens MICROSOFT_PROVIDER_AUTHENTICATION_SECRET gespeichert. Wenn der geheime Clientschlüssel nicht festgelegt ist, verwenden Anmeldevorgänge vom Dienst den impliziten OAuth 2.0-Genehmigungsflow, was nicht empfohlen wird.
    • Aussteller-URL, die die Form <authentication-endpoint>/<tenant-id>/v2.0übernimmt. Ersetzen Sie <authentication-endpoint> durch den -Wert des Authentifizierungsendpunkts, der für die Cloudumgebung spezifisch ist. Beispielsweise würde ein Mitarbeitermandant in der globalen Azure-Umgebung „https://sts.windows.net"“ als Authentifizierungsendpunkt verwenden.

Wenn Sie eine App-Registrierung in einem Mitarbeitermandanten manuell erstellen müssen, lesen Sie Registrieren einer Anwendung bei der Microsoft Identity Platform. Vergessen Sie beim Durchlaufen des Registrierungsprozesses nicht, die Anwendungs-ID (Client-ID) und die geheimen Clientschlüsselwerte zu notieren.

Wählen Sie während des Registrierungsprozesses im Abschnitt Umleitungs-URIs die Option Web für Plattform und den Typ <app-url>/.auth/login/aad/callback aus. Beispiel: https://contoso.azurewebsites.net/.auth/login/aad/callback.

Ändern Sie nach der Erstellung die App-Registrierung:

  1. Wählen Sie im linken Navigationsbereich API offenlegen>Hinzufügen>Speichern aus. Dieser Wert identifiziert die Anwendung eindeutig, wenn sie als Ressource verwendet wird, wodurch Token angefordert werden können, die Zugriff gewähren. Der Wert ist ein Präfix für Bereiche, die Sie erstellen.

    Für eine App mit nur einem Mandanten können Sie den Standardwert verwenden, der die Form api://<application-client-id> aufweist. Sie können auch einen besser lesbaren URI wie https://contoso.com/api basierend auf einer der überprüften Domänen für Ihren Mandanten angeben. Für eine mehrinstanzenfähige App müssen Sie einen benutzerdefinierten URI angeben. Weitere Informationen zu akzeptierten Formaten für App-ID-URIs finden Sie unter Bewährte Methoden für Anwendungseigenschaften in Microsoft Entra ID.

  2. Wählen Sie Bereich hinzufügen.

    1. Geben Sie in Bereichsname den Namen user_impersonation ein.
    2. Wählen Sie unter Wer kann zustimmen die Option Administratoren und Benutzer aus, wenn Sie Benutzern erlauben möchten, diesem Bereich zuzustimmen.
    3. Geben Sie den Namen des Zustimmungsbereichs ein. Geben Sie eine Beschreibung ein, die Benutzern auf der Zustimmungsseite angezeigt werden soll. Geben Sie z. B. Zugriff auf <Anwendungsname> ein.
    4. Wählen Sie Bereich hinzufügen aus.

  3. (Empfohlen) So erstellen Sie einen geheimen Clientschlüssel:

    1. Wählen Sie im linken Navigationsbereich Zertifikate und Geheimnisse>Geheime Clientschlüssel>Neuer geheimer Clientschlüssel aus.
    2. Geben Sie eine Beschreibung und den Ablauf ein, und wählen Sie Hinzufügen aus.
    3. Kopieren Sie im Feld Wert den Wert des geheimen Clientschlüssels. Nachdem Sie von dieser Seite weg navigieren, wird sie nicht mehr angezeigt.

  4. (Optional) Wenn Sie mehrere Antwort-URLs hinzufügen möchten, wählen Sie Authentifizierung aus.

Konfigurieren zusätzlicher Prüfungen

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

Wählen Sie für Clientanwendungsanforderung Folgendes aus:

  • Anforderungen nur von dieser Anwendung selbst zulassen
  • Anforderungen von bestimmten Clientanwendungen zulassen
  • Anforderungen nur jeder Anwendung zulassen (nicht empfohlen)

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

  • Anforderungen von einer beliebigen Identität zulassen
  • Anforderungen von bestimmten Identitäten zulassen

Wählen Sie für Mandantenanforderung Folgendes aus:

  • Anforderungen nur vom Ausstellermandanten zulassen
  • Anforderungen von bestimmten Mandanten zulassen
  • Standardeinschränkungen basierend auf dem Aussteller verwenden

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

Konfigurieren von Authentifizierungseinstellungen

Diese Optionen bestimmen, wie Ihre Anwendung auf nicht authentifizierte Anforderungen reagiert. Die Standardauswahl leitet alle Anforderungen zur Anmeldung mit diesem neuen Anbieter um. Sie können dieses Verhalten jetzt anpassen oder diese Einstellungen später über den Hauptbildschirm der Authentifizierung anpassen, indem Sie neben den Authentifizierungs-Einstellungendie Option Bearbeiten auswählen. Weitere Informationen finden Sie unter Authentifizierungsflow.

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

  • Erzwingen Sie die Authentifizierung.
  • Nicht authentifizierten Zugriff zulassen

Für Nicht authentifizierte Anforderungen

  • HTTP 302 Gefundene Umleitung: für Websites empfohlen
  • HTTP 401 Nicht autorisiert: für APIs empfohlen
  • HTTP 403 – Unzulässig
  • HTTP 404 Nicht gefunden

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 sie die Leistung optimieren müssen.

Hinzufügen des Identitätsanbieters

Wenn Sie die Mitarbeiterkonfiguration der Mitarbeiter ausgewählt haben, können Sie Weiter: Berechtigungen auswählen und alle Microsoft Graph-Berechtigungen hinzufügen, die von der Anwendung benötigt werden. 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 dem Bildschirm 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.

Autorisieren von Anforderungen

Standardmäßig behandelt die App Service-Authentifizierung nur die Authentifizierung. Sie bestimmt, ob der Anrufer die Person ist, die sie sind. 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 integrierten Überprüfungen, was hilfreich sein kann, aber sie allein reichen möglicherweise nicht aus, um die Autorisierungsanforderungen Ihrer App abzudecken.

Tipp

Mehrmandanten Anwendungen sollten den Aussteller und die Mandanten-ID der Anforderung im Rahmen dieses Prozesses überprüfen, um sicherzustellen, dass die Werte zulässig sind. Wenn App Service-Authentifizierung für ein Mehrmandanten Szenario konfiguriert ist, wird nicht überprüft, von welchem Mandanten die Anforderung stammt. Eine App muss möglicherweise auf bestimmte Mandanten beschränkt werden, je nachdem, ob sich die Organisation beispielsweise für den Dienst registriert hat. Siehe Aktualisieren des Codes zum Verarbeiten mehrerer Ausstellerwerte.

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 eingehende Anforderungen für Ihren Microsoft Entra-Mandanten. Standardmäßig kann jeder innerhalb des Mandanten auch 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 Überprüfungen mithilfe der App Service-Authentifizierung 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 Abschnitt validation, der ein defaultAuthorizationPolicy-Objekt wie in der folgenden Struktur enthalten kann:

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
Eigenschaft Beschreibung
defaultAuthorizationPolicy Eine Gruppe von Anforderungen, die erfüllt werden müssen, um auf die App zugreifen zu können. Der Zugriff wird basierend auf einem logischen AND über jeder der konfigurierten Eigenschaften gewährt. Wenn sowohl allowedApplications als auch allowedPrincipals konfiguriert ist, muss die eingehende Anforderung beide Anforderungen erfüllen, um akzeptiert zu werden.
allowedApplications Eine Zulassungsliste von Zeichenfolgenanwendungsclient-IDs, die die Clientressource darstellen, die in die App aufruft. Wenn diese Eigenschaft als nicht leeres Array konfiguriert ist, werden nur Token akzeptiert, die von einer in der Liste angegebenen Anwendung abgerufen werden.

Diese Richtlinie wertet den appid- oder azp-Anspruch des eingehenden Tokens aus, bei dem es sich um ein Zugriffstoken handeln muss. Siehe Nutzlastansprüche.
allowedPrincipals Eine Gruppe von Überprüfungen, die bestimmen, ob der durch die eingehende Anforderung dargestellte Prinzipal auf die App zugreifen kann. Die Erfüllung von allowedPrincipals basiert auf einem logischen OR über den konfigurierten Eigenschaften.
identities (unter allowedPrincipals) Eine Zulassungsliste von Objekt-IDs als Zeichenfolgen, die Benutzer oder Anwendungen darstellt, die Zugriff haben. Wenn diese Eigenschaft als nicht leeres Array konfiguriert ist, kann die allowedPrincipals-Anforderung erfüllt sein, wenn der Benutzer oder die Anwendung, der/die durch die Anforderung dargestellt wird, in der Liste angegeben ist. Die Liste der Identitäten ist auf insgesamt 500 Zeichen begrenzt.

Diese Richtlinie wertet den oid-Anspruch des eingehenden Tokens aus. Siehe Nutzlastansprüche.

Ebenfalls können einige Überprüfungen unabhängig von der verwendeten API-Version über eine Anwendungseinstellung konfiguriert werden. Die WEBSITE_AUTH_AAD_ALLOWED_TENANTS Anwendungseinstellung kann mit einer durch Trennzeichen getrennten Liste von bis zu 10 Mandanten-IDs konfiguriert werden, zum Beispiel, aaaabbbb-0000-cccc-1111-dddd2222eeee.

Diese Einstellung kann erfordern, dass das eingehende Token von einem der angegebenen Mandanten stammt, wie durch den tid Anspruch angegeben ist. Die WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL Anwendungseinstellung kann auf true oder 1 konfiguriert werden, um zu verlangen, dass das eingehende Token einen oid Anspruch enthält. Wenn allowedPrincipals.identities konfiguriert wurde, wird diese Einstellung ignoriert und als "true" behandelt, da der oid Anspruch auf diese bereitgestellte Identitätsliste überprüft wird.

Anforderungen, die diese integrierten Überprüfungen nicht bestehen, erhalten eine HTTP-Antwort 403 Forbidden.

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

In den vorherigen Abschnitten haben Sie Ihren App Service oder Ihre Azure-Funktion registriert, um Benutzer zu authentifizieren. In diesem Abschnitt wird erläutert, wie systemeigene Clients oder Daemon-Apps in Microsoft Entra registriert werden. Sie können den Zugriff auf APIs anfordern, die von Ihrem App Service im Auftrag von Benutzern oder selbst verfügbar gemacht werden, wie in einer N-Ebene-Architektur. Wenn Sie nur Benutzer authentifizieren möchten, sind die Schritte in diesem Abschnitt nicht erforderlich.

Native Clientanwendung

Sie können native Clients registrieren, um im Namen eines angemeldeten Benutzers Zugriff auf die APIs Ihrer App Servic-App zu beantragen.

  1. Wählen Sie im Menü des Portals Microsoft Entra ID aus.

  2. Wählen Sie im linken Navigationsbereich Verwalten>App-Registrierungenaus, und wählen Sie dann Neue Registrierungaus.

  3. Geben Sie auf der Seite Anwendung registrieren einen Namen für Ihre App-Registrierung ein.

  4. Wählen Sie in Umleitungs-URI-öffentlichen Client/nativen (Mobile & Desktop) aus, und geben Sie die URL <app-url>/.auth/login/aad/callbackein. Beispiel: https://contoso.azurewebsites.net/.auth/login/aad/callback.

  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 Navigationsbereich Verwalten>API-Berechtigungenaus. 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, stellen Sie sicher, dass Sie den Bereich user_impersonation in der App-Registrierung hinzufügen haben.

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

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

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

In einer N-Schicht-Architektur kann Ihre Clientanwendung ein Token abrufen, um eine App Service- oder Funktions-App im Namen der Client-App selbst nicht im Namen eines Benutzers aufzurufen. Dieses Szenario ist nützlich für nicht interaktive Daemon-Anwendungen, 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. Navigieren Sie im Menü des Azure-Portals Microsoft Entra ID aus.
  2. Wählen Sie im linken Navigationsbereich Verwalten>App-Registrierungen>Neue Registrierungaus.
  3. Geben Sie auf der Seite Anwendung registrieren einen Namen für Ihre App-Registrierung ein.
  4. Für eine Daemon-Anwendung benötigen Sie keinen Umleitungs-URI, sodass Sie diesen Wert 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 Navigationsbereich Verwalten>Zertifikate und geheime Schlüssel aus. Wählen Sie dann geheimen Clientschlüssel>Neuen geheimen Clientschlüsselaus.
  8. Geben Sie eine Beschreibung und den Ablauf ein, und wählen Sie Hinzufügen aus.
  9. Kopieren Sie im Feld Wert den Wert des geheimen Clientschlüssels. Nachdem Sie von dieser Seite weg navigieren, wird sie nicht mehr angezeigt.

Sie können jetzt ein Zugriffstoken mithilfe der Client-ID und des geheimen Clientschlüsselsanfordern. Legen Sie den resource Parameter auf den Anwendungs-ID-URI der Ziel-App fest. Das resultierende Zugriffstoken kann dann der Ziel-App mithilfe des standardmäßigen OAuth 2.0-Autorisierungsheadersangezeigt werden. Die App Service-Authentifizierung überprüft und verwendet das Token wie gewohnt, um anzugeben, dass der Anrufer 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 außerdem bei der Autorisierung erzwingen möchten, dass nur bestimmte Clientanwendungen zugelassen werden, müssen Sie weitere Konfigurationen vornehmen.

  1. Definieren Sie eine App-Rolle im Manifest der App-Registrierung, die die App Service- oder Funktions-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 keine App-Registrierung angezeigt wird, stellen Sie sicher, dass Sie eine App-Rolle hinzugefügt haben.

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

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

    Ähnlich wie im vorherigen Szenario (vor dem Hinzufügen jeglicher Rollen) können Sie jetzt für dieselbe Ziel-resourceein Zugriffstoken anfordern. Das Zugriffstoken enthält dann einen roles-Anspruch mit den App-Rollen, die für die Clientanwendung autorisiert wurden.

Im App-Code des Ziel-App Services oder der Funktions-App können Sie nun überprüfen, ob die erwarteten Rollen im Token vorhanden sind. Die App Service-Authentifizierung führt diese Überprüfung nicht durch. Weitere Informationen finden Sie unter Zugriff auf Benutzeransprüche.

Sie haben eine Daemon-Clientanwendung konfiguriert, die unter Verwendung der eigenen Identität auf Ihre App Service-App zugreifen kann.

Bewährte Methoden

Unabhängig von der Konfiguration, die Sie zum Einrichten der Authentifizierung verwenden, werden Ihnen die folgenden bewährten Methoden dabei helfen, Ihren Mandanten und Ihre Anwendungen besser zu schützen:

  • Konfigurieren Sie jede App Service-App mit einer eigenen App-Registrierung in Microsoft Entra.
  • Erteilen Sie jeder App Service-App eigene Berechtigungen und Einwilligung.
  • Vermeiden Sie das Teilen von Berechtigungen zwischen Umgebungen. Verwenden Sie separate App-Registrierungen für separate Bereitstellungsplätze. Wenn Sie neuen Code testen, kann diese Vorgehensweise dabei helfen, Probleme zu verhindern, die sich auf die Produktions-App auswirken können.

Migrieren zu Microsoft Graph

Einige ältere Apps wurden möglicherweise auch mit einer Abhängigkeit vom veralteten Azure AD Graph eingerichtet, das für die vollständige Außerbetriebnahme vorgesehen 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 Graphwechseln. 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:

  1. Aktualisieren Sie die URL des Zertifikatausstellers so, dass sie das /v2.0 Suffix „/v2.0“ enthält, wenn dies noch nicht der Fall ist.

  2. 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, der vom /v2.0 -Endpunkt nicht unterstützt wird, oder Bereiche, die Sie speziell von Azure AD Graph anfordern.

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

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.

Nächste Schritte