Como implementar o modo convidado (utilizadores anónimos) e converter para utilizadores Logto

Muitas aplicações permitem que utilizadores experimentem funcionalidades antes de se registarem. Pensa em carrinhos de compras, rascunhos de documentos ou preferências guardadas. Os utilizadores esperam que este "modo convidado" funcione automaticamente.

Mas se estiveres a usar o Logto (ou outro fornecedor OIDC) para autenticação, podes perguntar-te: como lido com estes utilizadores anónimos?

Resposta curta: O Logto trata a autenticação, a tua app gere as sessões de convidados. São preocupações separadas.

Neste artigo, mostro-te um padrão simples de três fases para implementares o modo convidado com Logto. Vais aprender a:

• Gerir sessões de convidados no teu backend
• Permitir que convidados se registem através do Logto
• Fundir os dados do convidado na conta real do utilizador

Porque é que não existe "login anónimo" no Logto#

Poderias esperar que o Logto tivesse uma funcionalidade de "login anónimo". Algo como: chamar uma API, obter um token, sem interação do utilizador.

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

O OIDC baseia-se no consentimento do utilizador. O objetivo é verificar "quem é esta pessoa?" Um token anónimo significaria "é alguém, mas não sabemos quem" — o que contraria o propósito.

Pensa da seguinte forma:

• Autenticação = provar identidade ("quem és?")
• Rastreamento de sessão = memorizar ações ("o que fizeste?")

O modo convidado serve para rastreamento de sessão, não autenticação. Por isso, não pertence ao teu sistema de autenticação.

Na verdade, isto é uma boa notícia. Significa que tens uma separação clara:

• O Logto trata da identidade (registo, login, tokens)
• A tua aplicação gere as sessões de convidados (antes de existir identidade)

Deixa cada sistema fazer o que foi desenhado para fazer.

A solução em três fases#

Eis o padrão: Convidado → Autenticação → Fusão

Fase 1: Gerir sessões de convidado sem autenticação#

O teu backend cria e gere sessões de convidado. O Logto ainda não intervém.

Quando um utilizador realiza uma ação significativa (como adicionar ao carrinho), o teu backend:

1. Gera um guest ID (por exemplo, UUID)
2. Devolve-o como cookie ou JWT
3. Guarda as ações do utilizador sob este guest ID

Mantém simples. Uma tabela guest_sessions com guest_id, data e created_at é suficiente.

Fase 2: Permitir que os utilizadores iniciem sessão com o Logto#

Quando o utilizador clica em "Registar" ou "Entrar", ativa o fluxo OIDC padrão do Logto.

O guest ID permanece no cookie/armazenamento durante este processo. Após autenticação bem-sucedida, o teu frontend tem:

• Um access token do Logto (identidade de utilizador)
• O guest ID anterior (dados de convidado)

Fase 3: Fundir de forma segura os dados do convidado com os do utilizador autenticado#

Agora faz a ligação. Chama a API do backend com ambos:

O teu backend deve validar ambos os tokens antes da fusão:

1. Validar o access token → extrai o ID do utilizador. Vê Validar access tokens para saber como fazer isso com Logto.
2. Validar o guest ID → confirmar que é uma sessão de convidado legítima emitida pelo teu backend. Isto é crucial — nunca confies num guest ID fornecido pelo cliente sem verificação.

Só após ambas validações:

3. Fundir os dados de convidado na conta de utilizador
4. Invalidar a sessão de convidado

A lógica de fusão depende do teu negócio. Carrinho de compras? Juntar itens. Rascunhos de documentos? Transferir propriedade. Tu decides.

Como proteger o teu endpoint de fusão com validação de tokens#

O endpoint de fusão é uma operação sensível. Alguns pontos a ter em conta:

• Valida sempre o access token. Não leias apenas o ID do utilizador do corpo do pedido. Decifra e verifica o JWT. Eis como fazer com o Logto.
• Valida sempre o guest ID. Verifica se existe na tua base de dados e se não expirou. Se emitiste como JWT, valida a assinatura.
• Exige autenticação. O endpoint de fusão deve rejeitar pedidos sem access token válido.
• Define um TTL para sessões de convidados. Limpa sessões abandonadas após 30 dias (ou o que fizer sentido para a tua app).

Conclusão#

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

1. Convidado (a tua app) → gerir sessões antes do registo do utilizador
2. Autenticação (Logto) → tratar registo e login
3. Fusão (a tua app) → associar dados de convidado ao utilizador real

Este padrão funciona com qualquer fornecedor OIDC, não só Logto. O ponto-chave é: autenticação e rastreamento de sessões são preocupações separadas. Deixa cada sistema fazer o que sabe fazer.