Comment implémenter le mode invité (utilisateurs anonymes) et les convertir en utilisateurs Logto

De nombreuses applications permettent aux utilisateurs d'essayer des fonctionnalités avant de s'inscrire. Pensez aux paniers d'achat, aux brouillons de documents ou aux préférences enregistrées. Les utilisateurs s'attendent à ce que ce « mode invité » fonctionne tout simplement.

Mais si tu utilises Logto (ou tout autre fournisseur OIDC) pour l'authentification, tu pourrais te demander : comment gérer ces utilisateurs anonymes ?

La réponse courte : Logto gère l'authentification, ton appli gère les sessions invité. Ce sont deux préoccupations distinctes.

Dans cet article, je vais te montrer un schéma simple en trois phases pour implémenter le mode invité avec Logto. Tu apprendras à :

• Gérer les sessions invité dans ton backend
• Permettre aux invités de s'inscrire via Logto
• Fusionner les données invité vers le vrai compte utilisateur

Pourquoi il n'y a pas de « connexion anonyme » dans Logto#

Tu pourrais t'attendre à ce que Logto propose une fonctionnalité de « connexion anonyme ». Par exemple : appeler une API, obtenir un jeton, sans interaction utilisateur.

Mais ce n'est pas ainsi que fonctionne OIDC. Voici pourquoi :

OIDC repose sur le consentement de l'utilisateur. L'objectif est de vérifier « qui est cette personne ? ». Un jeton anonyme signifierait « c'est quelqu'un, mais on ne sait pas qui » — ce qui va à l'encontre du principe même.

Vois les choses ainsi :

• Authentification = prouver son identité (« qui es-tu ? »)
• Suivi de session = se souvenir des actions (« qu'as-tu fait ? »)

Le mode invité concerne le suivi de session, pas l'authentification. Cela ne relève donc pas de ton système d'authentification.

C'est en réalité une bonne nouvelle. Cela signifie que tu as une séparation nette :

• Logto gère l'identité (inscription, connexion, jetons)
• Ton appli gère les sessions invité (avant que l'identité n'existe)

Chaque système fait ce pour quoi il est conçu.

La solution en trois phases#

Voici le schéma : Invité → Auth → Fusionner

Phase 1 : Gérer les sessions invité sans authentification#

Ton backend crée et gère les sessions invité. Logto n'intervient pas encore.

Lorsqu'un utilisateur effectue une action significative (par exemple, ajouter au panier), ton backend :

1. Génère un guest ID (par ex., UUID)
2. Le renvoie en cookie ou JWT
3. Enregistre les actions utilisateur sous ce guest ID

Reste simple. Une table guest_sessions avec guest_id, data et created_at suffit.

Phase 2 : Permettre aux utilisateurs de se connecter avec Logto#

Quand l'utilisateur clique sur « S'inscrire » ou « Se connecter », déclenche le flux OIDC standard de Logto.

Le guest ID reste dans le cookie/stockage pendant ce processus. Après une authentification réussie, ton frontend a maintenant :

• Un access token de Logto (identité utilisateur)
• Le guest ID d'avant (données invité)

Phase 3 : Fusionner en toute sécurité les données invité à l'utilisateur authentifié#

Maintenant, connecte les points. Appelle ton API backend avec les deux :

Ton backend doit valider les deux jetons avant de fusionner :

1. Valide l'access token → extrais l'ID utilisateur. Consulte la validation des access tokens pour savoir comment faire avec Logto.
2. Valide le guest ID → vérifie qu'il existe bien dans ta base et a bien été émis par ton backend. C'est critique — ne fais jamais confiance à un guest ID reçu du client sans validation.

Une fois les deux validations passées :

3. Fusionne les données invité avec le compte utilisateur
4. Invalide la session invité

La logique de fusion dépend de ton métier. Panier d'achat ? Fusionne les articles. Brouillons de documents ? Transfère la propriété. À toi de décider.

Comment sécuriser ton endpoint de fusion avec validation des jetons#

Le endpoint de fusion est une opération sensible. Quelques éléments à garder en tête :

• Valide toujours l'access token. Ne lis pas simplement l'ID utilisateur dans le corps de la requête. Décode et vérifie le JWT. Voici comment faire avec Logto.
• Valide toujours le guest ID. Vérifie qu'il existe dans ta base et qu'il n'est pas expiré. S'il est délivré comme JWT, vérifie la signature.
• Exige l'authentification. Le endpoint de fusion doit rejeter les requêtes sans access token valide.
• Définis un TTL pour les sessions invité. Nettoie les sessions abandonnées après 30 jours (ou ce qui fait sens pour ton appli).

Conclusion#

Le mode invité avec Logto suit un schéma simple :

1. Invité (ton appli) → gérer les sessions avant inscription
2. Auth (Logto) → gérer inscription et connexion
3. Fusionner (ton appli) → relier les données invité à l'utilisateur réel

Ce schéma fonctionne avec tout fournisseur OIDC, pas seulement Logto. L'idée clé : authentification et suivi de session sont des préoccupations distinctes. Que chaque système fasse ce pour quoi il est construit.