English

guest mode
anonymous users
user conversion

How to implement guest mode (anonymous users) and convert to Logto users

Learn how to implement guest mode and convert to Logto users using a three-phase pattern: manage guest sessions, authenticate with OIDC, and securely merge guest data to user accounts.

Yijun

Developer

1/9/20263 min read

Stop wasting weeks on user auth

Launch secure apps faster with Logto. Integrate user auth in minutes, and focus on your core product.

Get started

Many apps let users try features before signing up. Think shopping carts, document drafts, or saved preferences. Users expect this "guest mode" to just work.

But if you're using Logto (or any OIDC provider) for authentication, you might wonder: how do I handle these anonymous users?

The short answer: Logto handles authentication, your app handles guest sessions. They're separate concerns.

In this article, I'll show you a simple three-phase pattern to implement guest mode with Logto. You'll learn how to:

Manage guest sessions in your backend
Let guests sign up through Logto
Merge guest data to the real user account

You might expect Logto to have an "anonymous login" feature. Something like: call an API, get a token, no user interaction needed.

But that's not how OIDC works. Here's why:

OIDC is built around user consent. The whole point is to verify "who is this person?" An anonymous token would mean "this is someone, but we don't know who" — which defeats the purpose.

Think of it this way:

Authentication = proving identity ("who are you?")
Session tracking = remembering actions ("what did you do?")

Guest mode is about session tracking, not authentication. So it doesn't belong to your auth system.

This is actually good news. It means you have a clean separation:

Logto handles identity (sign-up, sign-in, tokens)
Your app handles guest sessions (before identity exists)

Let each system do what it's designed for.

The three-phase solution

Here's the pattern: Guest → Auth → Merge

Phase 1: Handle guest sessions without authentication

Your backend creates and manages guest sessions. Logto isn't involved yet.

When a user takes a meaningful action (like adding to cart), your backend:

Generates a guest ID (e.g., UUID)
Returns it as a cookie or JWT
Stores user actions under this guest ID

Keep it simple. A guest_sessions table with guest_id, data, and created_at is enough.

When the user clicks "Sign up" or "Sign in", trigger the standard Logto OIDC flow.

The guest ID stays in the cookie/storage during this process. After successful authentication, your frontend now has:

An access token from Logto (user identity)
The guest ID from before (guest data)

Phase 3: Securely merge guest data to authenticated users

Now connect the dots. Call your backend API with both:

Your backend must validate both tokens before merging:

Validate the access token → extracts user ID. See Validate access tokens for how to do this with Logto.
Validate the guest ID → confirm it's a real guest session your backend issued. This is critical — never trust a guest ID from the client without verification.

Only after both validations pass:

Merge guest data to the user account
Invalidate the guest session

The merge logic depends on your business. Shopping cart? Combine items. Document drafts? Transfer ownership. You decide.

How to secure your merge endpoint with token validation

The merge endpoint is a sensitive operation. A few things to keep in mind:

Always validate the access token. Don't just read the user ID from the request body. Decode and verify the JWT. Here's how to do it with Logto.
Always validate the guest ID. Check it exists in your database and hasn't expired. If you issued it as a JWT, verify the signature.
Require authentication. The merge endpoint should reject requests without a valid access token.
Set a TTL for guest sessions. Clean up abandoned sessions after 30 days (or whatever makes sense for your app).

Conclusion

Guest mode with Logto follows a simple pattern:

Guest (your app) → manage sessions before users sign up
Auth (Logto) → handle sign-up and sign-in
Merge (your app) → connect guest data to real users

This pattern works with any OIDC provider, not just Logto. The key insight is: authentication and session tracking are separate concerns. Let each system do what it's built for.

Why there's no "anonymous login" in Logto#

The three-phase solution#

Phase 1: Handle guest sessions without authentication#

Phase 2: Let users sign in with Logto#

Phase 3: Securely merge guest data to authenticated users#

How to secure your merge endpoint with token validation#

Conclusion#

Why there's no "anonymous login" in Logto#

The three-phase solution#

Phase 1: Handle guest sessions without authentication#

Phase 2: Let users sign in with Logto#

Phase 3: Securely merge guest data to authenticated users#

How to secure your merge endpoint with token validation#

Conclusion#

Why there's no "anonymous login" in Logto

The three-phase solution

Phase 1: Handle guest sessions without authentication

Phase 2: Let users sign in with Logto

Phase 3: Securely merge guest data to authenticated users

How to secure your merge endpoint with token validation

Conclusion

Why there's no "anonymous login" in Logto

The three-phase solution

Phase 1: Handle guest sessions without authentication

Phase 2: Let users sign in with Logto

Phase 3: Securely merge guest data to authenticated users

How to secure your merge endpoint with token validation

Conclusion