- Article
Ces configurations et meilleures pratiques vous aideront à éviter des scénarios courants qui empêchent la mise à la disposition de l’authentification sans mot de passe FIDO2 aux utilisateurs de vos applications.
Bonnes pratiques générales
Indications de domaine
N’utilisez pas d’indication de domaine pour contourner la découverte de home-real. Cette fonctionnalité est destinée à rationaliser les connexions, mais le fournisseur d’identité fédéré peut ne pas prendre en charge l’authentification sans mot de passe.
Exiger des informations d’identification spécifiques
Si vous utilisez SAML, ne spécifiez pas qu’un mot de passe est requis avec l’élément RequestedAuthnContext.
L’élément RequestedAuthnContext est facultatif. Par conséquent, pour résoudre ce problème, vous pouvez le supprimer de vos demandes d’authentification SAML. Il s’agit d’une meilleure pratique générale, car l’utilisation de cet élément peut également empêcher le bon fonctionnement d’autres options d’authentification, comme l’authentification multifacteur.
Utilisation de la méthode d’authentification la plus récemment utilisée
La méthode de connexion la plus récemment utilisée par un utilisateur lui sera présentée en premier. Cela peut être source de confusion lorsque les utilisateurs pensent qu’ils doivent utiliser la première option présentée. Toutefois, ils peuvent choisir une autre option en sélectionnant «Autres méthodes pour se connecter», comme indiqué ci-dessous.
Meilleures pratiques spécifiques à la plateforme
Bureau
Les options recommandées pour l’implémentation de l’authentification sont, dans l’ordre:
- Les applications de bureau .NET qui utilisent la bibliothèque d’authentification Microsoft (MSAL) doivent utiliser le gestionnaire d’authentification Windows (WAM). Cette intégration et ses avantages sont documentés sur GitHub.
- Utilisez WebView2 pour prendre en charge FIDO2 dans un navigateur incorporé.
- Utilisez le navigateur du système. Les bibliothèques MSAL pour les plateformes de bureau utilisent cette méthode par défaut. Vous pouvez consulter notre page sur la compatibilité des navigateurs avec FIDO2 pour vous assurer que le navigateur que vous utilisez prend en charge l’authentification FIDO2.
Mobile
FIDO2 est pris en charge pour les applications natives iOS qui utilisent MSAL avec ASWebAuthenticationSession ou l’intégration de répartiteur. Le répartiteur est livré dans Microsoft Authenticator sur iOS et le portail d’entreprise Intune Microsoft sur macOS.
Assurez-vous que votre réseau Proxy ne bloque pas la validation de domaine associé par Apple. L’authentification FIDO2 nécessite que la validation de domaine associé d’Apple réussisse, ce qui nécessite que certains domaines Apple soient exclus des réseaux Proxy. Pour plus d’informations, consultez Utiliser les produits Apple sur les réseaux d’entreprise.
La prise en charge de FIDO2 pour les applications natives Android natives est actuellement en cours de développement.
Si vous n’utilisez pas MSAL, vous devez quand même utiliser le navigateur web du système pour l’authentification. Les fonctionnalités telles que l’authentification unique et l’accès conditionnel s’appuient sur une surface web partagée fournie par le navigateur web du système. Cela signifie que vous devez utiliser les onglets personnalisés de Chrome (Android) ou authentifier un utilisateur à l’aide d’un service web [Documentation pour développeurs sur Apple] (iOS).
Applications web et monopages
La disponibilité de l’authentification sans mot de passe FIDO2 pour les applications qui s’exécutent dans un navigateur web dépend de la combinaison du navigateur et de la plateforme. Vous pouvez consulter notre matrice de compatibilité FIDO2 pour vérifier si la combinaison que vos utilisateurs rencontreront est prise en charge.
Étapes suivantes
Options d’authentification sans mot de passe pour Microsoft EntraID
