Condividi tramite

Autenticatore Web

  • Articolo

Sfogliare l'esempio. Esplorare l'esempio

Questo articolo descrive come usare l'interfaccia dell'interfaccia utente dell'app multipiattaforma .NET (.NET MAUI).IWebAuthenticator Questa interfaccia consente di avviare flussi di autenticazione basati su browser, in ascolto di un callback a un URL specifico registrato nell'app.

L'implementazione predefinita dell'interfaccia IWebAuthenticator è disponibile tramite la WebAuthenticator.Default proprietà . Sia l'interfaccia che WebAuthenticator la IWebAuthenticator classe sono contenute nello spazio dei Microsoft.Maui.Authentication nomi .

Panoramica

Molte app richiedono l'aggiunta dell'autenticazione utente e questo spesso significa consentire agli utenti di accedere al proprio account di accesso Microsoft, Facebook, Google o Apple esistente.

Suggerimento

Microsoft Authentication Library (MSAL) offre un'eccellente soluzione turn-key per aggiungere l'autenticazione all'app.

Se si è interessati a usare il proprio servizio Web per l'autenticazione, è possibile usare WebAuthenticator per implementare la funzionalità lato client.

Perché usare un back-end del server

Molti provider di autenticazione sono stati spostati nell'offerta solo di flussi di autenticazione espliciti o a due zampe per garantire una maggiore sicurezza. Ciò significa che è necessario un segreto client del provider per completare il flusso di autenticazione. Sfortunatamente, le app per dispositivi mobili non sono un ottimo punto in cui archiviare i segreti e qualsiasi elemento archiviato nel codice, nei file binari di un'app per dispositivi mobili o in altro modo, è considerato non sicuro.

La procedura consigliata consiste nell'usare un back-end Web come livello intermedio tra l'app per dispositivi mobili e il provider di autenticazione.

Importante

È consigliabile evitare l'uso di librerie e modelli di autenticazione di solo dispositivi mobili meno recenti che non sfruttano un back-end Web nel flusso di autenticazione, a causa della mancanza intrinseca di sicurezza per l'archiviazione dei segreti client.

Operazioni preliminari

Per accedere alla funzionalità è necessaria la WebAuthenticator configurazione specifica della piattaforma seguente.

Android richiede una configurazione filtro finalità per gestire l'URI di callback. Questa operazione viene eseguita ereditando dalla WebAuthenticatorCallbackActivity classe :

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

}

Se la versione di Android di destinazione del progetto è impostata su Android 11 (API R 30) o versione successiva, è necessario aggiornare il manifesto Android con query che usano i requisiti di visibilità dei pacchetti android.

Nel file Platforms/Android/AndroidManifest.xml aggiungere i nodi seguenti queries/intent nel manifest nodo:

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

Uso di WebAuthenticator

L'API è costituita principalmente da un singolo metodo, AuthenticateAsync, che accetta due parametri:

  1. URL usato per avviare il flusso del Web browser.
  2. L'URI a cui si prevede che il flusso venga richiamato, registrato nell'app.

Il risultato è un 'WebAuthenticatorResult, che include tutti i parametri di query analizzati dall'URI di callback:

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
}

L'API WebAuthenticator si occupa dell'avvio dell'URL nel browser e dell'attesa fino alla ricezione del callback:

Tipico flusso di autenticazione Web.

Se l'utente annulla il flusso in qualsiasi momento, viene generata un'eccezione TaskCanceledException .

Sessione di autenticazione privata

iOS 13 ha introdotto un'API del Web browser temporanea per gli sviluppatori per avviare la sessione di autenticazione come privata. Ciò consente agli sviluppatori di richiedere che non siano disponibili cookie condivisi o dati di esplorazione tra le sessioni di autenticazione e sarà una nuova sessione di accesso ogni volta. È disponibile tramite il WebAuthenticatorOptions parametro passato al AuthenticateAsync metodo :

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
}

Differenze tra le piattaforme

Questa sezione descrive le differenze specifiche della piattaforma con l'API di autenticazione Web.

Le schede personalizzate vengono usate ogni volta che è disponibile; in caso contrario, il browser di sistema viene usato come fallback.

Accesso Apple

Secondo le linee guida di revisione di Apple, se l'app Apple usa qualsiasi servizio di accesso social per l'autenticazione, deve anche offrire Apple Sign In come opzione. Per aggiungere Apple Sign In alle tue app, dovrai aggiungere l'accesso con il diritto Apple all'app. Questo diritto viene definito usando la com.apple.developer.applesignin chiave , di tipo Array String:

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

Per altre informazioni, vedere Sign in with Apple Entitlement on developer.apple.com (Accedi con Apple Entitlement on developer.apple.com).

Per iOS 13 e versioni successive, chiamare il AppleSignInAuthenticator.AuthenticateAsync metodo . Questo usa le API di accesso Apple native in modo che gli utenti ottengano la migliore esperienza possibile su questi dispositivi. Ad esempio, è possibile scrivere il codice condiviso per usare l'API corretta in fase di esecuzione:

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;

Suggerimento

Per i dispositivi non iOS 13, verrà avviato il flusso di autenticazione Web, che può essere usato anche per abilitare l'accesso Apple nei dispositivi Android e Windows. È possibile accedere all'account iCloud nel simulatore iOS per testare l'accesso ad Apple.

back-end del server principale ASP.NET

È possibile usare l'API WebAuthenticator con qualsiasi servizio back-end Web. Per usarla con un'app principale ASP.NET, configurare l'app Web con la procedura seguente:

  1. Configurare i provider di autenticazione di social networking esterni in un'app Web ASP.NET Core.
  2. Impostare lo schema di autenticazione predefinito su CookieAuthenticationDefaults.AuthenticationScheme nella .AddAuthentication() chiamata.
  3. Usare .AddCookie() nella chiamata Startup.cs.AddAuthentication().
  4. Tutti i provider devono essere configurati con .SaveTokens = true;.
services.AddAuthentication(o =>
    {
        o.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
    })
    .AddCookie()
    .AddFacebook(fb =>
    {
        fb.AppId = Configuration["FacebookAppId"];
        fb.AppSecret = Configuration["FacebookAppSecret"];
        fb.SaveTokens = true;
    });

Suggerimento

Se si vuole includere Apple Sign In, è possibile usare il AspNet.Security.OAuth.Apple pacchetto NuGet. È possibile visualizzare l'esempio completo di Startup.cs.

Aggiungere un controller di autenticazione per dispositivi mobili personalizzato

Con un flusso di autenticazione mobile, in genere si avvia il flusso direttamente a un provider scelto dall'utente. Ad esempio, facendo clic su un pulsante "Microsoft" nella schermata di accesso dell'app. È anche importante restituire informazioni pertinenti all'app in un URI di callback specifico per terminare il flusso di autenticazione.

A tale scopo, usare un controller API personalizzato:

[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
    }
}

Lo scopo di questo controller è dedurre lo schema (provider) richiesto dall'app e avviare il flusso di autenticazione con il provider di social networking. Quando il provider esegue il callback al back-end Web, il controller analizza il risultato e reindirizza all'URI di callback dell'app con parametri.

A volte può essere necessario restituire dati come il provider all'app access_token , che è possibile eseguire tramite i parametri di query dell'URI di callback. In alternativa, è possibile creare una propria identità nel server e passare il proprio token all'app. Che cosa e come si fa questa parte è per voi!

Vedere l'esempio completo del controller.

Nota

L'esempio precedente illustra come restituire il token di accesso dal provider di autenticazione di terze parti (ie: OAuth). Per ottenere un token che è possibile usare per autorizzare le richieste Web al back-end Web stesso, è necessario creare il proprio token nell'app Web e restituirlo. La panoramica dell'autenticazione ASP.NET Core contiene altre informazioni sugli scenari di autenticazione avanzati in ASP.NET Core.