Cómo implementar el modo invitado (usuarios anónimos) y convertirlos en usuarios de Logto

Muchas aplicaciones permiten a los usuarios probar funciones antes de registrarse. Piensa en carritos de compras, borradores de documentos o preferencias guardadas. Los usuarios esperan que este "modo invitado" simplemente funcione.

Pero si utilizas Logto (o cualquier proveedor OIDC) para la autenticación, podrías preguntarte: ¿cómo gestiono a estos usuarios anónimos?

La respuesta corta: Logto gestiona la autenticación, tu app gestiona las sesiones de invitados. Son asuntos separados.

En este artículo, te mostraré un sencillo patrón de tres fases para implementar modo invitado con Logto. Aprenderás a:

• Gestionar sesiones de invitado en tu backend
• Permitir que los invitados se registren mediante Logto
• Fusionar los datos de invitado en la cuenta real del usuario

Por qué no existe "inicio de sesión anónimo" en Logto#

Quizás esperabas que Logto tuviera una función de "inicio de sesión anónimo". Algo así como: llamas una API, obtienes un token y no necesita interacción del usuario.

Pero así no funciona OIDC. Aquí tienes la razón:

OIDC está construido en torno al consentimiento del usuario. El propósito principal es verificar "¿quién es esta persona?" Un token anónimo significaría "esto es alguien, pero no sabemos quién" — lo que va en contra de la idea.

Piensa de esta forma:

• Autenticación = probar la identidad ("¿quién eres?")
• Seguimiento de sesión = recordar acciones ("¿qué hiciste?")

El modo invitado trata sobre el seguimiento de sesión, no sobre autenticación. Así que no le corresponde a tu sistema de autenticación.

Esto en realidad es una buena noticia. Significa que tienes una separación clara:

• Logto gestiona la identidad (registro, inicio de sesión, tokens)
• Tu app gestiona las sesiones de invitado (antes de que exista identidad)

Deja que cada sistema haga lo que fue diseñado para hacer.

La solución de tres fases#

Aquí está el patrón: Invitado → Auth → Fusionar

Fase 1: Gestiona sesiones de invitado sin autenticación#

Tu backend crea y gestiona sesiones de invitado. Logto aún no participa.

Cuando un usuario realiza una acción relevante (como añadir al carrito), tu backend:

1. Genera un ID de invitado (por ejemplo, UUID)
2. Lo retorna como cookie o JWT
3. Guarda las acciones del usuario bajo este ID de invitado

Mantenlo simple. Una tabla sesiones_invitado con id_invitado, datos y creado_en es suficiente.

Fase 2: Permite que los usuarios inicien sesión con Logto#

Cuando el usuario hace clic en "Registrarse" o "Iniciar sesión", dispara el flujo estándar OIDC de Logto.

El ID de invitado permanece en la cookie/almacenamiento durante este proceso. Tras la autenticación exitosa, tu frontend tiene:

• Un token de acceso de Logto (identidad del usuario)
• El ID de invitado anterior (datos del invitado)

Fase 3: Fusiona de forma segura los datos de invitado en usuarios autenticados#

Ahora conecta los puntos. Llama a tu API de backend con ambos:

Tu backend debe validar ambos tokens antes de fusionar:

1. Validar el token de acceso → extrae el ID de usuario. Consulta Validar tokens de acceso para ver cómo hacerlo con Logto.
2. Validar el ID de invitado → confirma que es una sesión de invitado real que emitió tu backend. Esto es fundamental — nunca confíes en un ID de invitado proveniente del cliente sin verificación.

Sólo después de que ambas validaciones pasen:

3. Fusiona los datos de invitado a la cuenta de usuario
4. Invalida la sesión de invitado

La lógica de fusión depende de tu negocio. ¿Carritos de compra? Combina los ítems. ¿Borradores de documentos? Transfiere la propiedad. Tú decides.

Cómo asegurar tu endpoint de fusión con validación de tokens#

El endpoint de fusión es una operación sensible. Algunos puntos a tener en mente:

• Siempre valida el token de acceso. No sólo leas el ID de usuario desde el cuerpo de la petición. Decodifica y verifica el JWT. Aquí te mostramos cómo hacerlo con Logto.
• Siempre valida el ID de invitado. Verifica que existe en tu base de datos y que no ha expirado. Si lo emitiste como JWT, verifica la firma.
• Requiere autenticación. El endpoint de fusión debe rechazar peticiones sin un token de acceso válido.
• Define un TTL para las sesiones de invitado. Elimina sesiones abandonadas después de 30 días (o lo que tenga sentido para tu app).

Conclusión#

El modo invitado con Logto sigue un patrón simple:

1. Invitado (tu app) → gestiona sesiones antes del registro
2. Auth (Logto) → gestiona registro e inicio de sesión
3. Fusionar (tu app) → conecta los datos de invitado con usuarios reales

Este patrón funciona con cualquier proveedor OIDC, no sólo Logto. El punto clave es: la autenticación y el seguimiento de sesión son preocupaciones separadas. Que cada sistema haga lo que fue creado para hacer.