Authentifizierung und Autorisierung in Azure App Service und Azure Functions

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.

Azure App Service bietet integrierte Authentifizierungs- und Autorisierungsfunktionen (manchmal auch als "Easy Auth" bezeichnet), sowie Azure-Funktionen, sodass Sie Benutzer anmelden und auf Daten zugreifen können, indem Sie minimalen oder gar keinen Code in Ihrer Web-App, Ihrer RESTful-API und Ihrem mobilen Backend schreiben. In diesem Artikel wird beschrieben, wie App Service zur Vereinfachung der Authentifizierung und Autorisierung für Ihre App beiträgt.

Warum die eingebaute Authentifizierung verwenden?

Die Nutzung dieser Funktion für die Authentifizierung und Autorisierung ist nicht verpflichtend. Sie können die gebündelten Sicherheitsfeatures im Webframework Ihrer Wahl verwenden oder eigene Hilfsprogramme schreiben. Sie müssen jedoch sicherstellen, dass Ihre Lösung mit den neuesten Sicherheits-, Protokoll- und Browser-Aktualisierungen auf dem neuesten Stand bleibt.

Das Implementieren einer sicheren Lösung für die Authentifizierung (Anmeldung von Benutzern) und die Autorisierung (Zugriff auf sichere Daten) kann einen erheblichen Aufwand in Anspruch nehmen. Sie müssen sicherstellen, dass Sie die bewährten Methoden und Standards der Branche befolgen und ihre Implementierung auf dem neuesten Stand halten. Die integrierte Authentifizierungsfunktion für App Service und Azure Functions kann Ihnen Zeit und Mühe ersparen, indem sie eine sofort einsatzbereite Authentifizierung mit föderierten Identitätsanbietern bietet, sodass Sie sich auf den Rest Ihrer Anwendung konzentrieren können.

• Der Azure App Service ermöglicht es Ihnen, eine Vielzahl von Authentifizierungsfunktionen in Ihre Web-App oder API zu integrieren, ohne Sie selbst zu implementieren.
• Es ist direkt in die Plattform integriert und erfordert keine bestimmte Sprache, kein SDK, Sicherheitskenntnisse weder die Verwendung jeglichen Codes.
• Sie können mit mehreren Anmelde-Anbietern integrieren. Beispiel: Microsoft Entra, Facebook, Google, X.

Ihre App muss möglicherweise komplexere Szenarien wie Visual Studio-Integration oder inkrementelle Einwilligung unterstützen. Zur Unterstützung dieser Szenarien stehen verschiedene Authentifizierungslösungen zur Verfügung. Weitere Informationen finden Sie unter Identitätsszenarien.

Identitätsanbieter

App Service nutzt die Verbundidentität. Dabei werden die Benutzeridentitäten und der Authentifizierungsablauf von einem externen Identitätsanbieter für Sie verwaltet. Die folgenden Identitätsanbieter sind standardmäßig verfügbar:

Anbieter	Anmeldungsendpunkt	Leitfäden zur Vorgehensweise
Microsoft Entra	/.auth/login/aad	Plattformanmeldung für App Service Microsoft Entra
Facebook	/.auth/login/facebook	App Service Facebook-Anmeldung
Google	/.auth/login/google	Google-Anmeldung App Service
X	/.auth/login/x	App Service X-Anmeldung
GitHub	/.auth/login/github	App Service: mit GitHub anmelden
Mit Apple anmelden	/.auth/login/apple	App Service-Anmeldung: Mit Apple anmelden (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 dieses Features werden alle Anforderungen an Ihre Anwendung automatisch an HTTPS umgeleitet, unabhängig von der App Service-Konfigurationseinstellung zum Erzwingen von HTTPS. Sie können dies mit der requireHttps Einstellung in der V2-Konfiguration deaktivieren. Wir empfehlen jedoch die Verwendung von HTTPS, und Sie sollten sicherstellen, dass keine Sicherheits-Token jemals über nicht sichere HTTP-Verbindungen übertragen werden.

Der App Service kann zur Authentifizierung mit oder ohne Einschränkung des Zugriffs auf Ihre Website-Inhalte und APIs verwendet werden. Zugriffseinschränkungen können im Abschnitt Authentifizierung>Authentifizierungseinstellungen Ihrer Web-App festgelegt werden. Um den App-Zugriff nur auf authentifizierte Benutzer zu beschränken, legen Sie die Aktion fest, die ausgeführt werden soll, wenn die Anforderung nicht authentifiziert ist, um sich mit einem der konfigurierten Identitätsanbieter anzumelden. Um den Zugriff zu authentifizieren, aber nicht zu beschränken, setzen Sie die Aktion bei nicht authentifizierter Anforderung auf „Anonyme Anforderungen zulassen (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 diese Vorgehensweise dabei helfen, Probleme zu verhindern, die sich auf die Produktions-App auswirken können.

Funktionsweise

Featurearchitektur

Authentifizierungsablauf

Autorisierungsverhalten

Tokenspeicher

Protokollierung und Ablaufverfolgung

Featurearchitektur

Die Middlewarekomponente für die Authentifizierung und Autorisierung ist ein Feature der Plattform, die auf derselben VM wie Ihre Anwendung ausgeführt wird. Wenn diese Komponente aktiviert ist, wird sie von allen eingehenden HTTP-Anforderungen durchlaufen, bevor diese von Ihrer Anwendung verarbeitet werden.

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

• Authentifizieren von Benutzern und Clients mit den angegebenen Identitätsanbietern
• Überprüfen, Speichern und Aktualisieren von OAuth-Tokens, die von den konfigurierten Identitätsanbietern ausgestellt wurden
• Verwaltung der authentifizierten Sitzung
• Einfügen von Identitätsinformationen in HTTP-Anforderungsheader

Das Modul wird separat von Ihrem Anwendungscode ausgeführt und kann über die Azure Resource Manager-Einstellungen oder per Konfigurationsdatei konfiguriert werden. Weder SDKs noch bestimmte Programmiersprachen oder Änderungen am Anwendungscode sind erforderlich.

Funktionsarchitektur unter Windows (Nicht-Container-Einsatz)

Das Modul für die Authentifizierung und Autorisierung wird als natives IIS-Modul in derselben Sandbox wie Ihre Anwendung ausgeführt. Wenn diese Komponente aktiviert ist, wird sie von allen eingehenden HTTP-Anforderungen durchlaufen, bevor diese von Ihrer Anwendung verarbeitet werden.

Funktions-Architektur für Linux und Container

Das Modul für Authentifizierung und Autorisierung wird in einem separaten Container isoliert von Ihrem Anwendungscode ausgeführt. Über das sogenannte Botschaftermuster interagiert es mit dem eingehenden Datenverkehr, um ähnliche Funktionen wie unter Windows auszuführen. Da es nicht in einem Prozess ausgeführt wird, ist keine direkte Integration in bestimmte Sprachframeworks möglich. Die relevanten Informationen für Ihre App werden jedoch wie unten erläutert mithilfe von Anforderungsheadern weitergeleitet.

Authentifizierungsfluss

Der Authentifizierungsablauf gilt für alle Anbieter, unterscheidet sich jedoch abhängig davon, ob die Anmeldung mit dem SDK des Anbieters erfolgen soll:

• Ohne Anbieter-SDK: Die Anwendung delegiert die Verbundanmeldung an App Service. Dies ist normalerweise bei Browser-Apps der Fall, die dem Benutzer die Anmeldeseite des Anbieters anzeigen können. Der Servercode verwaltet den Anmeldevorgang, daher wird er auch als servergesteuerter Datenfluss oder Serverfluss bezeichnet. Dieser Fall gilt für Browser- und mobile Apps, die zur Authentifizierung einen eingebetteten Browser verwenden.
• Mit Anbieter-SDK: Die Anwendung meldet den Benutzer manuell beim Anbieter an und sendet dann das Authentifizierungstoken zur Überprüfung an App Service. Dies ist normalerweise bei Apps ohne Browser der Fall, die dem Benutzer die Anmeldeseite des Anbieters nicht anzeigen können. Der Anwendungscode verwaltet den Anmeldevorgang, daher wird er auch als clientgesteuerter Datenfluss oder Clientfluss bezeichnet. Dieser Fall gilt für REST-APIs Azure Functions und JavaScript-Browserclients sowie Browser-Apps, die eine höhere Flexibilität beim Anmeldevorgang erfordern. Er gilt auch für native mobile Apps, die Benutzer mithilfe des Anbieter-SDKs anmelden.

Bei Aufrufen aus einer vertrauenswürdigen Browser-App in App Service an eine weitere REST-API in App Service oder Azure Functions kann über den servergesteuerten Datenfluss authentifiziert werden. Weitere Informationen finden Sie unter Anpassen von An- und Abmeldungen.

Die folgende Tabelle zeigt die Schritte des Authentifizierungsablaufs.

Schritt	Ohne Anbieter-SDK	Mit Anbieter-SDK
1. Anmeldung des Benutzers	Client wird zu /.auth/login/<provider> umgeleitet.	Clientcode meldet Benutzer direkt mit dem Anbieter-SDK an und erhält ein Authentifizierungstoken. Informationen finden Sie in der Dokumentation des Anbieters.
2. Nachauthentifizierung	Anbieter leitet Client zu /.auth/login/<provider>/callback um.	Clientcode sendet Token des Anbieters zur Überprüfung an /.auth/login/<provider>.
3. Einrichten der authentifizierten Sitzung	App Service fügt der Antwort ein authentifiziertes Cookie hinzu.	App Service gibt das eigene Authentifizierungstoken an den Clientcode zurück.
4. Bereitstellen von authentifiziertem Inhalt	Client schließt Authentifizierungscookie in nachfolgenden Anforderungen (die automatisch vom Browser verarbeitet werden) ein.	Der Clientcode stellt das Authentifizierungstoken im X-ZUMO-AUTH-Header bereit.

Für Clientbrowser kann App Service alle nicht authentifizierten Benutzer automatisch an /.auth/login/<provider> weiterleiten. Sie können Benutzern auch einen oder mehrere /.auth/login/<provider>-Links zur Anmeldung bei Ihrer App mit dem Anbieter ihrer Wahl bereitstellen.

Autorisierungsverhalten

Wichtig

Standardmäßig bietet dieses Feature nur die Authentifizierung, nicht die Autorisierung. Möglicherweise muss Ihre Anwendung zusätzlich zu den hier konfigurierten Überprüfungen noch Autorisierungsentscheidungen treffen.

Im Azure-Portal können Sie die App Service-Autorisierung mit einer Reihe von Verhaltensweisen konfigurieren, wenn eine eingehende Anforderung nicht authentifiziert ist. Die folgenden Überschriften beschreiben die Optionen.

Zugriff beschränken

• Nicht authentifizierte Anforderungen zulassen Mit dieser Option wird die Autorisierung von nicht authentifiziertem Datenverkehr in den Anwendungscode verschoben. Für authentifizierte Anforderungen übergibt 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 authentifizierter Datenverkehr an Ihre Anwendung abgelehnt. Eine bestimmte auszuführende Aktion wird im Abschnitt Nicht authentifizierte Anforderungen angegeben.

  Mit dieser Option müssen Sie in Ihrer App keinen Authentifizierungscode schreiben. Eine genauere Autorisierung, z.B. rollenspezifische Autorisierung, kann durch das Untersuchen der Ansprüche des Benutzers durchgeführt werden (siehe Zugriff auf Benutzeransprüche).

  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.

  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.

Nicht authentifizierte Anforderungen

• HTTP 302 Gefundene Umleitung: empfohlen für Websites Leitet eine 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 Wenn die anonyme Anforderung von einer nativen mobilen App stammt, wird HTTP 401 Unauthorized als Antwort zurückgegeben. Sie können die Ablehnung auch so konfigurieren, dass die Fehlermeldung HTTP 401 Unauthorized für alle Anforderungen angezeigt wird.
• 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 die Fehlermeldung HTTP 404 Not found für alle Anforderungen angezeigt wird.

Tokenspeicher

App Service bietet einen integrierten Tokenspeicher. Dabei handelt es sich um ein Repository mit 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 Auftrag des Benutzers auf Daten dieser Anbieter zugreifen muss, z.B um:

• Beiträge in der Facebook-Chronik des authentifizierten Benutzers zu veröffentlichen
• Lesen der Unternehmensdaten des Benutzers mit der Microsoft Graph-API

In der Regel müssen Sie Code schreiben, um diese Token in Ihrer Anwendung zu erfassen, speichern und aktualisieren. 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-, Zugriffs- und Aktualisierungstoken werden für die authentifizierte Sitzung zwischengespeichert und sind nur für den zugehörigen Benutzer zugänglich.

Wenn Sie in Ihrer App nicht mit Token arbeiten müssen, können Sie auf der Seite Authentifizierung/Autorisierung Ihrer App den Tokenspeicher deaktivieren.

Protokollierung und Nachverfolgung

Wenn Sie die Anwendungsprotokollierung aktivieren, werden Ablaufverfolgungen für Authentifizierung und Autorisierung direkt in den Protokolldateien angezeigt. Wenn ein unerwarteter Authentifizierungsfehler angezeigt wird, können Sie alle Details dazu problemlos in den vorhandenen Anwendungsprotokollen finden. Wenn Sie die Ablaufverfolgung für Anforderungsfehler aktivieren, sehen Sie genau, welche Rolle das Modul für Authentifizierung und Autorisierung möglicherweise bei einer fehlgeschlagenen Anforderung gespielt hat. Suchen Sie in den Ablaufverfolgungsprotokollen nach Verweisen auf ein Modul namens EasyAuthModule_32/64.

Eindämmen der websiteübergreifenden Anforderungsfälschung (Cross-Site Request Forgery, CSRF)

Die App Service-Authentifizierung dämmt die CSRF ein, indem Clientanforderungen auf die folgenden Bedingungen überprüft werden:

• Es handelt sich um eine POST-Anforderung, die mithilfe eines Sitzungscookies authentifiziert wurde.
• Die Anforderung stammt aus einem bekannten Browser (durch den HTTP-Header User-Agent bestimmt).
• Der HTTP-Header Origin oderReferer fehlt oder befindet sich nicht in der konfigurierten Liste der genehmigten externen Domänen für die Umleitung.
• Der HTTP-Header Origin fehlt oder befindet sich nicht in der konfigurierten Liste der CORS-Ursprünge.

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

Überlegungen zur Verwendung von Azure Front Door

Wenn Sie Azure App Service mit der Authentifizierung hinter Azure Front Door oder anderen Reverseproxys verwenden, sind einige zusätzliche Dinge zu beachten.

• Deaktivieren Sie die Front Door-Zwischenspeicherung für den Authentifizierungsworkflow.

• Verwenden Sie den Front Door-Endpunkt für Umleitungen.

  App Service ist normalerweise nicht direkt zugänglich, wenn es über Azure Front Door verfügbar gemacht wird. Dies kann beispielsweise verhindert werden, indem App Service über Private Link in Azure Front Door Premium verfügbar gemacht wird. Um zu verhindern, dass der Authentifizierungsworkflow den Datenverkehr direkt zu App Service umleitet, müssen Sie die Anwendung so konfigurieren, dass sie zu https://<front-door-endpoint>/.auth/login/<provider>/callback umleitet.

• Sicherstellen, dass App Service den richtigen Umleitungs-URI verwendet

  In einigen Konfigurationen verwendet App Service den App Service-FQDN als Umleitungs-URI anstelle des Front Door-FQDN. Dies führt zu einem Problem, wenn der Kunde anstelle von Front Door an App Service umgeleitet wird. Um dies zu ändern, muss die forwardProxy-Einstellung auf Standard festgelegt werden, damit App Service den von Azure Front Door festgelegten X-Forwarded-Host-Header berücksichtigt.

  Andere Reverseproxys wie Azure Application Gateway oder Produkte von Drittanbietern verwenden möglicherweise andere Header und benötigen eine andere forwardProxy-Einstellung.

  Diese Konfiguration kann derzeit nicht über das Azure-Portal durchgeführt werden und muss über az rest erfolgen:

  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"
    }
  }
  

  und stellen Sie sicher, dass convention auf Standard festgelegt ist, damit der von Azure Front Door verwendete X-Forwarded-Host-Header berücksichtigt wird.

  Importieren von Einstellungen

  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 Ressourcen

• Vorgehensweise: Konfigurieren Ihres App Services oder der Azure Functions-App für die Verwendung der Microsoft Entra-Anmeldung
• Anpassen von An- und Abmeldungen

• Arbeiten mit OAuth-Token bei der Azure App Service-Authentifizierung
• Verwenden von Benutzeridentitäten bei der Azure App Service-Authentifizierung
• Dateibasierte Konfiguration

Beispiele:

• Tutorial: Hinzufügen der Authentifizierung zu Ihrer Web-App in Azure App Service
• Tutorial: Umfassendes Authentifizieren und Autorisieren von Benutzern in Azure App Service (Windows oder Linux)
• .NET Core-Integration von Azure AppService EasyAuth (Drittanbieter)
• Azure App Service-Authentifizierung mit .NET Core (Drittanbieter)