Como implementar o modo visitante (usuários anônimos) com 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 visitante" simplesmente funcione.

Mas se você usa o Logto (ou qualquer provedor OIDC) para autenticação, pode se perguntar: como lidar com esses usuários anônimos?

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

Neste artigo, vou mostrar um padrão simples em três fases para implementar o modo visitante com Logto. Você vai aprender como:

• Gerenciar sessões de visitantes no seu backend
• Permitir que visitantes se cadastrem pelo Logto
• Unir os dados do visitante à 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, pegar um token, sem interação do usuário.

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

OIDC é construído em torno do consentimento do usuário. O objetivo é verificar "quem é essa pessoa?" Um token anônimo significaria "este é alguém, mas não sabemos quem" — o que vai contra o propósito.

Veja desta forma:

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

O modo visitante é sobre rastreamento de sessão, não autenticação. Por isso, não pertence ao seu sistema de autenticação.

Na verdade, isso é uma boa notícia. Significa que você tem uma separação clara:

• O Logto cuida da identidade (cadastro, login, tokens)
• Seu app cuida das sessões de visitantes (antes da identidade existir)

Deixe cada sistema fazer o que foi projetado para fazer.

A solução em três fases#

Aqui está o padrão: Visitante → Autenticação → União

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

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

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

1. Gera um ID de visitante (por exemplo, UUID)
2. Retorna como um cookie ou JWT
3. Armazena as ações do usuário nesse ID de visitante

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

Fase 2: Permita que usuários se autentiquem com o Logto#

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

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

• Um token de acesso do Logto (identidade do usuário)
• O guest ID anterior (dados do visitante)

Fase 3: Una os dados do visitante ao usuário autenticado#

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

Seu backend precisa validar ambos antes de unir:

1. Validar o token de acesso → extrai o ID do usuário. Veja Validar tokens de acesso para saber como fazer isso com o Logto.
2. Validar o guest ID → conferir se é uma sessão de visitante verdadeira emitida pelo seu backend. Isso é crítico — jamais confie em um guest ID vindo do cliente sem verificação.

Só após ambas as validações:

3. Una os dados do visitante à conta do usuário
4. Invalide a sessão do visitante

A lógica de união depende do seu negócio. Carrinho de compras? Junte itens. Rascunhos de documentos? Transfira a propriedade. Você decide.

Como proteger seu endpoint de união com validação de token#

O endpoint de união é uma operação sensível. Veja algumas recomendações:

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

Conclusão#

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

1. Visitante (seu app) → gerencie sessões antes do cadastro dos usuários
2. Autenticação (Logto) → gerencie cadastro e login
3. União (seu app) → conecte dados do visitante ao usuário real

Este padrão funciona com qualquer provedor OIDC, não só o Logto. O principal ponto é: autenticação e rastreamento de sessão são preocupações diferentes. Deixe cada sistema cuidar daquilo para o qual foi construído.