Clés d’accès

Une clé d’accès permet à quelqu’un de se connecter avec son empreinte digitale, son visage ou son code PIN de l’appareil au lieu de taper un mot de passe. Elle est conservée sur son appareil, dans son gestionnaire de mots de passe ou sur son téléphone, elle ne fonctionne que sur le site pour lequel elle a été créée, et elle ne peut pas être modifiée ou réutilisée ailleurs. Power Portals Pro ajoute des clés d’accès aux comptes locaux d’un portail sur React et Blazor : les utilisateurs les ajoutent sur leur page de compte, puis se connectent avec une seule en une seule étape.

Désactiver les clés d’accès

Les clés d’accès sont activées là où se trouvent les comptes locaux (LocalAccountsEnabled, activés par défaut) : une clé d’accès est un identifiant local, conservé comme un contact comme mot de passe. Pour un portail qui ne devrait pas les offrir, mettez PasskeysEnabled sur AuthClientOptions false dans Program.cs. Désactivé, le serveur cesse de servir les routes par clé d’accès et refuse la connexion par clé d’accès, les pages du compte cessent de les afficher, et les clés d’accès déjà enregistrées ne peuvent plus être utilisées.

Important

Les clés d’accès sont conservées dans la ppp_passkey table, que la solution gérée Power Portals Pro prévoie. Importez la solution avant que les pages de compte n’offrent des clés d’accès, et assurez-vous que l’utilisateur de l’application du portail détient le rôle d’utilisateur applicatif expédié, qui détient ses privilèges sur la table.

Dans les pages des comptes

Les pages de compte générées par les modèles de projet affichent des clés d’accès dès qu’elles sont activées : un bouton Connexion avec un bouton clé d’accès sur la page de connexion, à côté du formulaire de mot de passe, et une section clés d’accès sur la page de profil où l’utilisateur ajoute, renomme et supprime les siennes. Les deux lisent passkeysEnabled depuis GET /api/auth/options, ou AuthClientOptions sur une page Blazor Server, et ne montrent rien lorsque les clés d’accès sont désactivées.

Les composants

Deux composants, sur les deux piles, font le travail. PasskeySignInButton Se connecte avec une clé d’accès choisie par la personne, et ne rend rien dans un navigateur qui ne peut pas utiliser de clés d’accès. PasskeyManager Liste les clés d’accès des utilisateurs connectés et leur permet de les ajouter, renommer et supprimer. Affichez-les uniquement lorsque les clés d’accès sont activées.

Réagir

Blazor

Une fois connecté, le bouton Blazor recharge la page à ReturnUrl, de sorte que tout ce qui y est visible permet à l’utilisateur de se connecter. OnResult Il remet à la page les résultats qu’elle gère elle-même, comme un compte verrouillé. La partie navigateur de la cérémonie s’exécute dans les scripts propres aux composants, donc ils fonctionnent de la même manière sous Blazor Server, WebAssembly et Auto.

Comment fonctionne une cérémonie

Chaque opération de clé d’accès consiste en deux requêtes, construites sur le support de ASP.NET clé d’accès de Core Identity : la première renvoie les options que le navigateur transmet à navigator.credentials, et la seconde renvoie ce que le navigateur a répondu. Identity conserve le défi entre eux dans un cookie.

• Connexion : POST /api/auth/passkey/request-options, puis POST /api/auth/passkey/login, qui vérifie la signature par rapport à la clé publique stockée et connecte l’utilisateur. Les deux comptent pour la limite par adresse sur les formulaires de connexion.
• Gérer : GET /api/auth/manage/passkeys les lister ; POST /api/auth/manage/passkeys/creation-options et POST /api/auth/manage/passkeys en ajouter un ; /rename et /remove faire ce qu’ils disent. Sur React, AuthClient.signInWithPasskeyAsync et createPasskeyAsync organiser toute une cérémonie en un seul appel.

Sécurité

• Une clé d’accès qui vérifie le code PIN ou la biométrie de la personne est en soi deux facteurs, donc une connexion avec clé d’accès ne demande aucun code d’authentification. Un compte verrouillé ou non confirmé est refusé, comme lors de la connexion par mot de passe.
• Une clé d’accès ne fonctionne que sur le domaine sur lequel elle a été créée. Si le portail passe vers un autre domaine, ou si un emplacement de staging a son propre nom d’hôte, les clés d’accès existantes ne fonctionnent pas là. Réglez IdentityPasskeyOptions.ServerDomain pour épingler les clés d’accès de domaine pour lesquelles elles sont conçues.
• ppp_passkey est une table protégée : aucune requête de portail ne l’atteint, quel que soit le rôle ou le rôle de sécurité. Le code de connexion et de compte le lit et l’écrit comme l’application. Ce qu’il contient — une clé publique et les données que le navigateur a signées — n’est pas secret.
• Un administrateur qui se fait passer pour un utilisateur ne peut ni ajouter ni retirer les clés d’accès de l’utilisateur, car il ne peut pas changer le mot de passe de l’utilisateur.
• Les utilisateurs internes se connectent via Microsoft Entra ID, qui conserve leurs clés d’accès ; ils n’en ont aucune dans le portail.

Note

Les navigateurs n’autorisent les clés d’accès que sur les origines sécurisées : https, ou localhost lors du développement.