Come implementare la modalità ospite (utenti anonimi) con Logto

Molte app permettono agli utenti di provare le funzionalità prima di registrarsi. Pensa ai carrelli della spesa, alle bozze di documenti o alle preferenze salvate. Gli utenti si aspettano che questa "modalità ospite" funzioni senza problemi.

Ma se usi Logto (o qualsiasi provider OIDC) per l'autenticazione, potresti chiederti: come gestisco questi utenti anonimi?

La risposta breve: Logto gestisce l'autenticazione, la tua app gestisce le sessioni ospite. Sono due aspetti separati.

In questo articolo ti mostrerò uno schema semplice in tre fasi per implementare la modalità ospite con Logto. Imparerai come:

• Gestire le sessioni ospite nel tuo backend
• Permettere agli ospiti di registrarsi tramite Logto
• Unire i dati ospite all'account utente reale

Perché non esiste un "login anonimo" in Logto#

Potresti aspettarti che Logto abbia una funzionalità di "login anonimo". Qualcosa tipo: chiamare una API, ottenere un token, nessuna interazione utente richiesta.

Ma non è così che funziona OIDC. Ecco perché:

OIDC si basa sul consenso dell'utente. L'obiettivo principale è verificare "chi è questa persona?". Un token anonimo significherebbe "questo è qualcuno, ma non sappiamo chi" — il che vanifica lo scopo.

Pensala così:

• Autenticazione = provare l'identità ("chi sei?")
• Monitoraggio della sessione = ricordare le azioni ("cosa hai fatto?")

La modalità ospite riguarda il monitoraggio delle sessioni, non l'autenticazione. Quindi non appartiene al tuo sistema di autenticazione.

In realtà è una buona notizia. Significa che hai una separazione chiara:

• Logto gestisce l'identità (registrazione, accesso, token)
• La tua app gestisce le sessioni ospite (prima che esista un'identità)

Lascia che ogni sistema faccia quello per cui è stato progettato.

La soluzione in tre fasi#

Ecco lo schema: Ospite → Auth → Unisci

Fase 1: Gestisci le sessioni ospite senza autenticazione#

Il tuo backend crea e gestisce le sessioni ospite. Logto non è ancora coinvolto.

Quando un utente compie un'azione significativa (ad esempio aggiunge al carrello), il tuo backend:

1. Genera un guest ID (ad esempio, UUID)
2. Lo restituisce come cookie o JWT
3. Salva le azioni dell'utente sotto questo guest ID

Tieni tutto semplice. Una tabella guest_sessions con guest_id, data e created_at è sufficiente.

Fase 2: Permetti agli utenti di accedere con Logto#

Quando l'utente clicca su "Registrati" o "Accedi", avvia il flusso OIDC standard di Logto.

Il guest ID rimane nel cookie/storage durante questo processo. Dopo l'autenticazione avvenuta con successo, il tuo frontend ora ha:

• Un access token da Logto (identità utente)
• Il guest ID da prima (dati ospite)

Fase 3: Unisci in modo sicuro i dati ospite agli utenti autenticati#

Ora collega i punti. Chiama la tua API backend con entrambi:

Il tuo backend deve validare entrambi i token prima di unire:

1. Valida l'access token → estrai l'ID utente. Vedi Convalida access token per scoprire come farlo con Logto.
2. Valida il guest ID → conferma che sia una sessione ospite reale emessa dal tuo backend. Questo è fondamentale — non fidarti mai di un guest ID proveniente dal client senza verifica.

Solo dopo che entrambe le validazioni sono passate:

3. Unisci i dati ospite all'account utente
4. Invalida la sessione ospite

La logica di unione dipende dal tuo business. Carrello? Unisci gli articoli. Bozze di documenti? Trasferisci la proprietà. Decidi tu.

Come mettere in sicurezza il tuo endpoint di unione con la validazione del token#

L'endpoint di unione è un'operazione delicata. Alcune cose da ricordare:

• Valida sempre l'access token. Non leggere solo l'ID utente dal body della richiesta. Decodifica e verifica il JWT. Ecco come farlo con Logto.
• Valida sempre il guest ID. Controlla che esista nel tuo database e che non sia scaduto. Se lo hai emesso come JWT, verifica la firma.
• Richiedi autenticazione. L'endpoint di unione deve rifiutare richieste senza un access token valido.
• Imposta un TTL per le sessioni ospite. Pulisci le sessioni abbandonate dopo 30 giorni (o il periodo più adatto alla tua app).

Conclusione#

La modalità ospite con Logto segue uno schema semplice:

1. Ospite (la tua app) → gestisci le sessioni prima della registrazione
2. Auth (Logto) → gestisci registrazione e accesso
3. Unisci (la tua app) → collega i dati ospite agli utenti reali

Questo schema funziona con qualsiasi provider OIDC, non solo Logto. Il punto chiave è: autenticazione e monitoraggio delle sessioni sono problematiche separate. Lascia che ogni sistema faccia ciò per cui è stato progettato.