Auth QR code : le pattern WhatsApp Web avec Supabase

Pour connecter le site web a l'app mobile, je voulais quelque chose d'instantane. Pas de formulaire, pas de mot de passe a retaper. Le pattern WhatsApp Web : scanner un QR code et boom, connecte. Voici comment j'ai implemente ce systeme dans TAMSIV avec Supabase Realtime, un fallback polling, et une UX qui impressionne.

Points cles a retenir :
- Le QR code encode un UUID de session unique — le site s'abonne en temps reel via Supabase Realtime.
- Un fallback polling HTTP (toutes les 2s) prend le relais si le Realtime echoue apres 3 secondes.
- Le QR code expire apres 5 minutes et se regenere automatiquement a 4min30 avec countdown visuel.
- L'ensemble du systeme tient en 300 lignes cote web et 150 cote mobile.

Pourquoi choisir l'authentification par QR code plutot qu'un formulaire classique ?

L'authentification classique — email + mot de passe — fonctionne. Mais elle cree de la friction. L'utilisateur a deja un compte sur l'app mobile. Lui demander de retaper ses identifiants sur le web, c'est l'obliger a se souvenir d'un mot de passe, potentiellement chercher dans son gestionnaire, et risquer un echec.

Le QR code elimine cette friction. L'utilisateur est deja authentifie sur son telephone. Scanner un code prend 2 secondes. C'est le pattern popularise par WhatsApp Web, Telegram et Discord. Les utilisateurs le connaissent et l'attendent.

Pour TAMSIV, c'est d'autant plus pertinent que le site web sert de complement a l'app mobile — pas de remplacement. Le QR code materialise ce lien entre les deux plateformes.

Comment fonctionne le flux d'authentification QR code ?

Du point de vue de l'utilisateur, c'est magique : je scanne, je suis connecte. Du point de vue technique, c'est un ballet precis de tokens et de channels temps reel. Voici les etapes :

1. Generation : l'utilisateur ouvre tamsiv.com. Le site genere un UUID de session unique et cree une entree dans Supabase avec le statut "pending".
2. Affichage : le QR code encode cet UUID. Le site s'abonne au channel Supabase Realtime pour cette session.
3. Scan : l'utilisateur scanne le QR code avec l'app mobile TAMSIV. L'app decode l'UUID.
4. Confirmation : l'app envoie son JWT existant + l'UUID au backend. Le backend verifie le JWT, genere un token d'auth web, et met a jour la session en "confirmed".
5. Connexion : le site recoit la mise a jour via Realtime, recupere le token, et l'utilisateur est connecte.

Ce flux garantit que seul un utilisateur deja authentifie sur l'app mobile peut confirmer la session. Le token genere pour le web a une duree de vie limitee et est independant du token mobile — les deux sessions sont separees.

Comment Supabase Realtime permet-il la connexion instantanee ?

Supabase Realtime est le composant qui rend l'experience instantanee. Quand l'app mobile confirme la session, le changement en base de donnees est detecte par le channel Realtime et pousse vers le navigateur — en quelques millisecondes.

Techniquement, le site s'abonne a un channel specifique filtrant sur l'UUID de session :

supabase.channel('qr-auth-SESSION_UUID')
  .on('postgres_changes', { event: 'UPDATE', filter: `id=eq.SESSION_UUID` }, callback)
  .subscribe()

Le callback est declenche des que le statut passe de "pending" a "confirmed". Le token d'auth est inclus dans la mise a jour. L'utilisateur voit la page de connexion se transformer en dashboard — sans aucune action supplementaire.

C'est le meme mecanisme Realtime que j'utilise pour le cache de contenu et les mises a jour en direct dans les groupes collaboratifs.

Pourquoi un fallback polling est-il indispensable ?

Supabase Realtime fonctionne tres bien dans la majorite des cas. Mais "la majorite" ne suffit pas pour une feature d'authentification. Certains reseaux d'entreprise bloquent les WebSockets. Certains proxies les interrompent. Certains navigateurs ont des bugs specifiques.

J'ai implemente un fallback polling HTTP qui prend le relais automatiquement :

• Le site tente la connexion Realtime pendant 3 secondes
• Si la connexion echoue, il bascule silencieusement sur un polling HTTP toutes les 2 secondes
• Le polling interroge directement la base : "est-ce que la session UUID est confirmee ?"
• L'utilisateur ne sait jamais quel mecanisme est utilise — l'experience est identique

Le delai de 3 secondes est un compromis entre reactivite et fiabilite. Plus court, on passerait trop vite au polling (moins efficace). Plus long, l'utilisateur attendrait sans feedback.

Ce pattern dual (Realtime + polling) est une bonne pratique pour toute fonctionnalite critique. Ne jamais dependre d'un seul canal de communication.

Comment securiser le systeme de QR code ?

L'authentification par QR code introduit des vecteurs d'attaque specifiques. Voici les mesures implementees dans TAMSIV :

• Expiration a 5 minutes : un QR code non utilise devient invalide. Ca empeche la reutilisation de screenshots ou de QR codes partages.
• Usage unique : une session ne peut etre confirmee qu'une seule fois. Toute tentative subsequente est rejetee.
• Auth requise cote mobile : seul un utilisateur connecte a l'app peut confirmer. Le JWT est verifie cote backend comme pour les WebSockets.
• Token ephemere : le token genere pour le web est a usage unique et a duree limitee. Il sert uniquement a initier la session web, pas comme token permanent.
• UUID v4 imprevisible : l'UUID utilise pour la session est genere avec un CSPRNG (Cryptographically Secure Pseudo-Random Number Generator). Impossible a deviner.

Ces mesures sont alignees avec les recommandations OWASP pour l'authentification.

Quelle est l'experience utilisateur finale ?

L'UX a ete soignee dans les moindres details :

1. Auto-regeneration du QR : a 4min30, le QR code se regenere automatiquement avec un nouveau UUID. Un countdown visuel indique le temps restant. L'utilisateur n'a jamais a rafraichir la page.
2. Animation de connexion : quand le scan est confirme, une animation smooth transitionne entre la page de login et le dashboard. Pas de rechargement de page.
3. Options alternatives : email/password et Magic Link sont disponibles en dessous du QR code. Aucun utilisateur n'est bloque si le scan ne fonctionne pas.
4. Responsive : sur mobile (quand le QR n'a pas de sens), l'interface privilegie email/password et Magic Link. Le QR est affiche uniquement sur desktop/tablet.

Le systeme d'onboarding guide les nouveaux utilisateurs web vers le QR code en premier, avec un fallback naturel vers les methodes classiques.

Combien de code represente cette feature ?

Environ 300 lignes cote web (composant QR, logique Realtime/polling, gestion des tokens) et 150 lignes cote mobile (scanner, verification, appel API de confirmation). C'est compact.

La raison : Supabase fait le gros du travail. La base de donnees stocke les sessions, Realtime pousse les updates, Auth gere les tokens. Le code applicatif se concentre sur l'orchestration et l'UX.

C'est typique de l'approche architecture Supabase de TAMSIV : maximiser ce que la plateforme offre nativement, minimiser le code custom. Le meme principe qui guide la strategie d'internationalisation et le systeme de gamification.

Quelles alternatives au QR code existent pour le cross-device auth ?

D'autres approches sont possibles pour l'authentification cross-device :

• Deep links : envoyer un lien cliquable a l'utilisateur qui ouvre l'app et confirme. Marche bien mais necessite que l'utilisateur soit sur le meme appareil — ce qui n'est pas le cas ici.
• Code numerique : afficher un code a 6 chiffres que l'utilisateur tape dans l'app. Plus universel mais plus lent (6 secondes vs 2 secondes pour un scan).
• Push notification : envoyer une notification push avec un bouton "Confirmer". Necessite que les notifications soient activees et que le systeme FCM soit configure.
• WebAuthn/Passkeys : la solution moderne mais pas encore universellement supportee sur tous les devices.

Le QR code offre le meilleur compromis entre rapidite, universalite et "effet wahou". C'est le genre de feature qui fait dire "c'est bien pense" — et c'est exactement l'impression que TAMSIV veut laisser.

FAQ

Que se passe-t-il si je ferme le navigateur apres avoir scanne le QR code ?

Le token genere pour la session web est stocke en local storage. A la prochaine visite, le site verifie ce token et te reconnecte automatiquement si le token est encore valide. Tu n'as pas besoin de rescanner le QR code a chaque visite.

Peut-on avoir plusieurs sessions web en meme temps ?

Oui, chaque scan cree une session independante. Tu peux etre connecte sur ton ordinateur de bureau et ton laptop simultanement. Chaque session a son propre token et peut etre revoquee individuellement depuis les parametres de l'app.

Le QR code fonctionne-t-il sans connexion internet ?

Non, le QR code necessite une connexion internet active des deux cotes (mobile et web). Le scan decode un UUID qui doit etre verifie en ligne via Supabase. Pour une utilisation hors ligne, les methodes email/password restent disponibles.

Comment TAMSIV protege-t-il contre le QR code phishing ?

Le QR code encode uniquement un UUID de session — pas de donnees sensibles. La confirmation se fait via l'app officielle TAMSIV qui verifie le domaine et la validite de la session. Un QR code forge redirigerait vers un UUID inexistant en base et echouerait immediatement.

Pourquoi le QR code expire-t-il apres 5 minutes seulement ?

Cinq minutes est un compromis securite/UX. C'est assez long pour que l'utilisateur ait le temps de prendre son telephone et scanner. C'est assez court pour limiter la fenetre d'attaque si le QR est intercepte. La regeneration automatique a 4min30 garantit un QR toujours frais sans action de l'utilisateur.