Authentifizierung und Autorisierung in Azure App Service und Azure Functions

2025-04-24

Azure App Service bietet integrierte Authentifizierungsfunktionen (Anmelden von Benutzern) und Autorisierung (Zugriff auf sichere Daten). Diese Funktionen werden manchmal als Easy Auth bezeichnet. Sie können sie verwenden, um Benutzer anzumelden und auf Daten zuzugreifen, indem Sie wenig oder keinen Code in Ihrer Web-App, RESTful-API, mobilen Server und Funktionen schreiben.

In diesem Artikel wird beschrieben, wie App Service zur Vereinfachung der Authentifizierung und Autorisierung für Ihre App beiträgt.

Gründe für die Verwendung der integrierten Authentifizierung

Um Authentifizierung und Autorisierung zu implementieren, können Sie die gebündelten Sicherheitsfeatures in Ihrem Webframework ihrer Wahl verwenden oder Eigene Tools schreiben. Die Implementierung einer sicheren Lösung für die Authentifizierung und Autorisierung kann erhebliche Anstrengungen erfordern. Sie müssen die bewährten Methoden und Standards der Branche einhalten. Außerdem müssen Sie sicherstellen, dass Ihre Lösung mit den neuesten Sicherheits-, Protokoll- und Browserupdates auf dem neuesten Stand bleibt.

Die integrierten Funktionen von App Service und Azure Functions können Ihnen Zeit und Mühe sparen, indem Sie die sofort einsatzbereite Authentifizierung mit Verbundidentitätsanbietern bereitstellen, damit Sie sich auf den Rest Ihrer Anwendung konzentrieren können.

Mit App Service können Sie Authentifizierungsfunktionen in Ihre Web-App oder API integrieren, ohne sie selbst zu implementieren. Dieses Feature ist direkt in die Plattform integriert und erfordert keine bestimmte Sprache, sdk, Sicherheitskompetenz oder Code. Sie können sie in mehrere Anmeldeanbieter integrieren, z. B. Microsoft Entra, Facebook, Google und X.

Ihre App muss möglicherweise komplexere Szenarien unterstützen, z. B. visual Studio-Integration oder inkrementelle Zustimmung. Zur Unterstützung dieser Szenarien stehen mehrere Authentifizierungslösungen zur Verfügung. Weitere Informationen finden Sie unter Authentifizierungsszenarien und Empfehlungen.

Identitätsanbieter

Der App-Dienst verwendet Verbundidentität. Ein Microsoft- oder Nicht-Microsoft-Identitätsanbieter verwaltet die Benutzeridentitäten und den Authentifizierungsfluss für Sie. Die folgenden Identitätsanbieter sind standardmäßig verfügbar:

Anbieter	Anmeldungsendpunkt	Leitfäden zur Vorgehensweise
Microsoft Entra	`/.auth/login/aad`	Anmeldung der Microsoft Entra-Plattform für App Service
Facebook	`/.auth/login/facebook`	App Service Facebook-Anmeldung
Googeln	`/.auth/login/google`	App Service Google-Anmeldung
X	`/.auth/login/x`	App Service X-Anmeldung
GitHub (Englisch)	`/.auth/login/github`	App-Dienst-GitHub-Anmeldung
Apfel	`/.auth/login/apple`	App Service-Anmeldung über Apple-Anmeldung (Vorschau)
Ein beliebiger OpenID Connect-Anbieter	`/.auth/login/<providerName>`	App Service OpenID Connect-Anmeldung

Wenn Sie dieses Feature mit einem dieser Anbieter konfigurieren, ist der entsprechende Anmeldungsendpunkt für die Benutzerauthentifizierung und die Überprüfung von Authentifizierungstoken vom Anbieter verfügbar. Sie können Ihren Benutzern problemlos eine beliebige Anzahl von diesen Anmeldeoptionen bereitstellen.

Überlegungen zur Verwendung der integrierten Authentifizierung

Durch aktivieren der integrierten Authentifizierung werden alle Anforderungen an Ihre Anwendung automatisch an HTTPS umgeleitet, unabhängig von der Konfigurationseinstellung des App-Diensts, um HTTPS zu erzwingen. Sie können diese automatische Umleitung mithilfe der requireHttps Einstellung in der V2-Konfiguration deaktivieren. Es wird jedoch empfohlen, HTTPS weiterhin zu verwenden und sicherzustellen, dass keine Sicherheitstoken über nicht unsichere HTTP-Verbindungen übertragen werden.

Sie können App Service für die Authentifizierung mit oder ohne Einschränkung des Zugriffs auf Ihre Websiteinhalte und APIs verwenden. Festlegen von Zugriffseinschränkungen im Abschnitt Einstellungen>Authentifizierung>Authentifizierungseinstellungen Ihrer Web-App:

Um den App-Zugriff auf nur authentifizierte Benutzer einzuschränken, legen Sie die Aktion fest, die ausgeführt werden soll, wenn die Anforderung nicht authentifiziert wird , um sich bei einem der konfigurierten Identitätsanbieter anzumelden.
Um den Zugriff zu authentifizieren, aber nicht einzuschränken, legen Sie die Auszuführende Aktion fest, wenn die Anforderung nicht authentifiziert ist, um anonyme Anforderungen zuzulassen (keine Aktion).

Wichtig

Sie sollten jeder App-Registrierung eine eigene Erlaubnis und Zustimmung geben. Vermeiden Sie das Teilen von Berechtigungen zwischen Umgebungen, indem Sie separate App-Registrierungen für gesonderte Bereitstellungsslots verwenden. Wenn Sie neuen Code testen, kann dies dazu beitragen, probleme zu verhindern, die sich auf die Produktions-App auswirken.

Funktionsweise

Featurearchitektur

Die Authentifizierungs- und Autorisierungs-Middleware-Komponente ist ein Feature der Plattform, die auf demselben virtuellen Computer wie Ihre Anwendung ausgeführt wird. Wenn Sie sie aktivieren, durchläuft jede eingehende HTTP-Anforderung diese Komponente, bevor die Anwendung sie behandelt.

Von der Middleware der Plattform werden mehrere Vorgänge für Ihre App durchgeführt:

Authentifiziert Benutzer und Clients mit den angegebenen Identitätsanbietern
Überprüft, speichert und aktualisiert OAuth-Token, die von den konfigurierten Identitätsanbietern ausgestellt wurden.
Verwaltung der authentifizierten Sitzung
Einfügen von Identitätsinformationen in HTTP-Anforderungsheader

Das Modul wird separat vom Anwendungscode ausgeführt. Sie können sie mithilfe von Azure Resource Manager-Einstellungen oder mithilfe einer Konfigurationsdatei konfigurieren. Weder SDKs noch bestimmte Programmiersprachen oder Änderungen am Anwendungscode sind erforderlich.

Funktionsarchitektur unter Windows (Bereitstellung ohne Container)

Das Modul für die Authentifizierung und Autorisierung wird als natives IIS-Modul in derselben Sandbox wie Ihre Anwendung ausgeführt. Wenn Sie sie aktivieren, durchläuft jede eingehende HTTP-Anforderung sie, bevor ihre Anwendung sie behandelt.

Funktions-Architektur für Linux und Container

Das Authentifizierungs- und Autorisierungsmodul wird in einem separaten Container ausgeführt, der von Ihrem Anwendungscode isoliert ist. Das Modul verwendet das Botschaftermuster , um mit dem eingehenden Datenverkehr zu interagieren, um ähnliche Funktionen wie unter Windows auszuführen. Da es nicht im Prozess läuft, ist keine direkte Integration mit spezifischen Sprach-Frameworks möglich. Die relevanten Informationen, die Ihre App benötigt, werden jedoch in Anforderungsheadern übergeben.

Authentifizierungsfluss

Der Authentifizierungsfluss ist für alle Anbieter identisch. Es unterscheidet sich je nachdem, ob Sie sich mit dem SDK des Anbieters anmelden möchten:

Ohne Anbieter-SDK: Die Anwendung delegiert die Verbundanmeldung an App Service. Diese Delegierung ist in der Regel bei Browser-Apps der Fall, die dem Benutzer die Anmeldeseite des Anbieters präsentieren können. Der Servercode verwaltet den Anmeldeprozess, sodass er auch als servergesteuerter Fluss oder Serverfluss bezeichnet wird.

Dieser Fall gilt für Browser- und mobile Apps, die zur Authentifizierung einen eingebetteten Browser verwenden.
Mit dem Anbieter-SDK: Die Anwendung meldet sich manuell beim Anbieter an. Anschließend sendet es das Authentifizierungstoken zur Überprüfung an App Service. Dieser Vorgang ist in der Regel bei browserlosen Apps der Fall, was dem Benutzer die Anmeldeseite des Anbieters nicht präsentieren kann. Der Anwendungscode verwaltet den Anmeldeprozess, sodass er auch als clientgesteuerter Fluss oder Clientfluss bezeichnet wird.

Dieser Fall gilt auch für REST-APIs, Azure Functions und JavaScript-Browserclients, zusätzlich zu Browser-Apps, die mehr Flexibilität im Anmeldeprozess benötigen. Sie gilt auch für systemeigene mobile Apps, die Benutzer mithilfe des SDK des Anbieters anmelden.

Aufrufe einer vertrauenswürdigen Browser-App in App Service zu einer anderen REST-API in App Service oder Azure Functions können über den servergesteuerten Fluss authentifiziert werden. Weitere Informationen finden Sie unter Anpassen der Anmeldung und Abmeldung in der Azure App Service-Authentifizierung.

Die folgende Tabelle zeigt die Schritte des Authentifizierungsflows.

Schritt	Ohne Anbieter-SDK	Mit Anbieter-SDK
1. Melden Sie sich beim Benutzer an	Der Anbieter leitet den Client zu `/.auth/login/<provider>`.	Der Client-Code meldet den Benutzer direkt über das SDK des Anbieters an und empfängt ein Authentifizierungstoken. Weitere Informationen finden Sie in der Dokumentation des Anbieters.
2. Durchführen der Nachauthentifizierung	Der Anbieter leitet den Client zu `/.auth/login/<provider>/callback`.	Clientcode stellt das Token vom Anbieter`/.auth/login/<provider>` zur Überprüfung bereit.
3. Einrichten einer authentifizierten Sitzung	Der App-Dienst fügt der Antwort ein authentifiziertes Cookie hinzu.	Der App-Dienst gibt ein eigenes Authentifizierungstoken an den Clientcode zurück.
4. Bereitstellen von authentifiziertem Inhalt	Client schließt ein Authentifizierungscookie in nachfolgenden Anforderungen (die automatisch vom Browser verarbeitet werden) ein.	Clientcode stellt das Authentifizierungstoken im `X-ZUMO-AUTH` Header dar.

Für Clientbrowser kann App Service alle nicht authentifizierten Benutzer automatisch an /.auth/login/<provider> weiterleiten. Sie können Benutzern auch einen Link oder mehrere /.auth/login/<provider> Links anzeigen, um sich bei Ihrer App anzumelden, indem sie ihren bevorzugten Anbieter nutzen.

Autorisierungsverhalten

Im Azure-Portal können Sie App Service mit verschiedenen Verhaltensweisen konfigurieren, wenn eine eingehende Anforderung nicht authentifiziert wird. In den folgenden Abschnitten werden die Optionen beschrieben.

Wichtig

Standardmäßig bietet dieses Feature nur Authentifizierung und keine Autorisierung. Ihre Anwendung muss möglicherweise noch Autorisierungsentscheidungen treffen, zusätzlich zu den hier konfigurierten Prüfungen.

Eingeschränkter Zugriff

Nicht authentifizierte Anforderungen zulassen: Mit dieser Option wird die Autorisierung von nicht authentifiziertem Datenverkehr in den Anwendungscode verschoben. Für authentifizierte Anforderungen übermittelt der App Service auch Authentifizierungsinformationen in den HTTP-Headern.

Diese Option bietet mehr Flexibilität bei der Verarbeitung anonymer Anforderungen. Beispielsweise können Sie für Ihre Benutzer mehrere Anmeldungsanbieter bereitstellen. Sie müssen jedoch Code schreiben.
Authentifizierung erforderlich: Mit dieser Option wird jeglicher nicht authentifizierte Datenverkehr an Ihre Anwendung abgelehnt. Eine bestimmte auszuführende Aktion wird im Abschnitt Nicht authentifizierte Anforderungen weiter unten in diesem Artikel angegeben.

Mit dieser Option müssen Sie in Ihrer App keinen Authentifizierungscode schreiben. Sie können eine feinere Autorisierung behandeln, z. B. rollenspezifische Autorisierung, indem Sie die Ansprüche des Benutzers prüfen.

Achtung

Das Einschränken des Zugriffs auf diese Weise gilt für alle Aufrufe Ihrer App, was für Apps, die eine öffentlich verfügbare Startseite wünschen, eventuell nicht wünschenswert ist, wie bei vielen Single-Page-Anwendungen. Wenn Ausnahmen erforderlich sind, müssen Sie ausgeschlossene Pfade in einer Konfigurationsdatei konfigurieren.

Hinweis

Wenn Sie den Microsoft-Identitätsanbieter für Benutzer in Ihrer Organisation verwenden, ist das Standardverhalten, dass jeder Benutzer in Ihrem Microsoft Entra-Mandanten ein Token für Ihre Anwendung anfordern kann. Sie können die Anwendung in Microsoft Entra konfigurieren, wenn Sie den Zugriff auf Ihre App auf eine bestimmte Gruppe von Benutzern beschränken möchten. App Service bietet auch einige grundlegende integrierte Autorisierungsprüfungen, die bei einigen Validierungen helfen können. Weitere Informationen zur Autorisierung in Microsoft Entra finden Sie unter Grundlagen zur Autorisierung in Microsoft Entra.

Wenn Sie den Microsoft-Identitätsanbieter für Benutzer in Ihrer Organisation verwenden, ist das Standardverhalten, dass jeder Benutzer in Ihrem Microsoft Entra-Mandanten ein Token für Ihre Anwendung anfordern kann. Sie können die Anwendung in Microsoft Entra konfigurieren, wenn Sie den Zugriff auf Ihre App auf eine bestimmte Gruppe von Benutzern beschränken möchten. App Service bietet auch einige grundlegende integrierte Autorisierungsprüfungen , die bei einigen Überprüfungen hilfreich sein können. Weitere Informationen zur Autorisierung in Microsoft Entra finden Sie unter Grundlagen zur Autorisierung in Microsoft Entra.

Nicht authentifizierte Anfragen

HTTP 302 Found redirect: Empfohlen für Websites: Leitet die Aktion an einen der konfigurierten Identitätsanbieter um. In diesen Fällen wird ein Browser Client an /.auth/login/<provider> den von Ihnen gewählten Anbieter umgeleitet.
HTTP 401 Nicht autorisiert: Empfohlen für APIs: Gibt eine HTTP 401 Unauthorized Antwort zurück, wenn die anonyme Anforderung von einer nativen mobilen App stammt. Sie können die Ablehnung auch so konfigurieren, dass sie HTTP 401 Unauthorized für alle Anforderungen ist.
HTTP 403 Verboten: Konfiguriert die Ablehnung so, dass die Fehlermeldung HTTP 403 Forbidden für alle Anforderungen angezeigt wird.
HTTP 404 Nicht gefunden: Konfiguriert die Ablehnung so, dass sie für HTTP 404 Not found alle Anfragen gilt.

Tokenspeicher

Der App-Dienst stellt einen integrierten Tokenspeicher bereit. Ein Tokenspeicher ist ein Repository von Token, die den Benutzern Ihrer Web-Apps, APIs oder nativen mobilen Apps zugeordnet sind. Wenn Sie die Authentifizierung für jeden Anbieter aktivieren, ist dieser Tokenspeicher sofort für Ihre App verfügbar.

Wenn Ihr Anwendungscode im Namen des Benutzers auf Daten von diesen Anbietern zugreifen muss, müssen Sie in der Regel Code schreiben, um diese Token in Ihrer Anwendung zu sammeln, zu speichern und zu aktualisieren. Aktionen können Folgendes umfassen:

Posten Sie auf der Facebook-Zeitachse des authentifizierten Benutzers.
Lesen Sie die Unternehmensdaten des Benutzers mithilfe der Microsoft Graph-API.

Mit dem Tokenspeicher rufen Sie die Token bei Bedarf einfach ab und weisen App Service an, sie zu aktualisieren, wenn sie ungültig werden.

Die ID-Token, Zugriffstoken und Aktualisierungstoken werden für die authentifizierte Sitzung zwischengespeichert. Nur der zugeordnete Benutzer kann darauf zugreifen.

Wenn Sie nicht mit Token in Ihrer App arbeiten müssen, können Sie den Tokenspeicher auf derEinstellungsauthentifizierungsseite> Ihrer App deaktivieren.

Protokollierung und Nachverfolgung

Wenn Sie die Anwendungsprotokollierung aktivieren, werden Authentifizierungs- und Autorisierungsüberwachungen direkt in Ihren Protokolldateien angezeigt. Wenn ein unerwarteter Authentifizierungsfehler angezeigt wird, können Sie alle Details dazu problemlos in den vorhandenen Anwendungsprotokollen finden.

Wenn Sie die Ablaufverfolgung fehlgeschlagener Anforderungen aktivieren, können Sie genau sehen, welche Rolle das Authentifizierungs- und Autorisierungsmodul in einer fehlgeschlagenen Anforderung spielen kann. Suchen Sie in den Ablaufverfolgungsprotokollen nach Verweisen auf ein Modul namens EasyAuthModule_32/64.

Entschärfung der websiteübergreifenden Anforderungsverfälschung

Die App-Dienstauthentifizierung verringert die websiteübergreifende Anforderungsfälschung, indem Clientanforderungen auf die folgenden Bedingungen überprüft werden:

Es handelt sich um eine POST Anforderung, die über ein Sitzungs-Cookie authentifiziert wurde.
Die Anforderung stammt aus einem bekannten Browser, wie vom HTTP-Header User-Agent bestimmt.
Origin- oder Referer-HTTP-Header fehlt oder befindet sich nicht in der konfigurierten Liste der genehmigten externen Domänen für die Weiterleitung.
Der HTTP-Header Origin fehlt oder ist nicht in der konfigurierten Liste der Ursprünge für Cross-Origin Resource Sharing (CORS) enthalten.

Wenn eine Anforderung alle diese Bedingungen erfüllt, lehnt die App Service-Authentifizierung sie automatisch ab. Sie können diese Entschärfungslogik umgehen, indem Sie Ihre externe Domäne zur Umleitungsliste in den Einstellungen>Authentifizierung>Authentifizierungseinstellungen bearbeiten>Zulässige externe Umleitungs-URLs hinzufügen.

Überlegungen zur Verwendung von Azure Front Door

Wenn Sie Azure App Service mit Authentifizierung hinter Azure Front Door oder anderen Reverseproxys verwenden, sollten Sie die folgenden Aktionen in Betracht ziehen.

Deaktivieren der Zwischenspeicherung von Azure Front Door

Deaktivieren Sie die Zwischenspeicherung von Azure Front Door für den Authentifizierungsworkflow.

Verwenden des Azure Front Door-Endpunkts für Umleitungen

Der App-Dienst kann in der Regel nicht direkt zugänglich sein, wenn er von Azure Front Door verfügbar gemacht wird. Sie können dieses Verhalten z. B. verhindern, indem Sie App Service mithilfe von Azure Private Link in Azure Front Door Premium verfügbarmachen. Um zu verhindern, dass der Authentifizierungsworkflow den Datenverkehr direkt zurück zum App-Dienst umleitet. Weitere Informationen finden Sie unter Umleitungs-URI.

Sicherstellen, dass App Service den richtigen Umleitungs-URI verwendet

In einigen Konfigurationen verwendet App Service den vollqualifizierten Domänennamen (FQDN) als Umleitungs-URI anstelle des Azure Front Door-FQDN. Diese Konfiguration verursacht ein Problem, wenn der Client anstelle von Azure Front Door zu App Service umgeleitet wird. Um dies zu ändern, legen Sie forwardProxy auf Standard fest, damit der App-Dienst den von Azure Front Door festgelegten X-Forwarded-Host-Header respektiert.

Andere Reverseproxys, z. B. Azure Application Gateway oder Nicht-Microsoft-Produkte, verwenden möglicherweise unterschiedliche Header und benötigen eine andere forwardProxy Einstellung.

Sie können die forwardProxy Konfiguration nicht über das Azure-Portal ändern. Sie müssen az rest verwenden

Exporteinstellungen

az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method get > auth.json

Aktualisieren der Einstellungen

Suchen nach:

"httpSettings": {
  "forwardProxy": {
    "convention": "Standard"
  }
}

Stellen Sie sicher, dass convention auf Standard gesetzt ist, um den X-Forwarded-Host-Header zu berücksichtigen, den Azure Front Door verwendet.

Importeinstellungen

az rest --uri /subscriptions/REPLACE-ME-SUBSCRIPTIONID/resourceGroups/REPLACE-ME-RESOURCEGROUP/providers/Microsoft.Web/sites/REPLACE-ME-APPNAME/config/authsettingsV2?api-version=2020-09-01 --method put --body @auth.json

Weitere Informationen zur App Service-Authentifizierung finden Sie unter:

Beispiele finden Sie unter:

Schnellstart: Hinzufügen der App-Authentifizierung zu Ihrer Web-App, die auf Azure App Service ausgeführt wird
Tutorial: Benutzer durchgehend in Azure App Service authentifizieren und autorisieren
.NET Core-Integration von Azure AppService Easy Auth (Nicht-Microsoft GitHub-Inhalte)
Einrichten der Azure App Service-Authentifizierung mit .NET Core (Nicht von Microsoft stammende GitHub-Inhalte)

Freigeben über