Pour un portail client qui expose des factures ou des données personnelles, supprimer le mot de passe ne doit pas supprimer le second facteur. Le parcours visé est simple à décrire : l’utilisateur reçoit un lien magique, l’ouvre, puis confirme un code TOTP généré par son application d’authentification. Le point difficile est moins l’écran de connexion que le moment où l’application considère la session comme suffisamment vérifiée.

Aurabase fournit l’authentification et une base PostgreSQL 16 dédiée, ainsi que des fonctions edge. Les informations disponibles ne précisent toutefois pas si son service Auth prend en charge nativement les liens magiques et l’enrôlement TOTP, ni quelles garanties il applique aux sessions intermédiaires. Vérifiez ces capacités et leurs comportements dans la documentation actuelle avant de choisir l’implémentation. Ne présentez pas un flux personnalisé comme une fonction native du produit.

Définir le contrat de sécurité

Commencez par écrire les états attendus du parcours : non authentifié, lien vérifié mais TOTP en attente, MFA validée, puis facteur perdu ou réinitialisé. La règle essentielle est que l’état « TOTP en attente » ne donne pas accès aux données protégées. Cacher un écran dans le navigateur ne suffit pas : les appels serveur et les politiques d’accès à la base doivent aussi refuser cet état.

Un lien magique établit que la personne peut accéder à une adresse e-mail. Il ne prouve pas qu’elle détient le second facteur. Si le mécanisme d’authentification délivre d’emblée une session complète après le lien, déterminez comment les requêtes sensibles resteront bloquées avant la validation TOTP. Si vous ne pouvez pas appliquer cette séparation côté serveur, ne déployez pas le parcours comme une MFA effective.

Mettre en place l’enrôlement TOTP

1. Confirmer les primitives d’authentification. Vérifiez la création et l’expiration des liens, la confirmation de leur usage et la possibilité de distinguer une session partielle d’une session MFA validée. Vérifiez aussi comment l’API permet de révoquer ou renouveler les sessions. Ces détails déterminent si le flux peut rester dans Auth ou s’il faut une logique serveur complémentaire.
2. Créer le facteur dans un contexte serveur de confiance. Après le lien, générez un secret TOTP côté serveur et ne l’exposez qu’au moment de l’enrôlement, sous la forme nécessaire à l’ajout dans une application d’authentification. N’enregistrez jamais le secret en clair dans une table lisible par le client. Si vous utilisez PostgreSQL pour les métadonnées du facteur, limitez-en l’accès et ne stockez le secret qu’après avoir défini une méthode de protection adaptée.
3. Activer seulement après vérification. Demandez un premier code TOTP avant de marquer le facteur comme actif. Un code affiché à l’écran ne prouve pas que l’utilisateur a correctement configuré son application. Prévoyez aussi des codes de récupération à usage unique et un parcours de remplacement du facteur qui ne repose pas uniquement sur le même e-mail.
4. Garder l’autorisation côté serveur. À chaque requête protégée, exigez une preuve que le second facteur a été validé. Une fonction edge peut convenir à une partie de cette logique, mais vérifiez les possibilités du runtime et le mode de protection des secrets avant d’y placer la vérification. Les politiques PostgreSQL doivent empêcher qu’un client contourne l’écran MFA en interrogeant directement des données. Le guide sur les politiques PostgreSQL RLS sur Aurabase aide à cadrer cette couche d’accès.

Tester les ruptures, pas seulement le parcours idéal

Testez un lien expiré, réutilisé ou ouvert sur un autre appareil, un code TOTP incorrect, une horloge décalée et une session partielle qui tente d’appeler une route privée. Vérifiez qu’un changement d’adresse e-mail ou une réinitialisation de facteur ne désactive pas silencieusement la MFA. Les codes de récupération doivent être consommés une seule fois. Journalisez les événements utiles à l’audit sans écrire les secrets, les codes ou les liens dans les logs.

Cette architecture ajoute des frictions : l’utilisateur doit conserver son application d’authentification, et le support doit traiter les pertes de facteur sans transformer la boîte e-mail en voie de contournement. Le TOTP dépend aussi de l’heure de l’appareil, contrairement à un simple lien par e-mail. En revanche, il ajoute une preuve distincte de la possession de la boîte mail. Pour une application qui protège des données sensibles, cet échange est souvent justifié.

Le choix pratique est donc conditionnel. Si Aurabase Auth expose les primitives nécessaires et permet de bloquer les accès avant le second facteur, utilisez-les plutôt que de reconstruire la gestion des sessions. Sinon, gardez Aurabase pour son Auth et PostgreSQL, mais ajoutez uniquement la logique serveur manquante après avoir vérifié qu’elle peut imposer la MFA sur toutes les opérations concernées. La promesse d’une authentification sans mot de passe tient à cette frontière, pas au seul écran de connexion.