### 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