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 /fr/docs/mobile/passkeys.md (or send Accept: text/markdown).
Connexion par passkey
Connexion sans mot de passe via un relais navigateur qui renvoie la session à l'application.
Comment fonctionne le relais
La connexion par passkey démarre dans l'application et se termine dans le navigateur système. L'application ouvre {API URL}/auth?mobile_callback=<lien profond> via WebBrowser.openAuthSessionAsync ; une fois la page Web terminée avec n'importe quelle méthode de connexion, elle appelle GET /api/auth/mobile-handoff, qui redirige vers <scheme>://auth/callback avec le cookie de session et un nonce d'état.
Chaque tentative génère un nouveau nonce qui doit faire l'aller-retour inchangé — un paramètre d'état non concordant est rejeté avec stateMismatch, donc un rappel périmé ou forgé ne peut pas injecter de session. Le cookie renvoyé rejoint le même conteneur SecureStore utilisé par le client Expo de Better Auth (supastack.auth_cookie), puis le magasin de session est notifié et l'application connectée s'affiche.
Une feuille de navigateur fermée se résout en un résultat cancelled silencieux plutôt qu'en erreur ; laissez donc l'écran de connexion inchangé quand cela se produit.
# apps/mobile/.env.local
EXPO_PUBLIC_APP_SCHEME=supastack
# apps/web/.env.local — server side
AUTH_PASSKEY_ENABLED=true
MOBILE_ALLOWED_ORIGINS=Garder la liste d'autorisation identique des deux côtés
Les deux côtés valident la cible du rappel : l'application n'accepte que <scheme>://auth plus ses origines de production configurées, et le serveur vérifie la même liste construite à partir d'EXPO_PUBLIC_APP_SCHEME et de MOBILE_ALLOWED_ORIGINS. Les rappels avec identifiants intégrés, schémas inconnus ou suffixes trompeurs sont rejetés avant que le moindre cookie ne bouge.
En production, MOBILE_ALLOWED_ORIGINS est requise et doit lister des origines HTTPS exactes et non locales — les jokers ne sont pas acceptés. L'application est livrée en binaire compilé tandis que le serveur lit son environnement à chaque requête : un changement de schéma ou d'origine exige donc à la fois une nouvelle build de l'application et un déploiement du serveur. Ne modifier qu'un seul côté fait échouer les relais en bloquant.
Les autres méthodes sans mot de passe
Le même écran de connexion propose des codes à usage unique par e-mail (requestEmailOtp puis verifyEmailOtp) ainsi que la connexion sociale Apple ou Google via signIn.social avec un callbackURL. Les passkeys apparaissent quand AUTH_PASSKEY_ENABLED=true côté serveur ; la configuration des passkeys et de la double authentification d'un compte reste dans l'application Web sous Paramètres → Sécurité.
Vérification et dépannage
Exercez sur la build visée un rappel au démarrage à froid, un retour vers une application en cours d'exécution, une feuille de navigateur annulée et une session expirée. Les échecs typés — passkeyUnavailable, browserFailed, untrustedCallback, missingCookie, malformedCookie, cookieStoreFailed — décrivent chacun une rupture distincte ; stateMismatch signifie que le nonce n'a pas fait l'aller-retour et que la tentative a été correctement refusée.
Si tous les relais sont rejetés, comparez EXPO_PUBLIC_APP_SCHEME de la build livrée avec le schéma du serveur et MOBILE_ALLOWED_ORIGINS — la paire diverge quand un seul côté a été redéployé sans l'autre.