Untersuchen der Authentifizierung und Autorisierung in App Service

6 Minuten

Der Azure App Service bietet eine integrierte Authentifizierungs- und Autorisierungsunterstützung. Sie können Benutzer und Benutzerinnen anmelden und auf Daten zugreifen, indem Sie nur wenig oder keinen Code in Ihrer Web-App, RESTful-API, Ihrem mobilen Back-End oder Ihren Azure Functions schreiben.

Warum die eingebaute Authentifizierung verwenden?

Die Nutzung von App Service für die Authentifizierung und Autorisierung ist nicht verpflichtend. Viele Webframeworks sind mit Sicherheitsfunktionen gebündelt und können bei Bedarf verwendet werden. Wenn Sie mehr Flexibilität benötigen, als App Service bietet, können Sie auch eigene Hilfsprogramme schreiben.

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.

Mit Azure App Service können Sie verschiedene Authentifizierungsfunktionen in Ihre Web-App oder API integrieren, ohne sie selbst zu implementieren.
Auth ist direkt in die Plattform integriert und erfordert keine bestimmte Sprache, kein SDK, keine Sicherheitskenntnisse und keinen Code.
Sie können mit mehreren Anmelde-Anbietern integrieren. Beispiel: Microsoft Entra ID, Facebook, Google, X.

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
X	`/.auth/login/twitter`	App Service X-Anmeldung
Ein beliebiger OpenID Connect-Anbieter	`/.auth/login/<providerName>`	App Service OpenID Connect-Anmeldung
GitHub	`/.auth/login/github`	App Service: mit GitHub anmelden

Wenn Sie die Authentifizierung und Autorisierung mit einem dieser Anbieter aktivieren, 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.

Funktionsweise

Das Modul für Authentifizierung und Autorisierung wird in der gleichen Sandbox wie Ihr Anwendungscode ausgeführt. Wenn es aktiviert ist, wird es von allen eingehenden HTTP-Anforderungen durchlaufen, bevor diese an Ihren Anwendungscode übergeben werden. Dieses Modul erledigt einige Dinge für Ihre App:

Authentifizieren von Benutzerinnen und Benutzern und Clients mit dem angegebenen Identitätsanbieter
Überprüfen, Speichern und Aktualisieren von OAuth-Token, die vom konfigurierten Identitätsanbieter 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.

Hinweis

Unter Linux und in Containern wird das Modul für Authentifizierung und Autorisierung in einem separaten Container isoliert von Ihrem Anwendungscode ausgeführt. Da es nicht in einem Prozess ausgeführt wird, ist keine direkte Integration mit bestimmten Sprachframeworks möglich.

Authentifizierungsfluss

Der Authentifizierungsflow ist für alle Anbieter gleich, unterscheidet sich jedoch abhängig davon, ob die Anmeldung mit dem SDK des Anbieters erfolgen soll.

Ohne die Anbieter-SDK: Die Anwendung delegiert die Verbundanmeldung an App Service. Dies Delegierung ist normalerweise bei Browser-Apps der Fall, die den Benutzern und Benutzerinnen die Anmeldeseite des Anbieters anzeigen können. Der Servercode verwaltet den Anmeldeprozess und wird als servergesteuerter Fluss oder Serverfluss bezeichnet.
Mit Anbieter-SDK: Die Anwendung meldet die Benutzer*innen 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 und wird als clientgesteuerter Fluss oder Clientfluss bezeichnet. Dies gilt für REST-APIs, Azure Functions, JavaScript-Browserclients und native mobile Apps, die Benutzer mit dem SDK des Anbieters anmelden.

Die folgende Tabelle zeigt die Schritte des Authentifizierungsflows.

Schritt	Ohne Anbieter-SDK	Mit Anbieter-SDK
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.
Nachauthentifizierung	Anbieter leitet Client zu `/.auth/login/<provider>/callback` um.	Clientcode sendet Token des Anbieters zur Überprüfung an `/.auth/login/<provider>`.
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.
Bereitstellen von authentifiziertem Inhalt	Client schließt Authentifizierungscookie in nachfolgenden Anforderungen (die automatisch vom Browser verarbeitet werden) ein.	Clientcode stellt Authentifizierungstoken im `X-ZUMO-AUTH`-Header (der automatisch von Mobile Apps-Client-SDKs verarbeitet wird) 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

Im Azure-Portal können Sie App Service mit zahlreichen Verhaltensweisen konfigurieren, wenn eine eingehende Anforderung nicht authentifiziert ist.

Allow unauthenticated requests (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. Damit können Sie für Ihre Benutzer mehrere Anmeldungsanbieter bereitstellen.
Authentifizierung erforderlich: Mit dieser Option wird jeglicher nicht authentifizierte Datenverkehr an Ihre Anwendung abgelehnt. 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.

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.

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.

Protokollierung und Nachverfolgung

Wenn Sie die Anwendungsprotokollierung aktivieren, werden Ablaufverfolgungen für Authentifizierung und Autorisierung direkt in Ihren Protokolldateien gesammelt. Wenn ein unerwarteter Authentifizierungsfehler angezeigt wird, können Sie alle Details dazu problemlos in den vorhandenen Anwendungsprotokollen finden.