Authentificateur web
Parcourir l'exempleCet article vous présente comment vous pouvez utiliser l’interface IWebAuthenticator de .NET Multi-Platform App UI (.NET MAUI). Cette interface vous permet de démarrer des flux d’authentification basés sur un navigateur qui écoute un rappel d’une URL spécifique inscrite dans l’application.
L’implémentation par défaut de l’interface IWebAuthenticator est disponible via la propriété WebAuthenticator.Default. L’espace de noms Microsoft.Maui.Authentication contient à la fois l’interface IWebAuthenticator et la classe WebAuthenticator.
Vue d’ensemble
De nombreuses applications nécessitent l’ajout d’une authentification utilisateur, ce qui signifie souvent que vos utilisateurs peuvent se connecter à leur compte de connexion Microsoft, Facebook, Google ou Apple existant.
Conseil
Microsoft Authentication Library (MSAL) fournit une excellente solution clé en main pour ajouter l’authentification à votre application.
Si vous souhaitez utiliser votre propre service web pour l’authentification, vous avez la possibilité d’utiliser WebAuthenticator pour implémenter la fonctionnalité côté client.
Pourquoi utiliser un back end de serveur
De nombreux fournisseurs d’authentification ont évolués pour offrir uniquement des flux d’authentification explicites ou à deux tranches pour améliorer la sécurité. Cela signifie que vous aurez besoin d’une clé secrète client du fournisseur pour terminer le flux d’authentification. Malheureusement, les applications mobiles ne constituent pas l’emplacement idéal pour stocker des secrets et tout élément stocké dans du code, des binaires ou autre d’une application mobile est considéré comme non sécurisé.
La meilleure pratique ici consiste à utiliser un back-end web comme couche intermédiaire entre votre application mobile et le fournisseur d’authentification.
Important
Nous vous recommandons vivement d’utiliser des bibliothèques et des modèles d’authentification mobiles plus anciens qui ne tirent pas parti d’un back-end web dans le flux d’authentification en raison de leur manque inhérent de sécurité pour le stockage de clés secrètes client.
Bien démarrer
Pour accéder à la fonctionnalité WebAuthenticator, la configuration spécifique à la plateforme suivante est requise.
Android nécessite une configuration de Filtre d’intention pour gérer votre URI de rappel. Vous y parvenez en héritant de la classe WebAuthenticatorCallbackActivity :
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";
}
Si la version Android cible de votre projet est définie sur Android 11 (R API 30) ou une version ultérieure, vous devez mettre à jour votre Manifeste Android avec les requêtes utilisées par les exigences de visibilité de package d’Android.
Dans le fichier Plateformes/Android/AndroidManifest.xml, ajoutez les nœuds queries/intent suivants dans le nœud manifest :
<queries>
<intent>
<action android:name="android.support.customtabs.action.CustomTabsService" />
</intent>
</queries>
Utilisation de WebAuthenticator
L’API consiste principalement d’une seul méthode, AuthenticateAsync, qui prend deux paramètres :
- L’URL utilisée pour démarrer le flux du navigateur web.
- L’URI que le flux doit finalement rappeler, qui est inscrit dans votre application.
Le résultat est un `WebAuthenticatorResult qui inclut tous les paramètres de requête analysés à partir de l’URI de rappel :
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 s’occupe du lancement de l’URL dans le navigateur et d’attendre la réception du rappel :
Si l’utilisateur annule le flux à un moment quelconque, une TaskCanceledException est levée.
Session d’authentification privée
iOS 13 a introduit une API de navigateur web éphémère pour que les développeurs puissent lancer la session d’authentification en mode privé. Cela permet aux développeurs de demander à ce qu’aucun cookie partagé ou aucune donnée de navigation ne soit disponible entre les sessions d’authentification. Il s’agira à chaque fois d’une nouvelle session de connexion. Elle est disponible via le paramètre WebAuthenticatorOptions transmis à la méthode AuthenticateAsync :
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
}
Différences selon les plateformes
Cette section décrit les différences spécifiques à la plateforme concernant l’API d’authentification web.
Les Onglets personnalisés sont utilisés lorsqu’ils sont disponibles. Autrement, le navigateur système est utilisé comme rappel.
Connexion Apple
Selon les instructions d’évaluation d’Apple, si votre application Apple utilise un service de connexion sociale pour s’authentifier, elle doit également offrir la connexion Apple en tant qu’option. Pour ajouter la connexion Apple dans vos applications, vous devez ajouter la connexion avec un droit d’utilisation Apple dans votre application. Le droit d’utilisation est défini en utilisant la clé com.apple.developer.applesignin, de type Array de String :
<key>com.apple.developer.applesignin</key>
<array>
<string>Default</string>
</array>
Pour obtenir plus d’informations, consultez Connectez-vous avec le droit Apple sur le site developer.apple.com.
Pour iOS 13 et version ultérieure, appelez la méthode AppleSignInAuthenticator.AuthenticateAsync. Elle utilise les API de connexion Apple natives afin que vos utilisateurs bénéficient de la meilleure expérience possible sur ces appareils. Par exemple, vous pouvez écrire votre code partagé pour qu’il utilise l’API correcte lors du runtime :
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;
Conseil
Pour les appareils non iOS 13, le flux d’authentification web démarre, qui peut également être utilisé pour activer la connexion Apple sur vos appareils Android et Windows. Vous pouvez vous connecter à votre compte iCloud sur votre simulateur iOS pour tester la connexion Apple.
Back end serveur ASP.NET Core
Il est possible d’utiliser l’API WebAuthenticator avec n’importe quel service back-end web. Pour l’utiliser avec une application ASP.NET Core, configurez l’application web à l’aide des étapes suivantes :
- Configurez vos fournisseurs externes d’authentification sociale dans une application web ASP.NET Core.
- Définissez le Schéma d’authentification sur CookieAuthenticationDefaults.AuthenticationScheme dans votre
.AddAuthentication()appel. - Utilisez
.AddCookie()dans votre appel Startup.cs.AddAuthentication(). - Tous les fournisseurs doivent être configurés avec
.SaveTokens = true;.
services.AddAuthentication(o =>
{
o.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
})
.AddCookie()
.AddFacebook(fb =>
{
fb.AppId = Configuration["FacebookAppId"];
fb.AppSecret = Configuration["FacebookAppSecret"];
fb.SaveTokens = true;
});
Conseil
Si vous souhaitez inclure la connexion Apple, vous pouvez utiliser le package NuGet AspNet.Security.OAuth.Apple. Vous pouvez consulter l’exemple Startup.cs complet.
Ajout d’un contrôleur d’authentification mobile personnalisé
Avec un flux d’authentification mobile, vous démarrez généralement le flux directement dans le fournisseur choisi par l’utilisateur. Par exemple, un clic sur le bouton « Microsoft » sur l’écran de connexion de l’application. Il est également important de renvoyer les informations pertinentes à votre application à un URI de rappel spécifique pour terminer le flux d’authentification.
Pour ce faire, utilisez un contrôleur d’API personnalisé :
[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
}
}
L’objectif de ce contrôleur est de déduire le schéma (fournisseur) demandé par l’application et de démarrer le flux d’authentification avec le fournisseur social. Lorsque le fournisseur rappelle le back-end web, le contrôleur analyse le résultat et redirige vers l’URI de rappel de l’application avec des paramètres.
Vous pouvez parfois retourner des données telles que le retour du access_token du fournisseur à l’application que vous pouvez effectuer via les paramètres de requête de l’URI de rappel. Vous pouvez également créer votre propre identité sur votre serveur à la place et renvoyer votre propre jeton à l’application. C’est à vous de décider ce que vous utilisez et comment vous effectuez cette partie.
Consultez l’exemple complet de contrôleur.
Remarque
L’exemple ci-dessus explique comment retourner le jeton d’accès du fournisseur de l’authentification tierce (c’est-à-dire : OAuth). Pour obtenir un jeton que vous pouvez utiliser pour autoriser les requêtes web au back-end web lui-même, vous devez créer votre propre jeton dans votre application web et retourner cela à la place. La Vue d’ensemble de l’authentification ASP.NET Core contient plus d’informations sur les scénarios d’authentification avancés dans ASP.NET Core.
