How to implement guest mode (anonymous users) with Logto

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

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

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 in 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:

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

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

Phase 2: Let users sign in with Logto#

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:

1. Validate the access token → extracts user ID. See Validate access tokens for how to do this with Logto.
2. 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:

3. Merge guest data to the user account
4. 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:

1. Guest (your app) → manage sessions before users sign up
2. Auth (Logto) → handle sign-up and sign-in
3. 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.