Cómo implementar el modo invitado (usuarios anónimos) con 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 usas Logto (o cualquier proveedor OIDC) para la autenticación, puedes preguntarte: ¿cómo manejo estos usuarios anónimos?

La respuesta corta: Logto se encarga de la autenticación, tu aplicación se encarga de las sesiones de invitados. Son preocupaciones separadas.

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

• Gestionar sesiones de invitados en tu backend
• Permitir que los invitados se registren a través de Logto
• Fusionar los datos de invitados a la cuenta real del usuario

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

Podrías esperar que Logto tenga una función de "inicio de sesión anónimo". Algo así como: llamar a una API, obtener un token, sin interacción del usuario.

Pero así no funciona OIDC. Aquí está el porqué:

OIDC se basa en el consentimiento del usuario. Todo el objetivo es verificar "¿quién es esta persona?" Un token anónimo significaría "esta es alguien, pero no sabemos quién es" — lo cual va en contra del propósito.

Piensa en esto así:

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

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

En realidad esto es una buena noticia. Significa que tienes una separación limpia:

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

Permite que cada sistema haga para lo que está diseñado.

La solución de tres fases#

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

Fase 1: Manejar sesiones de invitados sin autenticación#

Tu backend crea y gestiona sesiones de invitados. Aún no está involucrado Logto.

Cuando un usuario realiza una acción significativa (como agregar al carrito), tu backend:

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

Hazlo sencillo. Una tabla guest_sessions con guest_id, data y created_at es suficiente.

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

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

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

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

Fase 3: Fusionar de forma segura los datos del invitado al usuario autenticado#

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

Tu backend debe validar ambos tokens antes de fusionar:

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

Solo después de que ambas validaciones sean correctas:

3. Fusionar datos del invitado a la cuenta de usuario
4. Invalidar la sesión de invitado

La lógica de la fusión depende de tu negocio. ¿Carrito de compras? Combinar los artículos. ¿Borradores de documentos? Transferir 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. Ten en cuenta lo siguiente:

• Siempre valida el access token. No leas solo el user ID del cuerpo de la petición. Decodifica y verifica el JWT. Aquí tienes cómo hacerlo con Logto.
• Siempre valida el guest ID. Revisa que existe en tu base de datos y no ha expirado. Si lo emites como un JWT, verifica la firma.
• Requiere autenticación. El endpoint de fusión debe rechazar solicitudes que no tengan un access token válido.
• Configura un TTL para las sesiones de invitados. Limpia las 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 sencillo:

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

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