Web-Authentifikator

Durchsuchen Sie das Beispiel

In diesem Artikel wird beschrieben, wie Sie die .NET Multi-Platform App UI (.NET MAUI) für die IWebAuthenticator Schnittstelle verwenden können. Mit dieser Schnittstelle können Sie browserbasierte Authentifizierungsflüsse starten, die auf einen Rückruf einer bestimmten URL lauschen, die für die App registriert ist.

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.

Überblick

Viele Apps erfordern das Hinzufügen der Benutzerauthentifizierung. Dies bedeutet häufig, dass Sich Ihre Benutzer bei ihrem vorhandenen Microsoft-, Facebook-, Google- oder Apple-Anmeldekonto anmelden können.

Wenn Sie an der Verwendung Ihres eigenen Webdiensts für die Authentifizierung interessiert sind, ist es möglich WebAuthenticator , die clientseitige Funktionalität zu implementieren.

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

Viele Authentifizierungsanbieter haben nur explizite oder zweistufige Authentifizierungsflüsse angeboten, um eine bessere Sicherheit zu gewährleisten. Dies bedeutet, dass Sie einen geheimen Clientschlüssel vom Anbieter benötigen, um den Authentifizierungsfluss abzuschließen. Leider sind mobile Apps kein großartiger Ort, um geheime Schlüssel und alles zu speichern, was im Code, binärdateien oder anderweitig in einer mobilen App gespeichert ist, wird als unsicher angesehen.

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

Loslegen

Für den Zugriff auf die WebAuthenticator Funktionalität ist das folgende plattformspezifische Setup erforderlich.

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

}

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

<key>CFBundleURLTypes</key>
<array>
    <dict>
        <key>CFBundleURLName</key>
        <string>My App</string>
        <key>CFBundleURLSchemes</key>
        <array>
            <string>myapp</string>
        </array>
        <key>CFBundleTypeRole</key>
        <string>Editor</string>
    </dict>
</array>

<Applications>
    <Application Id="App" Executable="$targetnametoken$.exe" EntryPoint="MyApp.App">
        <Extensions>
            <uap:Extension Category="windows.protocol">
            <uap:Protocol Name="myapp">
                <uap:DisplayName>My App</uap:DisplayName>
            </uap:Protocol>
            </uap:Extension>
        </Extensions>
    </Application>
</Applications>

Verwenden von WebAuthenticator

Die API besteht hauptsächlich aus einer einzigen Methode, AuthenticateAsyncdie zwei Parameter verwendet:

1. Die URL, die zum Starten des Webbrowserablaufs verwendet wird.
2. Der URI, an den der Flow letztendlich zurückrufen 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 analysiert werden:

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 kümmert sich um den Start der URL im Browser und wartet, bis der Rückruf empfangen wird:

Wenn der Benutzer den Fluss an einem beliebigen Punkt abbricht, wird ein TaskCanceledException Fehler ausgelöst.

Private Authentifizierungssitzung

iOS 13 führte eine kurzlebige Webbrowser-API für Entwickler ein, um die Authentifizierungssitzung als privat zu starten. Auf diese Weise können Entwickler anfordern, dass keine freigegebenen Cookies oder Browserdaten zwischen Authentifizierungssitzungen verfügbar sind und jedes Mal eine neue Anmeldesitzung sein werden. Dies ist über den WebAuthenticatorOptions an die AuthenticateAsync Methode übergebenen Parameter verfügbar:

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

In diesem Abschnitt werden die plattformspezifischen Unterschiede mit der Webauthentifizierungs-API beschrieben.

Apple-Anmeldung

Gemäß den Prüfrichtlinien von Apple muss Ihre Apple-App, wenn Ihre Apple-App einen sozialen Anmeldedienst zur Authentifizierung verwendet, auch Apple Sign In als Option anbieten. Um Apple Sign In zu Ihren Apps hinzuzufügen, müssen Sie die Anmeldung mit Apple-Berechtigung zu Ihrer App hinzufügen. Diese Berechtigung wird unter Verwendung des com.apple.developer.applesignin Schlüssels des Typs Array von String definiert.

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

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

Rufen Sie für iOS 13 und höher die AppleSignInAuthenticator.AuthenticateAsync Methode auf. Dies verwendet die nativen Apple-Anmelde-APIs, damit Ihre Benutzer die bestmögliche Erfahrung auf diesen Geräten erhalten. Sie können beispielsweise Ihren freigegebenen Code schreiben, um die richtige API zur Laufzeit zu verwenden:

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;

ASP.NET Core-Server-Back-End

Es ist möglich, die WebAuthenticator API mit jedem Web-Back-End-Dienst zu verwenden. Um sie mit einer ASP.NET Core-App zu verwenden, konfigurieren Sie die Web-App mit den folgenden Schritten:

1. Richten Sie Ihre externen Anbieter für die soziale Authentifizierung in einer ASP.NET Core Web App ein.
2. Legen Sie das Standardauthentifizierungsschema in Ihrem .AddAuthentication() Aufruf festCookieAuthenticationDefaults.AuthenticationScheme.
3. Verwenden Sie .AddCookie() in Ihrem Startup.cs.AddAuthentication()-Aufruf.
4. Alle Anbieter müssen mit .SaveTokens = true;.

services.AddAuthentication(o =>
    {
        o.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    })
    .AddCookie()
    .AddFacebook(fb =>
    {
        fb.AppId = Configuration["FacebookAppId"];
        fb.AppSecret = Configuration["FacebookAppSecret"];
        fb.SaveTokens = true;
    });

Hinzufügen eines benutzerdefinierten mobilen Authentifizierungscontrollers

Bei einem mobilen Authentifizierungsfluss starten Sie den Fluss in der Regel direkt an einen Anbieter, den der Benutzer ausgewählt hat. Klicken Sie z. B. auf die Schaltfläche "Microsoft" auf dem Anmeldebildschirm der App. Außerdem ist es wichtig, relevante Informationen für Ihre App an eine bestimmte Callback-URI zurückzugeben, um den Authentifizierungsfluss zu beenden.

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 ableiten und den Authentifizierungsfluss mit dem sozialen Anbieter zu starten. Wenn der Anbieter zurück zum Web-Back-End aufruft, analysiert der Controller das Ergebnis und leitet den Rückruf-URI der App mit Parametern um.

Manchmal möchten Sie möglicherweise Daten wie den Anbieter access_token zurück an die App zurückgeben, die Sie über die Abfrageparameter des Rückruf-URI ausführen können. Oder Sie möchten stattdessen Ihre eigene Identität auf Ihrem Server erstellen und Ihr eigenes Token an die App übergeben. Was und wie Sie diesen Teil tun, liegt bei Ihnen!

Sehen Sie sich das vollständige Controllerbeispiel an.