Implementieren Sie die einmalige Anmeldung von nativen Apps zu eingebetteten Webansichten

Gilt für: Grüner Kreis mit einem weißen Häkchensymbol, das angibt, dass der folgende Inhalt für externe Mandanten gilt. Externe Mandanten (weitere Informationen)

Wenn Ihre mobile App webbasierte Features wie eine Profilaktualisierungsseite oder ein Rewards-Dashboard enthält, erwarten Benutzer eine nahtlose Einmalige Anmeldung. Sie sollten nicht auf eine zweite Anmeldeaufforderung stoßen, nachdem sie sich bereits über die systemeigene App angemeldet haben.

In diesem Artikel wird erläutert, wie Sie einmaliges Anmelden (Single Sign-On, SSO) zwischen einer nativen mobilen Anwendung und einer Webressource implementieren, die in einer eingebetteten Webansicht gehostet wird (z WKWebView . B. unter iOS oder WebView unter Android). Im Gegensatz zu Systembrowsern können Sie mit eingebetteten Webansichten Netzwerkanforderungen bearbeiten, bevor sie gesendet werden. Mit dieser Funktion kann Ihre App den Authentifizierungsstatus des Benutzers direkt in Anforderungsheader einfügen.

Der empfohlene Fluss funktioniert wie folgt:

  1. Der Benutzer meldet sich über die systemeigene Benutzeroberfläche der mobilen App mit dem Native Auth SDK oder der nativen Authentifizierungs-API an.
  2. Vor dem Laden der Webansicht ruft die App ein gültiges Zugriffstoken aus dem SDK oder der API ab.
  3. Die App lädt die Webansicht mit einer benutzerdefinierten Anforderung, die das Zugriffstoken im Authorization: Bearer <access_token> Header enthält.
  4. Die Webressource überprüft das Token und gewährt sofort Zugriff.

Das folgende Diagramm zeigt die Interaktion zwischen Der Webressource, der mobilen App, dem SDK und dem Identitätsdienst (ESTS):

Sequenzdiagramm mit dem SSO-Fluss, in dem sich die mobile App über DAS SDK anmeldet, Token empfängt und die Webansicht mit dem Zugriffstoken im Autorisierungsheader lädt.

Voraussetzungen

Anmelden mit systemeigener Authentifizierung

Schließen Sie den Standardanmeldungsfluss mit dem nativen Authentifizierungs-SDK oder der systemeigenen Authentifizierungs-API ab. Wenn die Anmeldung erfolgreich das SDK verwendet, werden das Zugriffstoken, das ID-Token und das Aktualisierungstoken sicher zwischengespeichert. Wenn Sie die API direkt verwenden, ist Ihre App dafür verantwortlich, die empfangenen Token sicher zu speichern.

Ausführliche Schritte zur Implementierung der Anmeldung finden Sie unter:

Abrufen des Zugriffstokens

Wenn der Benutzer die Aktion zum Öffnen der Webansicht auslöst, stellen Sie sicher, dass die App über ein gültiges, nicht abgelaufenes Zugriffstoken verfügt, bevor Sie die Webressource laden.

Wenn Sie das native Auth SDK verwenden, fordern Sie ein Token lautlos an. Das SDK stellt eine getAccessToken() Methode bereit, mit der ein gültiges Token aus dem Cache abgerufen oder im Hintergrund aktualisiert wird. Ausführliche Informationen zum Abrufen von Zugriffstoken mit bestimmten Gültigkeitsbereichen finden Sie unter:

Wenn Sie die native Authentifizierungs-API direkt verwenden, ruft Ihre App Token über den Endpunkt der API /oauth/v2.0/token ab. Ausführliche Informationen finden Sie in der Referenz zur nativen Authentifizierungs-API.

Fordern Sie das Token mit den genauen Bereichen an, die von der Webressource benötigt werden. Informationen zu Bereichsanforderungen finden Sie unter Einschränkungen und Konfigurationsanforderungen.

Laden der Webansicht mit Authentifizierung

Es gibt zwei Methoden, um den Authentifizierungsstatus an die Webansicht zu übergeben. Der empfohlene Ansatz verwendet Autorisierungs-Header. Ein auf Cookies basierender Fallback ist für veraltete Szenarien verfügbar, jedoch wird davon abgeraten.

Fügt das Zugriffstoken direkt in den Authorization Header der ursprünglichen HTTP-Anforderung ein, die zum Laden der Webansicht verwendet wird. Dies ist die sicherste und robusteste Methode.

Dieser Ansatz wird bevorzugt, da er:

  • Ist zustandslos: Es basiert nicht auf persistenten Cookies auf der Clientseite.
  • Isoliert das Token: Es beschränkt das Token streng auf diesen spezifischen Anforderungsfluss.
  • Vermeidet webbasierte Angriffsvektoren: Es umgeht häufig auftretende Sicherheitsprobleme, die mit browserverwalteten Sitzungen verbunden sind.

So laden Sie die Webansicht mit headerbasierter Authentifizierung:

  1. Erstellen Sie die URL für die Webressource. Stellen Sie sicher, dass https verwendet wird.
  2. Erstellen Sie ein benutzerdefiniertes Netzwerkanforderungsobjekt.
  3. Fügen Sie der Anforderung den Header Authorization: Bearer <access_token> hinzu.
  4. Laden Sie die Anforderung in die Webansichtskomponente (z. B. WKWebView auf iOS oder WebView auf Android).

Option B: Cookies verwenden (nur Fallback)

Wenn die Zielwebressource die headerbasierte Authentifizierung nicht verarbeiten kann (z. B. bestimmte ältere Einzelseitenanwendungen), können Sie das Token als Cookie einfügen. Dieser Ansatz wird in der Regel aufgrund von Sicherheitsrisiken abgeraten.

Durch das Einfügen von Cookies in eine Webansicht wird der Authentifizierungsstatus einem browserverwalteten Mechanismus übertragen. Dadurch wird die Sitzung „ambient“ (automatisch an Anforderungen gebunden), was die App Webangriffen der Standardklasse aussetzt.

  • XSS (siteübergreifendes Skripting): Die Sitzung ist anfällig für Entführer, wenn der Webinhalt kompromittiert wird.
  • CSRF (cross-site request forgery): Es besteht ein Risiko für unbeabsichtigte authentifizierte Anforderungen.
  • Sitzungsfixierung: Ein Angreifer kann die Sitzung steuern.
  • Compliance: Bei diesem Ansatz besteht ein Konflikt mit den besten Sicherheitspraktiken (z. B. MASTG-KNOW-0018) hinsichtlich des Speicherns von sensiblen Zuständen in Cookie-Speichern von Webansichten.

Warning

Der cookiebasierte Ansatz wird bedingt genehmigt und generell davon abgeraten. Verwenden Sie sie nur, wenn die Zielwebressource die headerbasierte Authentifizierung nicht unterstützen kann.

Wenn Sie den cookiebasierten Ansatz verwenden, gelten die folgenden Anforderungen:

  • Verwenden Sie ggf. vom Server ausgestellte Sitzungscookies.
  • Vermeiden Sie das direkte Platzieren von Rohzugriffstoken in Cookies.
  • Legen Sie Cookies mit den Attributen HttpOnly, Secure und den entsprechenden SameSite-Attributen fest.
  • Erzwingen Sie strengen CSRF-Schutz auf serverseitiger Seite.

Verifizieren und speichern Sie das Token im Backend

Wenn die Anforderung die Webressource erreicht, verarbeitet das Back-End das Token, um die Sitzung einzurichten.

Überprüfen des Tokens

Der Webserver fängt eingehende Anforderungen ab und überprüft die Signatur und Claims des Tokens. Verwenden Sie Microsoft.Identity.Web (MISE) für ASP.NET Core-Backends, um die Validierung automatisch zu handhaben.

Stellen Sie sicher, dass der Zielgruppenanspruch (aud) des Tokens mit dem Bezeichner der Web-API und dem Ausstelleranspruch (iss) mit der erwarteten Autorität übereinstimmt.

Beibehalten der Sitzung

Die Webansicht speichert keine benutzerdefinierten Kopfzeilen für nachfolgende Navigationsereignisse (z. B. wenn der Benutzer einen Link auswählt). Um den authentifizierten Zustand nach der anfänglichen Anforderung beizubehalten, gibt der Server bei erfolgreicher Überprüfung des anfänglichen Bearertokens ein Standardsitzungscookies (Set-Cookie) aus.

Konfigurieren Sie das Sitzungscookies mit den folgenden Attributen:

  • HttpOnly
  • Secure
  • Eine geeignete SameSite Richtlinie

Einschränkungen und Konfigurationsanforderungen

Um sicherzustellen, dass das für die mobile App ausgestellte Token von der Webressource akzeptiert wird, beachten Sie die folgenden Konfigurationen:

  • Gemeinsame Clientidentität: Die mobile App und Web-App sollten dieselbe Client-ID (Anwendungs-ID) gemeinsam nutzen. Wenn sie unterschiedliche IDs haben, lehnt das Back-End das Token der mobilen App als Benutzergruppenkonflikt ab.
  • Bereichsausrichtung: Die mobile App fordert das Zugriffstoken mit genau den Bereichen an, Profile.Readdie von der Webressource benötigt werden (z. B. , Orders.Write).

Note

Diese Lösung ist speziell auf das Webansichtsszenario zugeschnitten. Eine allgemeinere Lösung, die SSO-Funktionen auf Systembrowser und andere komplexe Szenarien erweitert, ist für eine zukünftige Version geplant.

Verwandte Inhalte

  • Last updated on