Português (Brasil)

modo convidado
usuários anônimos
conversão de usuários

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

Aprenda como implementar o modo convidado e converter para usuários Logto usando um padrão de três fases: gerencie sessões de convidados, autentique com OIDC e mescle com segurança os dados do convidado às contas de usuário.

Yijun

Developer

1/9/2026

Pare de perder semanas com autenticação de usuários

Lance aplicativos seguros mais rapidamente com o Logto. Integre a autenticação de usuários em minutos e concentre-se no seu produto principal.

Começar

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

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:

Gera um guest ID (ex: UUID)
Retorna isso como um cookie ou JWT
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.

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:

Valide o access token → extrai o user ID. Veja Validar access tokens para como fazer isso com o Logto.
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:

Mescle os dados do convidado à conta do usuário
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:

Convidado (seu app) → gerencia sessões antes do cadastro
Autenticação (Logto) → cuida do cadastro e login
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.

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

A solução de três fases#

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

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

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

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

Conclusão#

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

A solução de três fases#

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

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

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

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

Conclusão#

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

A solução de três fases

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

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

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

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

Conclusão

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

A solução de três fases

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

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

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

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

Conclusão