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

  • Artikel

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*innen mit der Microsoft Identity Platform (Microsoft Entra ID) als Authentifizierungsanbieter anmeldet.

Mit der APP Service-Authentifizierungsfunktion kann automatisch eine APP-Registrierung mit der Microsoft Identity-Plattform erstellt werden. Sie können auch eine Registrierung verwenden, die Sie oder ein Verzeichnis-Administrator separat erstellen.

Hinweis

Die Option zum automatischen Erstellen einer neuen Registrierung ist für Government Clouds oder bei Verwendung von [Microsoft Entra ID für Kunden (Vorschau)] nicht verfügbar. Definieren Sie stattdessen eine Registrierung separat.

Option 1: Automatisches Erstellen 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 ID anpassen, sobald sie erstellt ist.

  1. Melden Sie sich am Azure-Portal an und navigieren Sie zu Ihrer App.

  2. Wählen Sie Authentifizierung im Menü auf der linken Seite. Wählen Sie Identitätsanbieter hinzufügen aus.

  3. Wählen Sie Microsoftin der Dropdown-Liste der Identitätsanbieter aus. Die Option zum Erstellen einer neuen Registrierung ist standardmäßig ausgewählt. Sie können den Namen der Registrierung oder die unterstützten Kontotypen ändern.

    Ein Client-Geheimnis wird erstellt und als eine Slot-Sticky-Anwendungseinstellung namens MICROSOFT_PROVIDER_AUTHENTICATION_SECRET gespeichert. 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.

  4. Wenn dies der erste Identitätsanbieter ist, der für die Anwendung konfiguriert wurde, wird auch ein Abschnitt mit den Einstellungen für die App-Dienst-Authentifizierung angezeigt. Andernfalls können Sie mit dem nächsten Schritt fortfahren.

    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.

  5. (Optional) Klicken Sie auf Weiter: Berechtigungen und fügen Sie alle von der Anwendung benötigten Microsoft Graph-Berechtigungen hinzu. Diese werden der APP-Registrierung hinzugefügt, Sie können Sie jedoch später auch ändern.

  6. Klicken Sie auf Hinzufügen.

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.

Option 2: Verwenden einer vorhandenen, separat erstellten Registrierung

Sie können App Service-Authentifizierung so konfigurieren, dass eine vorhandene App-Registrierung verwendet wird. 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.

Schritt 1: Erstellen einer App-Registrierung in Microsoft Entra ID für Ihre App Service-App

Sammeln Sie während der Erstellung der App die folgenden Informationen, die Sie später beim Konfigurieren der Authentifizierung in der App Service-App benötigen:

  • Client-ID
  • Mandanten-ID
  • Geheimer Clientschlüssel (optional, aber empfohlen)
  • Anwendungs-ID-URI

Die Anweisungen zum Erstellen einer App-Registrierung hängen davon ab, ob Sie einen Mitarbeitermandanten oder einen Kundenmandanten verwenden. Verwenden Sie die folgenden Registerkarten, um die richtige Gruppe von Anweisungen für Ihr Szenario auszuwählen.

Gehen Sie wie folgt vor, um die App zu registrieren:

  1. Melden Sie sich beim Azure portal an, suchen Sie die Option App Services, wählen Sie sie aus, und wählen Sie anschließend Ihre App aus. Notieren Sie sich die URL Ihrer App. Sie verwenden diese, um die Registrierung Ihrer Microsoft Entra-App zu konfigurieren.

  2. Navigieren Sie im Portal zu Ihrem Mandanten:

    Wählen Sie im Menü des Portals Microsoft Entra ID aus. Wenn sich der von Ihnen verwendete Mandant von dem unterscheidet, den Sie zum Konfigurieren der App Service-Anwendung verwenden, müssen Sie zuerst die Verzeichnisse ändern.

  3. Notieren Sie sich auf dem Bildschirm „Übersicht“ die Mandanten-ID sowie die Primäre Domäne.

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

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

  6. Wählen Sie unter Unterstützte Kontotypen den Kontotyp aus, der auf diese Anwendung zugreifen kann.

  7. Wählen Sie im Abschnitt Umleitungs-URIs die Option Web für Plattform aus, und geben Sie <app-url>/.auth/login/aad/callback ein. Beispiel: https://contoso.azurewebsites.net/.auth/login/aad/callback.

  8. Wählen Sie Registrieren.

  9. Nachdem die App-Registrierung erstellt wurde, kopieren Sie die Anwendungs-ID (Client) und die Verzeichnis-ID (Mandant) , damit Sie diese später verwenden können.

  10. Wählen Sie im linken Navigationsbereich Authentication (Authentifizierung) aus. Aktivieren Sie unter Implizite Genehmigung und Hybridflows die Option ID-Token, um OpenID Connect-Benutzeranmeldungen von App Service zuzulassen. Wählen Sie Speichern.

  11. (Optional) Wählen Sie im linken Navigationsbereich Branding und Eigenschaften aus. Geben Sie in URL der Startseite die URL Ihrer App Service-App ein, und wählen Sie Speichern aus.

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

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

  14. (Optional) 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.

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

  16. Schließen Sie die Einrichtung Ihrer App-Registrierung ab:

    Für einen Mitarbeitermandanten sind keine weiteren Schritte erforderlich.

Schritt 2: Aktivieren von Microsoft Entra ID in Ihrer App Service-App

  1. Melden Sie sich am Azure-Portal an und navigieren Sie zu Ihrer App.

  2. Wählen Sie im linken Navigationsbereich Authentifizierung>Identitätsanbieter hinzufügen>Microsoft aus.

  3. Wählen Sie den Mandantentyp der von Ihnen erstellten App-Registrierung aus.

  4. Konfigurieren Sie die App so, dass sie die von Ihnen erstellte Registrierung verwendet, indem Sie die Anweisungen für den entsprechenden Mandantentyp verwenden:

    Wählen Sie für App-Registrierungstyp eine der folgenden Optionen aus:

    • Wählen Sie eine bestehende App-Registrierung in diesem Verzeichnis: Wählen Sie eine App-Registrierung aus dem aktuellen Mandanten, und sammeln Sie automatisch die erforderlichen App-Informationen. Das System versucht, einen neuen geheimen Clientschlüssel für die App-Registrierung zu erstellen und Ihre App automatisch für dessen Verwendung zu konfigurieren. Eine Standardaussteller-URL wird auf Grundlage der unterstützten Kontotypen festgelegt, die in der App-Registrierung konfiguriert wurden. Wenn Sie diese Standardeinstellung ändern möchten, ziehen Sie die folgende Tabelle heran.
    • Geben Sie die Details einer vorhandenen App-Registrierung an: Geben Sie Details für eine App-Registrierung von einem anderen Mandanten an, oder wenn Ihr Konto im aktuellen Mandanten nicht berechtigt ist, die Registrierungen abzufragen. Für diese Option müssen Sie die Konfigurationswerte gemäß der folgenden Tabelle manuell eingeben.

    Der Authentifizierungsendpunkt für einen Mitarbeitermandanten sollte ein für die Cloudumgebung spezifischer Wert sein. Beispielsweise würde ein Mitarbeitermandant in der globalen Azure-Umgebung „https://login.microsoftonline.com"“ als Authentifizierungsendpunkt verwenden. Notieren Sie sich den Wert des Authentifizierungsendpunkts, da er zum Erstellen der richtigen Aussteller-URL benötigt wird.

    Wenn Sie die Konfigurationsdetails direkt eintragen, verwenden Sie die Werte, die Sie während der Erstellung der App-Registrierung gesammelt haben:

    Feld BESCHREIBUNG
    Anwendungs-ID (Client) Verwenden Sie die Anwendungs-ID (Client) der App-Registrierung.
    Geheimer Clientschlüssel Verwenden Sie den geheimen Clientschlüssel, den Sie in der App-Registrierung generiert haben. Bei einem geheimen Clientschlüssel wird der Hybridflow verwendet, und der App Service gibt Zugriffs- und Aktualisierungstoken zurück. Wenn der geheime Clientschlüssel nicht festgelegt ist, wird der implizite Flow verwendet und nur ein ID-Token zurückgegeben. Diese Token werden vom Anbieter gesendet und im App Service- Authentifizierungstokenspeicher gespeichert.
    Aussteller-URL Verwenden Sie <authentication-endpoint>/<tenant-id>/v2.0, und ersetzen Sie <authentication-endpoint> durch den Authentifizierungsendpunkt, den Sie im vorherigen Schritt für Ihren Mandantentyp und Ihre Cloudumgebung bestimmt haben, wobei Sie ebenfalls <tenant-id> durch die Verzeichnis-ID (Mandant) ersetzen, in der die App-Registrierung erstellt wurde. Bei Anwendungen, die Azure AD v1 verwenden, müssen Sie /v2.0 in der URL auslassen.

    Dieser Wert wird verwendet, um Benutzer*innen zum richtigen Microsoft Entra-Mandanten umzuleiten, sowie um die entsprechenden Metadaten herunterzuladen, um die entsprechenden Tokensignaturschlüssel und den Anspruchswert des Tokenausstellers zu ermitteln. Jede Konfiguration mit Ausnahme eines mandantenspezifischen Endpunkts wird als mehrinstanzenfähig behandelt. Bei mehrinstanzenfähigen Konfigurationen wird vom System keine Überprüfung der Aussteller- oder Mandanten-ID durchgeführt, und diese Überprüfungen sollten vollständig in der Autorisierungslogik Ihrer App verarbeitet werden.
    Zulässige Tokenzielgruppen Dieses Feld ist optional. Die konfigurierte Anwendungs-ID (Client) wird immer implizit als zulässige Zielgruppe angesehen. Wenn Ihre Anwendung eine API darstellt, die von anderen Clients aufgerufen wird, sollten Sie auch den Anwendungs-ID-URI hinzufügen, den Sie in der App-Registrierung konfiguriert haben. In der Liste der zulässigen Zielgruppen gilt ein Grenzwert von insgesamt 500 Zeichen.

    Der geheime Schlüssel wird als Slot-sticky Anwendungs-Einstellung mit dem NamenMICROSOFT_PROVIDER_AUTHENTICATION_SECRET gespeichert. 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.

  5. Wenn dies der erste Identitätsanbieter ist, der für die Anwendung konfiguriert wurde, wird auch ein Abschnitt mit den Einstellungen für die App-Dienst-Authentifizierung angezeigt. Andernfalls können Sie mit dem nächsten Schritt fortfahren.

    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.

  6. Klicken Sie auf Hinzufügen.

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.

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 nutzen, 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 ID 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 ID 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 Erstellen einer App-Registrierung in Microsoft Entra ID für Ihre App Service-App 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 ID 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 ID.
  • 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 ID 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 ID bereitgestellten Anleitungen ebenfalls aktualisiert werden.

Nächste Schritte