Comment implémenter le mode invité (utilisateurs anonymes) avec Logto

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

Mais si tu utilises Logto (ou n’importe quel fournisseur OIDC) pour l’authentification, tu peux te demander : comment gérer ces utilisateurs anonymes ?

La réponse courte : Logto gère l’authentification, ton application gère les sessions invité. Ce sont des préoccupations séparées.

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é avec le compte utilisateur réel

Pourquoi il n’y a pas de "connexion anonyme" dans Logto#

Tu pourrais t’attendre à ce que Logto propose une fonction "connexion anonyme". Quelque chose comme : appeler une API, obtenir un jeton, sans interaction de l’utilisateur.

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

OIDC repose sur le consentement utilisateur. Le but est de vérifier "qui est cette personne ?" Un jeton anonyme signifierait "c’est quelqu’un, mais on ne sait pas qui" — ce qui annule le but.

Vois-le ainsi :

• Authentification = prouver l’identité ("qui es-tu ?")
• Suivi de session = mémoriser les actions ("qu’as-tu fait ?")

Le mode invité concerne le suivi de session, pas l’authentification. Il n’a donc pas sa place dans ton système d’authent.

C’est en fait une bonne nouvelle. Cela signifie que tu as une séparation claire :

• Logto gère l’identité (inscription, connexion, jetons)
• Ton app gère les sessions invité (avant l’existence de l’identité)

Laisse chaque système faire ce pour quoi il est conçu.

La solution en trois phases#

Voici le schéma : Invité → Authent → Fusion

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

Ton backend crée et gère les sessions invité. Logto n’entre pas encore en jeu.

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

1. Génère un guest ID (par exemple, UUID)
2. Le retourne comme cookie ou JWT
3. Stocke les actions utilisateur sous ce guest ID

Garde ça simple. Une table guest_sessions avec guest_id, data et created_at suffit.

Phase 2 : Laisser les utilisateurs se connecter avec Logto#

Quand l’utilisateur clique sur "Inscription" ou "Connexion", déclenche le flux standard OIDC Logto.

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

• D’un access token Logto (identité utilisateur)
• Du guest ID précédent (données invité)

Phase 3 : Fusionner les données invité avec l’utilisateur connecté, en toute sécurité#

Relie maintenant les points. Appelle ton backend avec les deux infos :

Ton backend doit valider les deux jetons avant la fusion :

1. Valider l’access token → extrait l’ID utilisateur. Voir Valider les access tokens pour comment faire avec Logto.
2. Valider le guest ID → confirmer que c’est une vraie session invité émise par ton backend. C’est critique — ne fais jamais confiance à un guest ID venant du client sans vérif.

Seulement après validation des deux :

3. Fusionner les données invité dans le compte utilisateur
4. Invalider la session invité

La logique de fusion dépend de ton métier. Panier ? Combine les articles. Brouillons ? Transfère la propriété. C’est à 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 points à garder à l’esprit :

• Valide toujours l’access token. Ne te contente pas de lire l’ID d’utilisateur dans le body. Décode et vérifie le JWT. Voici comment avec Logto.
• Valide toujours le guest ID. Vérifie qu’il existe dans ta base de données et qu’il n’a pas expiré. Si tu l’as émis en JWT, vérifie la signature.
• Exige l’authentification. Le endpoint de fusion doit rejeter les requêtes sans access token valide.
• Définis une durée de vie pour les sessions invité. Nettoie les sessions orphelines après 30 jours (ou selon ce qui a du sens pour ton app).

Conclusion#

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

1. Invité (ton app) → gérer les sessions avant l’inscription utilisateur
2. Authent (Logto) → gérer inscription et connexion
3. Fusion (ton app) → rattacher les données invité à de vrais utilisateurs

Ce schéma fonctionne avec n’importe quel fournisseur OIDC, pas seulement Logto. L’idée clé est : authentification et suivi de session sont des sujets séparés. Laisse chaque système faire ce pour quoi il est fait.