> ## 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

# 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.


## Weiter

[Mobile API](https://supastack.dev/de/docs/mobile/api.md)