> ## Documentation Index > Fetch the complete documentation index at: https://supastack.dev/llms.txt > Use this file to discover all available pages before exploring further. > For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt # 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= tramite WebBrowser.openAuthSessionAsync; dopo che la pagina web ha completato un qualsiasi metodo di accesso chiama GET /api/auth/mobile-handoff, che reindirizza a ://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 ://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. ## Successivo [API mobile](https://supastack.dev/it/docs/mobile/api.md)