For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /it/docs/mobile/passkeys.md (or send Accept: text/markdown).
Accesso con passkey
Accesso senza password tramite un passaggio nel browser che riporta la sessione all'app.
Come funziona il passaggio
L'accesso con passkey inizia nell'app e finisce nel browser di sistema. L'app apre {API URL}/auth?mobile_callback=<deep link> tramite WebBrowser.openAuthSessionAsync; dopo che la pagina web ha completato un qualsiasi metodo di accesso chiama GET /api/auth/mobile-handoff, che reindirizza a <scheme>://auth/callback portando il cookie di sessione e un nonce di stato.
Ogni tentativo genera un nonce nuovo che deve tornare invariato — un parametro di stato non corrispondente viene rifiutato come stateMismatch, così un callback scaduto o falsificato non può iniettare una sessione. Il cookie restituito si fonde nello stesso jar SecureStore che usa il client Better Auth Expo (supastack.auth_cookie), poi lo store di sessione viene notificato e l'app autenticata renderizza.
Un pannello del browser chiuso produce un risultato cancelled silenzioso anziché un errore, quindi lascia invariata la schermata di accesso quando succede.
# apps/mobile/.env.local
EXPO_PUBLIC_APP_SCHEME=supastack
# apps/web/.env.local — server side
AUTH_PASSKEY_ENABLED=true
MOBILE_ALLOWED_ORIGINS=Mantieni l'allow-list identica su entrambi i lati
Entrambi i lati validano la destinazione del callback: l'app accetta solo <scheme>://auth più le sue origini di produzione configurate, e il server controlla la stessa lista costruita da EXPO_PUBLIC_APP_SCHEME e MOBILE_ALLOWED_ORIGINS. I callback che portano credenziali, schemi sconosciuti o suffissi simili vengono rifiutati prima che qualsiasi cookie si sposti.
In produzione MOBILE_ALLOWED_ORIGINS è obbligatoria e deve elencare origini HTTPS esatte e non locali — i caratteri jolly non sono accettati. L'app viene distribuita in bundle mentre il server legge il proprio ambiente a ogni richiesta, quindi un cambio di schema o origine richiede sia una nuova build dell'app sia un deploy del server; cambiare un solo lato fa fallire chiusi i passaggi.
Gli altri metodi senza password
La stessa schermata di accesso offre codici monouso via email (requestEmailOtp poi verifyEmailOtp) e l'accesso social Apple o Google tramite signIn.social con una callbackURL. Le passkey compaiono quando AUTH_PASSKEY_ENABLED=true sul server; la configurazione di passkey e autenticazione a due fattori per un account resta nell'app web in Impostazioni → Sicurezza.
Verifica e risoluzione dei problemi
Esercita un callback ad avvio a freddo, il ritorno a un'app in esecuzione, un pannello del browser annullato e una sessione scaduta sulla build di destinazione. I fallimenti tipizzati — passkeyUnavailable, browserFailed, untrustedCallback, missingCookie, malformedCookie, cookieStoreFailed — descrivono ciascuno un guasto diverso; stateMismatch significa che il nonce non ha fatto il giro completo e il tentativo è stato correttamente rifiutato.
Se ogni passaggio viene rifiutato, confronta EXPO_PUBLIC_APP_SCHEME nella build distribuita con lo schema del server e MOBILE_ALLOWED_ORIGINS — la coppia deriva quando un lato è stato ridistribuito senza l'altro.