Como implementar o modo convidado (utilizadores anónimos) com o Logto

Muitas aplicações permitem que os 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 sem problemas.

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

A resposta curta: O Logto trata da autenticação, a tua aplicação gere as sessões de convidados. São preocupações separadas.

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

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

Porque 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, receber um token, sem necessidade de interação do utilizador.

Mas não é assim que o OIDC funciona. Aqui está o porquê:

OIDC é construído em torno do consentimento do utilizador. O ponto essencial é verificar "quem é esta pessoa?" Um token anónimo significaria "isto é alguém, mas não sabemos quem" — o que anula o objetivo.

Vê a coisa desta forma:

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

O modo convidado é sobre rastreio de sessão, não autenticação. Portanto, não pertence ao teu sistema de autenticação.

Na verdade, isto são boas notícias. Significa que tens uma separação limpa:

• O Logto trata da identidade (registo, início de sessão, tokens)
• A tua app gere as sessões de convidados (antes de existir identidade)

Deixa cada sistema fazer aquilo para que foi desenhado.

A solução de três fases#

Aqui está o padrão: Convidado → Auth → Fusão

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

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

Quando o utilizador faz uma ação relevante (como adicionar ao carrinho), o teu backend:

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

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

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

Quando o utilizador clica em "Registar" ou "Iniciar sessão", desencadeia o fluxo OIDC padrão do Logto.

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

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

Fase 3: Fundir os dados de convidado com utilizadores autenticados#

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 saberes como fazer isto com o Logto.
2. Validar o guest ID → confirma que é uma sessão de convidado real emitida pelo teu backend. Isto é crítico — nunca confies num guest ID vindo do cliente sem verificação.

Só depois de ambas as validações passarem:

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

A lógica de fusão depende do teu negócio. Carrinho de compras? Junta os itens. Rascunhos de documentos? Transfere a propriedade. Tu decides.

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

O endpoint de fusão é uma operação sensível. Algumas coisas 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. Vê como fazer com o Logto.
• Valida sempre o guest ID. Confirma se existe na tua base de dados e se não expirou. Se emitido como JWT, verifica a assinatura.
• Exige autenticação. O endpoint de fusão deve rejeitar pedidos sem access token válido.
• Define TTL para sessões de convidados. Limpa sessões abandonadas após 30 dias (ou o que fizer sentido para a tua aplicação).

Conclusão#

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

1. Convidado (tua app) → gerir sessões antes do registo
2. Auth (Logto) → gerir registo e login
3. Fusão (tua app) → ligar dados de convidado a utilizadores reais

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