Teilen über

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

  • Artikel

Hinweis

Ab dem 1. Juni 2024 haben alle neu erstellten App Service-Apps die Möglichkeit, einen eindeutigen Standardhostnamen mit der Namenskonvention <app-name>-<random-hash>.<region>.azurewebsites.net zu erstellen. Vorhandene App-Namen bleiben unverändert.

Beispiel: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

Ausführlichere 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 zuerst 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ü der App die Option Authentifizierung und anschließend Identitätsanbieter hinzufügen aus.

  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 für Mandantentyp die Option Konfiguration der Mitarbeiter (aktueller Mandant) für Mitarbeiter und Mitarbeiterinnen sowie Geschäftsgäste aus, oder wählen Sie Externe Konfiguration für Consumer 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.

Erstellen und verwenden Sie eine neue App-Registrierung, oder verwenden Sie eine vorhandene Registrierung, die separat erstellt wurde.

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 in Microsoft Entra anpassen, sobald sie erstellt ist.

Hinweis

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

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

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. Dazu gehören auch Bildungseinrichtungen 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. Sie können diese Einstellung später aktualisieren, um Key Vault Verweise zu verwenden, wenn Sie den geheimen Schlüssel in Azure Key Vault verwalten möchten.

Option 2: Verwenden einer vorhandenen, separat erstellten Registrierung

Entweder:

  • Wählen Sie Vorhandene App-Registrierung in diesem Verzeichnis auswählen und dann eine App-Registrierung aus der Dropdownliste aus.
  • Wählen Sie Details einer vorhandenen App-Registrierung angeben aus, und geben Sie Folgendes an:
    • 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 im Format <authentication-endpoint>/<tenant-id>/v2.0 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://login.microsoftonline.com"“ als Authentifizierungsendpunkt verwenden.

Wenn Sie eine App-Registrierung manuell in einem Mitarbeitermandanten erstellen müssen, befolgen Sie die Anleitung im Schnellstart Registrierung einer Anwendung. 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, sodass Token angefordert werden können, die Zugriff gewähren. Er wird als Präfix für Bereiche verwendet, 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 in der Referenz zu bewährten Methoden für App-Registrierungen.

  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 in die Textfelder den Namen und die Beschreibung für den Einwilligungsbereich ein, die Benutzern auf der Einwilligungsseite angezeigt werden sollen. 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. Er wird nicht mehr angezeigt, sobald Sie von dieser Seite weg navigieren.

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

Konfigurieren zusätzlicher Prüfungen

Konfigurieren Sie zusätzliche Prüfungen, um zu 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 weitere 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 Anfragen reagiert, und die Standardeinstellungen leiten alle Anfragen 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 zu diesen Optionen finden Sie unter Authentifizierungs-Fluss.

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 dies 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 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 in diesem Tutorial.

Autorisieren von Anforderungen

Standard mäßig verarbeitet die App Service-Authentifizierung nur die Authentifizierung, wobei bestimmt wird, ob der Aufrufer die Person ist, für die er sich ausgibt. Eine Autorisierung, die bestimmt, ob dieser Aufrufer Zugriff auf eine Ressource haben sollte, ist ein weiterer Schritt über die Authentifizierung hinaus. Weitere Informationen zu diesen Konzepten finden Sie unter Grundlagen der Microsoft Identity Platform-Autorisierung.

Ihre App kann Autorisierungsentscheidungen im Code treffen. App Service-Authentifizierung bietet einige integrierte Überprüfungen, die hilfreich sein können, aber möglicherweise alleine nicht ausreichen, um die Autorisierungsanforderungen Ihrer App zu erfüllen.

Tipp

Mehrinstanzenfähige 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 mehrinstanzenfähiges 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 Anleitung zur Mehrinstanzenfähigkeit von Microsoft Identity Platform.

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. 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 auch jeder innerhalb des Mandanten auf die Anwendung zugreifen, was für viele Anwendungen ausreichend ist. Einige Anwendungen müssen jedoch 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 Gruppierung 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 Positivliste von Anwendungsclient-IDs als Zeichenfolgen, die die Clientressource darstellen, die 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. Weitere Informationen finden Sie in der Referenz zu Microsoft Identity Platform-Ansprüchen.
allowedPrincipals Eine Gruppierung 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 darstellen, 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. Weitere Informationen finden Sie in der Referenz zu Microsoft Identity Platform-Ansprüchen.

Darüber hinaus können einige Überprüfungen unabhängig von der verwendeten API-Version über eine Anwendungseinstellung konfiguriert werden. Die Anwendungseinstellung WEBSITE_AUTH_AAD_ALLOWED_TENANTS kann mit einer durch Trennzeichen getrennten Liste von bis zu 10 Mandanten-IDs (z  B. „559a2f9c-c6f2-4d31-b8d6-5ad1a13f8330,5693f64a-3ad5-4be7-b846-e9d1141bcebc“) konfiguriert werden, um zu verlangen, dass das eingehende Token von einem der angegebenen Mandanten stammt, wie im tid-Anspruch angegeben. Die Anwendungseinstellung WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL kann auf „true“ oder „1“ konfiguriert werden, um zu verlangen, dass das eingehende Token einen oid-Anspruch enthält. Diese Einstellung wird ignoriert und als „true“ behandelt, wenn allowedPrincipals.identities konfiguriert wurde (da der oid-Anspruch gegen diese angegebene Liste von Identitäten ü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 Sie native Clients oder Daemon-Apps in Microsoft Entra registrieren können, damit diese im Namen von Benutzern oder im eigenen Namen Zugriff auf APIs beantragen können, die von Ihrer App Service-App zur Verfügung gestellt werden, beispielsweise in einer N-Schicht-Architektur. Sie müssen die in diesem Abschnitt beschriebenen Schritte nicht ausführen, wenn Sie nur Benutzer authentifizieren möchten.

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 aus.

  2. Wählen Sie im linken Navigationsbereich App-Registrierungen>Neue Registrierung aus.

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

  4. Wählen Sie unter Umleitungs-URI die Option Öffentlicher Client (Mobilgerät und Desktop) aus, und geben Sie die URL <app-url>/.auth/login/aad/callback ein. 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 API-Berechtigungen>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 hinzugefügt haben.

  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 native Clientanwendung konfiguriert, die im Namen eines Benutzers Zugriff auf Ihre App Service-App beantragen 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.

  1. Wählen Sie im Menü des Portals Microsoft Entra aus.
  2. Wählen Sie im linken Navigationsbereich App-Registrierungen>Neue Registrierung aus.
  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 Zertifikate und Geheimnisse>Geheime Clientschlüssel>Neuer geheimer Clientschlüssel aus.
  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. Er wird nicht mehr angezeigt, sobald Sie von dieser Seite weg navigieren.

Sie können jetzt ein Zugriffstoken mithilfe der Client-ID und des geheimen Clientschlüssels anfordern, indem Sie den Parameter resource auf den Anwendungs-ID-URI der Ziel-App festlegen. Das resultierende Zugriffstoken kann dann der Ziel-App mithilfe des standardmäßigen OAuth 2.0-Autorisierungsheaders angezeigt werden, woraufhin die App Service-Authentifizierung das Token überprüft und wie üblich verwendet, um jetzt anzuzeigen, dass der Aufrufer (in diesem Fall eine Anwendung, kein Benutzer) authentifiziert ist.

Im Moment ermöglicht dies 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 einige 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 die App-Registrierung nicht 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, und 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.
  6. Ähnlich wie im vorherigen Szenario (vor dem Hinzufügen jeglicher Rollen) können Sie jetzt ein Zugriffstoken anfordern für dieselbe Ziel-resource, woraufhin das Zugriffstoken einen roles-Anspruch aufnimmt, der die App-Rollen enthält, die für die Clientanwendung autorisiert wurden.
  7. Im Code der App Service- oder Funktions-Ziel-App können Sie jetzt überprüfen, ob die erwarteten Rollen im Token vorhanden sind (dies wird nicht von der App Service-Authentifizierung durchgeführt). Weitere Informationen finden Sie unter Zugriff auf Benutzeransprüche.

Sie haben nun 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, indem Sie separate App-Registrierungen für gesonderte Bereitstellungsslots verwenden. 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 kann 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, indem Sie die Anleitung befolgen, die von Microsoft Entra im Rahmen der Ausmusterung von Azure AD Graph bereitgestellt wird. Wenn Sie diese Anweisungen befolgen, 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 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 sie sich im additionalLoginParams-Array.
    • Wenn Sie die V2-API (/authsettingsV2) verwenden, befindet sie sich im loginParameters-Array.

    Sie müssen z. B. jeden Verweis auf https://graph.windows.net" entfernen. Dies umfasst den Parameter resource (der vom Endpunkt „/v2.0“ nicht unterstützt wird) oder alle Bereiche, die Sie speziell anfordern und die von Azure AD Graph stammen.

    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.

Bei diesen Änderungen fordert die App Service-Authentifizierung keine Berechtigungen mehr für Azure AD Graph an, sondern erhält stattdessen ein Token für Microsoft Graph. Jede Verwendung dieses Tokens aus Ihrem Anwendungscode muss gemäß den von Microsoft Entra bereitgestellten Anleitungen ebenfalls aktualisiert werden.

Nächste Schritte