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 /de/docs/mobile/passkeys.md (or send Accept: text/markdown).
Passkey-Anmeldung
Passwortlose Anmeldung über eine Browser-Übergabe, die die Sitzung an die App zurückgibt.
So funktioniert die Übergabe
Die Passkey-Anmeldung beginnt in der App und endet im Systembrowser. Die App öffnet {API URL}/auth?mobile_callback=<deep link> über WebBrowser.openAuthSessionAsync; nachdem die Webseite eine beliebige Anmeldemethode abgeschlossen hat, ruft sie GET /api/auth/mobile-handoff auf, das zu <scheme>://auth/callback zurückleitet und dabei das Sitzungs-Cookie und eine State-Nonce mitführt.
Jeder Versuch erzeugt eine frische Nonce, die unverändert zurückkehren muss — ein abweichender state-Parameter wird als stateMismatch abgelehnt, sodass ein veralteter oder gefälschter Callback keine Sitzung einschleusen kann. Das zurückgegebene Cookie landet in demselben SecureStore-Cookie-Jar, den der Better-Auth-Expo-Client nutzt (supastack.auth_cookie); danach wird der Sitzungsspeicher benachrichtigt und die angemeldete App gerendert.
Ein weggewischtes Browser-Sheet wird als stilles cancelled-Ergebnis aufgelöst, nicht als Fehler — lassen Sie den Anmeldebildschirm in dem Fall unverändert.
# apps/mobile/.env.local
EXPO_PUBLIC_APP_SCHEME=supastack
# apps/web/.env.local — server side
AUTH_PASSKEY_ENABLED=true
MOBILE_ALLOWED_ORIGINS=Halten Sie die Allowlist auf beiden Seiten identisch
Beide Seiten prüfen das Callback-Ziel: Die App akzeptiert nur <scheme>://auth plus ihre konfigurierten Produktions-Origins, und der Server prüft dieselbe Liste, die aus EXPO_PUBLIC_APP_SCHEME und MOBILE_ALLOWED_ORIGINS gebaut wird. Callbacks mit Zugangsdaten, unbekannten Schemas oder ähnlich aussehenden Suffixen werden abgelehnt, bevor irgendein Cookie wandert.
In der Produktion ist MOBILE_ALLOWED_ORIGINS Pflicht und muss exakte, nicht lokale HTTPS-Origins auflisten — Platzhalter werden nicht akzeptiert. Die App wird gebündelt ausgeliefert, während der Server seine Umgebung pro Anfrage liest; eine Schema- oder Origin-Änderung braucht daher sowohl einen neuen App-Build als auch ein Server-Deployment. Eine Änderung nur auf einer Seite lässt Übergaben geschlossen fehlschlagen.
Die anderen passwortlosen Methoden
Derselbe Anmeldebildschirm bietet Einmalcodes per E-Mail (requestEmailOtp, dann verifyEmailOtp) sowie Social Sign-in über Apple oder Google per signIn.social mit einer callbackURL. Passkeys erscheinen, wenn AUTH_PASSKEY_ENABLED=true auf dem Server gesetzt ist; die Passkey- und Zwei-Faktor-Einrichtung eines Kontos bleibt in der Web-App unter Einstellungen → Sicherheit.
Überprüfung und Fehlerbehebung
Testen Sie auf dem vorgesehenen Build einen Callback nach Kaltstart, die Rückkehr zu einer laufenden App, ein abgebrochenes Browser-Sheet und eine abgelaufene Sitzung. Die typisierten Fehler — passkeyUnavailable, browserFailed, untrustedCallback, missingCookie, malformedCookie, cookieStoreFailed — beschreiben jeweils einen eigenen Bruch; stateMismatch bedeutet, dass die Nonce nicht zurückgekehrt ist und der Versuch korrekt abgewiesen wurde.
Wenn jede Übergabe abgelehnt wird, vergleichen Sie EXPO_PUBLIC_APP_SCHEME im ausgelieferten Build mit dem Schema des Servers und MOBILE_ALLOWED_ORIGINS — das Paar driftet auseinander, wenn eine Seite ohne die andere neu bereitgestellt wurde.