Vérification renforcée

Une seconde étape, après un mot de passe

Une passkey est ici un second facteur et jamais un moyen de se connecter seule : la page de connexion ne propose aucune option passkey. Une clé de sécurité peut être utilisée à sa place. La vérification renforcée revérifie d'abord le mot de passe, si bien que seul un utilisateur qui a un mot de passe peut enrôler un facteur ou en prouver un.

Avant une opération sensible

Une opération peut exiger un second facteur. Vous définissez l'exigence avec foir operations update et son option --second-factor ; elle arrive en production à la prochaine publication. Une exécution dont la session n'a pas prouvé de facteur est refusée avec FAILED_PRECONDITION et un message que vous pouvez formuler vous-même. Une opération qui porte cette exigence ne peut pas être démarrée par un hook ou une planification.

À chaque connexion à une app

Chaque app de connexion a dans la console un interrupteur Require MFA. Lorsqu'il est activé, une connexion par mot de passe sur la page hébergée ne se termine qu'une fois que l'utilisateur a prouvé un facteur. Un utilisateur qui n'en a aucun en enrôle un pendant cette connexion, avec une passkey ou en scannant un code QR dans une application d'authentification.

L'interrupteur exclut aussi toute personne sans mot de passe. Les utilisateurs qui se connectent avec un code reçu par e-mail ou via un fournisseur d'identité ne peuvent pas du tout se connecter à cette app.

Vérification renforcée sans déconnexion

Cela nécessite une session sur un domaine vérifié, à savoir un domaine de connexion personnalisé. Une app qui utilise le flux par jeton n'a pas une telle session, et ses utilisateurs obtiennent un second facteur en se reconnectant via une app qui en exige un.