docv/docs/authentication.md

Authentification 4NK (iframe + MessageBus)

Cette application intègre un flux d’authentification 4NK encapsulé dans une iframe et orchestré côté client via MessageBus.

Composants impliqués

• components/4nk/AuthModal.tsx: modal d’auth 4NK, gère l’état d’affichage, le chargement, les erreurs et la progression
• components/4nk/Iframe.tsx et lib/4nk/IframeReference.ts: gestion de l’iframe 4NK et de sa référence DOM
• lib/4nk/MessageBus.ts: protocole de communication window.postMessage avec l’iframe
• lib/4nk/UserStore.ts: stockage des tokens (sessionStorage) et pairingId utilisateur
• lib/4nk/MockService.ts: implémentations simulées pour le mode démonstration

Protocole côté client

Séquence attendue côté UI lors d’une authentification standard :

1. L’iframe se charge et envoie un message LISTENING
2. Le client envoie REQUEST_LINK
3. Réception LINK_ACCEPTED avec accessToken et refreshToken
4. Le client envoie GET_PAIRING_ID pour récupérer l’identifiant d’appairage

Le MessageBus fournit des méthodes utilitaires supplémentaires (validateToken, renewToken, getProcesses, etc.) utilisées par l’espace /dashboard.

Mode démonstration (mock)

• Sur /login, saisir l’identifiant d’entreprise 1234 active le mode mock dans MessageBus
• Les appels sont alors redirigés vers MockService (tokens et données factices), sans dépendre de l’iframe
• Le dashboard affiche alors des statistiques et listes récentes simulées

Configuration

• NEXT_PUBLIC_4NK_IFRAME_URL: origine de l’iframe (ex. https://dev.4nk.io)
• Contrainte d’origine: MessageBus n’accepte que les événements provenant d’origines 4NK/localhost

Comportements principaux

• Stockage des tokens via UserStore.connect(accessToken, refreshToken)
• Appairage: getUserPairingId() stocke l’ID côté UserStore
• Vérification en dashboard: validateToken() côté 4NK (ou mock) et affichage conditionnel