Freigeben über

Web Authenticator

  • Artikel

Beispiel durchsuchen.Durchsuchen Sie das Beispiel

Dieser Element beschreibt, wie Sie die .NET Multi-Platform App UI (.NET MAUI) IWebAuthenticator-Schnittstelle verwenden können. Mit dieser Schnittstelle können Sie browserbasierte Authentifizierungsflows starten, die auf einen Rückruf zu einer bestimmten, in der App registrierten URL warten.

Die Standardimplementierung der IWebAuthenticator-Schnittstelle ist über die WebAuthenticator.Default-Eigenschaft verfügbar. Sowohl die IWebAuthenticator-Schnittstelle als auch die WebAuthenticator-Klasse sind im Microsoft.Maui.Authentication-Namespace enthalten.

Übersicht

Viele Apps erfordern eine zusätzliche Benutzerauthentifizierung, und das bedeutet oft, dass Ihre Benutzer*innen sich in Ihr bestehendes Microsoft-, Facebook-, Google- oder Apple-Anmeldekonto einloggen müssen.

Tipp

Microsoft Authentication Library (MSAL) bietet eine hervorragende, sofort einsetzbare Lösung zum Hinzufügen einer Authentifizierung zu Ihrer App.

Wenn Sie Ihren eigenen Webservice für die Authentifizierung nutzen möchten, können Sie WebAuthenticator verwenden, um die clientseitige Funktionalität zu implementieren.

Gründe für die Verwendung eines Server-Back-Ends

Viele Authentifizierungsanbieter sind dazu übergegangen, nur explizite oder zweibeinige Authentifizierungsflows anzubieten, um höhere Sicherheit zu gewährleisten. Das bedeutet, dass Sie einen geheimen Clientschlüssel vom Anbieter benötigen, um den Authentifizierungsflow abzuschließen. Leider sind mobile Apps kein guter Ort, um Geheimnisse zu speichern, und alles, was im Code einer mobilen App, in Binärdateien oder anderweitig gespeichert ist, gilt als unsicher.

Die bewährte Methode hier ist die Verwendung eines Web-Back-Ends als Zwischenschicht zwischen Ihrer mobilen App und dem Authentifizierungsanbieter.

Wichtig

Wir raten dringend davon ab, ältere Authentifizierungsbibliotheken und -muster zu verwenden, die nur für mobile Geräte geeignet sind und kein Web-Back-End in den Authentifizierungsflow einbinden, da sie keine Sicherheit für die Speicherung geheimer Clientschlüssel bieten.

Erste Schritte

Um auf die WebAuthenticator-Funktionalität zuzugreifen, ist die folgende plattformspezifische Einrichtung erforderlich.

Für Android ist die Einrichtung eines Intent-Filters zur Verarbeitung des Rückruf-URI erforderlich. Dies wird durch Vererbung von Klasse WebAuthenticatorCallbackActivity erreicht:

using Android.App;
using Android.Content.PM;

namespace YourNameSpace;

[Activity(NoHistory = true, LaunchMode = LaunchMode.SingleTop, Exported = true)]
[IntentFilter(new[] { Android.Content.Intent.ActionView },
              Categories = new[] { Android.Content.Intent.CategoryDefault, Android.Content.Intent.CategoryBrowsable },
              DataScheme = CALLBACK_SCHEME)]
public class WebAuthenticationCallbackActivity : Microsoft.Maui.Authentication.WebAuthenticatorCallbackActivity
{
    const string CALLBACK_SCHEME = "myapp";

}

Wenn die Android-Zielversion Ihres Projekts auf Android 11 (R API 30) oder höher gesetzt ist, müssen Sie Ihr Android-Manifest mit Abfragen aktualisieren, die die Paketsichtbarkeitsanforderungen von Android verwenden.

Fügen Sie in der Datei Platforms/Android/AndroidManifest.xml die folgenden queries/intent-Knoten zum Knoten manifest hinzu:

<queries>
  <intent>
    <action android:name="android.support.customtabs.action.CustomTabsService" />
  </intent>
</queries>

Verwenden von WebAuthenticator

Die API besteht hauptsächlich aus einer einzelnen AuthenticateAsync-Methode, die zwei Parameter verwendet:

  1. Die URL, die zum Starten des Webbrowser verwendet wird.
  2. Der URI, zu dem der Flow letztendlich zurückkehren soll und der für Ihre App registriert ist.

Das Ergebnis ist ein WebAuthenticatorResult, das alle Abfrageparameter enthält, die aus dem Rückruf-URI geparst wurden:

try
{
    WebAuthenticatorResult authResult = await WebAuthenticator.Default.AuthenticateAsync(
        new Uri("https://mysite.com/mobileauth/Microsoft"),
        new Uri("myapp://"));

    string accessToken = authResult?.AccessToken;

    // Do something with the token
}
catch (TaskCanceledException e)
{
    // Use stopped auth
}

Die WebAuthenticator-API übernimmt das Starten der URL im Browser und wartet, bis der Rückruf empfangen wird:

Typischer Webauthentifizierungs-Flow.

Wenn der/die Benutzer*in den Flow an einem beliebigen Punkt abbricht, wird eine TaskCanceledException ausgelöst.

Private Authentifizierungssitzung

Mit iOS 13 wurde eine kurzlebige Webbrowser-API eingeführt, mit der Entwickler die Authentifizierungssitzung als private Sitzung starten können. Dadurch können Entwickler anfordern, dass zwischen Authentifizierungssitzungen keine freigegebenen Cookies oder Browserdaten verfügbar sind, und jedes Mal eine neue Anmeldesitzung gestartet wird. Dies ist über den Parameter WebAuthenticatorOptions möglich, der an die Methode AuthenticateAsync übergeben wird:

try
{
    WebAuthenticatorResult authResult = await WebAuthenticator.Default.AuthenticateAsync(
        new WebAuthenticatorOptions()
        {
            Url = new Uri("https://mysite.com/mobileauth/Microsoft"),
            CallbackUrl = new Uri("myapp://"),
            PrefersEphemeralWebBrowserSession = true
        });

    string accessToken = authResult?.AccessToken;

    // Do something with the token
}
catch (TaskCanceledException e)
{
    // Use stopped auth
}

Plattformunterschiede

Dieser Abschnitt beschreibt die plattformspezifischen Unterschiede zur Web-Authentifizierungs-API.

Benutzerdefinierte Registerkarten werden verwendet, wenn sie verfügbar sind. Andernfalls wird der Systembrowser als Fallback verwendet.

Apple-Anmeldung

Gemäß den Überprüfungsrichtlinien von Apple muss Ihre App, wenn sie für die Authentifizierung einen Anmeldedienst für soziale Netzwerke verwendet, auch eine Apple-Anmeldung als Option anbieten. Um eine Apple-Anmeldung zu Ihren Apps hinzuzufügen, müssen Sie die Berechtigung für die Anmeldung bei Apple zu Ihrer App hinzufügen. Diese Berechtigung wird durch den Schlüssel com.apple.developer.applesignin vom Typ Array von String definiert:

<key>com.apple.developer.applesignin</key>
<array>
  <string>Default</string>
</array>

Weitere Informationen finden Sie unter Anmelden mit Apple-Berechtigung unter developer.apple.com.

Rufen Sie die AppleSignInAuthenticator.AuthenticateAsync-Methode für iOS 13 und höher auf. Dabei werden die nativen APIs für die Apple-Anmeldung verwendet, um Ihren Benutzer*innen die bestmögliche Erfahrung auf diesen Geräten zu bieten. So können Sie z. B. Ihren freigegebenen Code so schreiben, dass er zur Laufzeit die richtige API verwendet:

var scheme = "..."; // Apple, Microsoft, Google, Facebook, etc.
var authUrlRoot = "https://mysite.com/mobileauth/";
WebAuthenticatorResult result = null;

if (scheme.Equals("Apple")
    && DeviceInfo.Platform == DevicePlatform.iOS
    && DeviceInfo.Version.Major >= 13)
{
    // Use Native Apple Sign In API's
    result = await AppleSignInAuthenticator.AuthenticateAsync();
}
else
{
    // Web Authentication flow
    var authUrl = new Uri($"{authUrlRoot}{scheme}");
    var callbackUrl = new Uri("myapp://");

    result = await WebAuthenticator.Default.AuthenticateAsync(authUrl, callbackUrl);
}

var authToken = string.Empty;

if (result.Properties.TryGetValue("name", out string name) && !string.IsNullOrEmpty(name))
    authToken += $"Name: {name}{Environment.NewLine}";

if (result.Properties.TryGetValue("email", out string email) && !string.IsNullOrEmpty(email))
    authToken += $"Email: {email}{Environment.NewLine}";

// Note that Apple Sign In has an IdToken and not an AccessToken
authToken += result?.AccessToken ?? result?.IdToken;

Tipp

Bei Nicht-iOS-13-Geräten wird dadurch der Webauthentifizierungsflow gestartet, der auch dazu verwendet werden kann, die Apple-Anmeldung auf Ihren Android- und Windows-Geräten zu aktivieren. Sie können sich auf Ihrem iOS-Simulator bei Ihrem iCloud-Konto anmelden, um die Apple-Anmeldung zu testen.

ASP.NET Core-Server-Back-End

Die WebAuthenticator-API kann mit einem beliebigen Web-Back-End-Dienst verwendet werden. Zur Verwendung mit einer ASP.NET Core-App konfigurieren Sie die Web-App wie folgt:

  1. Richten Sie die externen Anbieter für die Authentifizierung über ein soziales Netzwerk in einer ASP.NET Core-Web-App ein.
  2. Legen Sie das Standardauthentifizierungsschema in Ihrem .AddAuthentication()-Aufruf auf CookieAuthenticationDefaults.AuthenticationScheme fest.
  3. Verwenden Sie .AddCookie() in Ihrem Startup.cs.AddAuthentication() Anruf.
  4. Alle Anbieter müssen mit .SaveTokens = true; konfiguriert sein.
services.AddAuthentication(o =>
    {
        o.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    })
    .AddCookie()
    .AddFacebook(fb =>
    {
        fb.AppId = Configuration["FacebookAppId"];
        fb.AppSecret = Configuration["FacebookAppSecret"];
        fb.SaveTokens = true;
    });

Tipp

Wenn Sie die Apple-Anmeldung einschließen möchten, können Sie das NuGet-Paket AspNet.Security.OAuth.Apple verwenden. Sehen Sie sich das vollständige Startup.cs-Beispiel an.

Hinzufügen eines benutzerdefinierten mobilen Authentifizierungscontrollers

Bei einem mobilen Authentifizierungsworkflow wird der Flow in der Regel direkt bei einem Anbieter gestartet, den die Benutzer*innen ausgewählt haben. Zum Beispiel durch Klicken auf die Schaltfläche „Microsoft“ auf dem Anmeldebildschirm der App. Es ist außerdem wichtig, dass Sie die relevanten Informationen über einen bestimmten Rückruf-URI an Ihre App zurückgeben, um den Authentifizierungsflow abzuschließen.

Verwenden Sie dazu einen benutzerdefinierten API-Controller:

[Route("mobileauth")]
[ApiController]
public class AuthController : ControllerBase
{
    const string callbackScheme = "myapp";

    [HttpGet("{scheme}")] // eg: Microsoft, Facebook, Apple, etc
    public async Task Get([FromRoute]string scheme)
    {
        // 1. Initiate authentication flow with the scheme (provider)
        // 2. When the provider calls back to this URL
        //    a. Parse out the result
        //    b. Build the app callback URL
        //    c. Redirect back to the app
    }
}

Der Zweck dieses Controllers besteht darin, das von der App angeforderte Schema (Anbieter) zu ermitteln und den Authentifizierungsflow mit dem Anbieter des sozialen Netzwerks zu starten. Wenn der Anbieter einen Rückruf an das Web-Back-End durchführt, analysiert der Controller das Ergebnis und nimmt eine Umleitung an den Rückruf-URI der App mit Parametern vor.

Manchmal möchten Sie vielleicht Daten wie die access_token des Anbieters an die App zurückgeben, was Sie über die Abfrageparameter des Rückruf-URIs tun können. Vielleicht möchten Sie auch stattdessen eine eigene Identität auf dem Server erstellen und Ihr eigenes Token an die App zurückgeben. Sie können entscheiden, was und wie Sie es machen.

Sehen Sie sich das vollständige Controller-Beispiel an.

Hinweis

Im obigen Beispiel wird veranschaulicht, wie das Zugriffstoken vom Authentifizierungsdrittanbieter (z. B. OAuth) zurückgegeben wird. Zum Abrufen eines Tokens, mit dem Sie Webanforderungen für das Web-Back-End selbst autorisieren können, sollten Sie ein eigenes Token in Ihrer Web-App erstellen und stattdessen dieses zurückgeben. In der Übersicht über die ASP.NET Core-Authentifizierung finden Sie weitere Informationen zu umfangreicheren Authentifizierungsszenarien in ASP.NET Core.