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 /es/docs/mobile/passkeys.md (or send Accept: text/markdown).
Inicio de sesión con passkey
Inicio de sesión sin contraseña mediante una transferencia al navegador que devuelve la sesión a la app.
Cómo funciona la transferencia
El inicio de sesión con passkey comienza en la app y termina en el navegador del sistema. La app abre {API URL}/auth?mobile_callback=<deep link> mediante WebBrowser.openAuthSessionAsync; cuando la página web completa cualquier método de inicio de sesión, llama a GET /api/auth/mobile-handoff, que redirige de vuelta a <scheme>://auth/callback llevando la cookie de sesión y un nonce de estado.
Cada intento genera un nonce nuevo que debe regresar sin cambios: un parámetro de estado que no coincide se rechaza como stateMismatch, así que un callback obsoleto o falsificado no puede inyectar una sesión. La cookie devuelta se fusiona en el mismo contenedor de SecureStore que usa el cliente Better Auth Expo (supastack.auth_cookie); después se notifica al almacén de sesión y se renderiza la app con la sesión iniciada.
Una hoja de navegador descartada se resuelve como un resultado cancelled silencioso en lugar de un error, así que mantén la pantalla de inicio de sesión sin cambios cuando ocurra.
# apps/mobile/.env.local
EXPO_PUBLIC_APP_SCHEME=supastack
# apps/web/.env.local — server side
AUTH_PASSKEY_ENABLED=true
MOBILE_ALLOWED_ORIGINS=Mantén idéntica la lista de permitidos en ambos lados
Ambos lados validan el destino del callback: la app solo acepta <scheme>://auth más sus orígenes de producción configurados, y el servidor comprueba la misma lista construida a partir de EXPO_PUBLIC_APP_SCHEME y MOBILE_ALLOWED_ORIGINS. Los callbacks que llevan credenciales, esquemas desconocidos o sufijos imitados se rechazan antes de que se mueva ninguna cookie.
En producción, MOBILE_ALLOWED_ORIGINS es obligatoria y debe enumerar orígenes HTTPS exactos y no locales: no se aceptan comodines. La app se distribuye empaquetada mientras el servidor lee su entorno en cada petición, así que un cambio de esquema u origen necesita a la vez una compilación nueva de la app y un despliegue del servidor; cambiar un solo lado hace que las transferencias fallen cerradas.
Los otros métodos sin contraseña
La misma pantalla de inicio de sesión ofrece códigos de un solo uso por correo electrónico (requestEmailOtp y después verifyEmailOtp) e inicio de sesión social con Apple o Google mediante signIn.social con una callbackURL. Las passkeys aparecen cuando AUTH_PASSKEY_ENABLED=true en el servidor; la configuración de passkey y de doble factor de una cuenta sigue viviendo en la app web, en Configuración → Seguridad.
Verificación y solución de problemas
Ejercita en la compilación prevista un callback en arranque en frío, un retorno a una app en ejecución, una hoja de navegador cancelada y una sesión caducada. Los fallos tipados —passkeyUnavailable, browserFailed, untrustedCallback, missingCookie, malformedCookie, cookieStoreFailed— describen cada uno una ruptura distinta; stateMismatch significa que el nonce no completó el viaje de ida y vuelta y el intento fue rechazado correctamente.
Si todas las transferencias se rechazan, compara EXPO_PUBLIC_APP_SCHEME de la compilación distribuida con el esquema del servidor y MOBILE_ALLOWED_ORIGINS: la pareja se desincroniza cuando un lado se volvió a desplegar sin el otro.