Authentifizierung und Autorisierung in Azure App Service und Azure Functions

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 ID, Facebook, Google, Twitter.

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 Identity Platform /.auth/login/aad Anmeldung bei App Service Microsoft-Identitätsplattform
Facebook /.auth/login/facebook App Service Facebook-Anmeldung
Google /.auth/login/google Google-Anmeldung App Service
Twitter /.auth/login/twitter App Service Twitter-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. 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.

An architecture diagram showing requests being intercepted by a process in the site sandbox which interacts with identity providers before allowing traffic to the deployed site

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.

Nicht-authentifizierte Anforderungen gestatten

Diese Option verweist die Autorisierung von nicht authentifiziertem Datenverkehr an Ihren Anwendungscode. 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.

Erfordern Sie die Authentifizierung

Diese Option wird den nicht-authentifizierten Datenverkehr für Ihre Anwendung ablehnen. Diese Ablehnung kann als eine Umleitungs-Aktion an einen der konfigurierten Identitäts-Anbietern stattfinden. In diesen Fällen wird ein Browser Client an /.auth/login/<provider> den von Ihnen gewählten Anbieter umgeleitet. 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 Sie ein HTTP 401 Unauthorized oder HTTP 403 Forbidden für alle Anforderungen ist.

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 ID konfigurieren, wenn Sie den Zugriff auf die Anwendung 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 der Microsoft Identity Platform finden Sie unter Grundlagen zur Autorisierung in der Microsoft Identity Platform.

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.

Überlegungen zur Verwendung von Azure Front Door

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

  1. Deaktivieren der Zwischenspeicherung für den Authentifizierungsworkflow

    Weitere Informationen zum Konfigurieren von Regeln in Azure Front Door zum Deaktivieren der Zwischenspeicherung für den Authentifizierungs- und Autorisierungsseiten finden Sie unter Deaktivieren des Caches für den Authentifizierungsworkflow.

  2. Verwenden des Front Door-Endpunkts 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.

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

Beispiele: