Como implementar o modo convidado (usuários anônimos) e converter para usuários Logto

Muitos aplicativos permitem que os usuários experimentem recursos antes de se cadastrarem. Pense em carrinhos de compras, rascunhos de documentos ou preferências salvas. Os usuários esperam que esse "modo convidado" simplesmente funcione.

Mas se você está usando o Logto (ou qualquer provedor OIDC) para autenticação, talvez se pergunte: como faço para lidar com esses usuários anônimos?

A resposta curta: O Logto cuida da autenticação, seu app cuida das sessões de convidados. São preocupações separadas.

Neste artigo, vou mostrar um padrão simples de três fases para implementar o modo convidado com Logto. Você verá como:

• Gerenciar sessões de convidados no seu backend
• Permitir que convidados se cadastrem através do Logto
• Mesclar dados do convidado à conta real do usuário

Por que não existe "login anônimo" no Logto#

Você pode esperar que o Logto tenha um recurso de "login anônimo". Algo como: chamar uma API, receber um token, sem interação do usuário necessária.

Mas não é assim que o OIDC funciona. Veja o porquê:

OIDC é baseado no consentimento do usuário. O objetivo é verificar "quem é essa pessoa?" Um token anônimo significaria "é alguém, mas não sabemos quem" — o que anula o propósito.

Pense assim:

• Autenticação = provar identidade ("quem é você?")
• Rastreamento de sessão = lembrar ações ("o que você fez?")

O modo convidado é sobre rastreamento de sessão, não autenticação. Então ele não pertence ao seu sistema de autenticação.

Isso na verdade é uma boa notícia. Significa que você tem uma separação clara:

• Logto gerencia identidade (cadastro, login, tokens)
• Seu app gerencia sessões de convidados (antes da identidade existir)

Deixe cada sistema fazer aquilo para o qual foi projetado.

A solução de três fases#

Aqui está o padrão: Convidado → Autenticação → Mesclar

Fase 1: Gerencie sessões de convidados sem autenticação#

Seu backend cria e gerencia sessões de convidados. O Logto ainda não está envolvido.

Quando um usuário realiza uma ação relevante (como adicionar ao carrinho), seu backend:

1. Gera um guest ID (ex: UUID)
2. Retorna isso como um cookie ou JWT
3. Armazena as ações do usuário sob esse guest ID

Mantenha simples. Uma tabela guest_sessions com guest_id, data e created_at já basta.

Fase 2: Permita que usuários façam login com Logto#

Quando o usuário clica em "Cadastrar" ou "Entrar", acione o fluxo padrão OIDC do Logto.

O guest ID permanece no cookie/armazenamento durante esse processo. Após a autenticação bem-sucedida, seu frontend terá:

• Um access token do Logto (identidade do usuário)
• O guest ID de antes (dados do convidado)

Fase 3: Mescle com segurança os dados do convidado ao usuário autenticado#

Agora, conecte os pontos. Chame sua API backend com ambos:

Seu backend precisa validar ambos tokens antes de mesclar:

1. Valide o access token → extrai o user ID. Veja Validar access tokens para como fazer isso com o Logto.
2. Valide o guest ID → confirme que é uma sessão de convidado criada pelo seu backend. Isso é crucial — nunca confie em um guest ID vindo do client sem verificação.

Só depois das duas validações:

3. Mescle os dados do convidado à conta do usuário
4. Invalide a sessão de convidado

A lógica da mesclagem depende do seu negócio. Carrinho de compras? Junte os itens. Rascunhos de documento? Transfira a posse. Você decide.

Como proteger seu endpoint de mescla com validação de tokens#

O endpoint de mescla é uma operação sensível. Algumas coisas importantes:

• Sempre valide o access token. Não apenas leia o user ID do corpo da requisição. Decodifique e verifique o JWT. Veja como fazer isso com o Logto.
• Sempre valide o guest ID. Verifique se existe no banco e se não expirou. Se você emitiu como JWT, valide a assinatura.
• Exija autenticação. O endpoint de mescla deve rejeitar requisições sem um access token válido.
• Defina um TTL para sessões de convidado. Limpe sessões abandonadas após 30 dias (ou o que fizer sentido para seu app).

Conclusão#

O modo convidado com Logto segue um padrão simples:

1. Convidado (seu app) → gerencia sessões antes do cadastro
2. Autenticação (Logto) → cuida do cadastro e login
3. Mesclar (seu app) → conecta os dados do convidado ao usuário real

Esse padrão funciona com qualquer provedor OIDC, não só o Logto. O ponto chave é: autenticação e rastreamento de sessão são preocupações separadas. Deixe cada sistema fazer aquilo que foi projetado.