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 /nl/docs/mobile/passkeys.md (or send Accept: text/markdown).
Aanmelden met een passkey
Wachtwoordloos aanmelden via een browseroverdracht die de sessie terugbrengt naar de app.
Hoe de overdracht werkt
Aanmelden met een passkey begint in de app en eindigt in de systeembrowser. De app opent {API URL}/auth?mobile_callback=<deep link> via WebBrowser.openAuthSessionAsync; nadat de webpagina een aanmeldmethode heeft voltooid, roept deze GET /api/auth/mobile-handoff aan, die terugredirect naar <scheme>://auth/callback met de sessiecookie en een state-nonce.
Elke poging genereert een verse nonce die ongewijzigd heen en weer moet reizen — een afwijkende state-parameter wordt afgewezen als stateMismatch, zodat een verouderde of vervalste callback geen sessie kan injecteren. De geretourneerde cookie wordt samengevoegd in dezelfde SecureStore-cookiejar die de Better Auth Expo-client gebruikt (supastack.auth_cookie), waarna de sessiestore wordt ingelicht en de aangemelde app rendert.
Een weggedrukt browserblad resulteert in een stil cancelled-resultaat in plaats van een fout, dus laat het aanmeldscherm ongewijzigd als dat gebeurt.
# apps/mobile/.env.local
EXPO_PUBLIC_APP_SCHEME=supastack
# apps/web/.env.local — server side
AUTH_PASSKEY_ENABLED=true
MOBILE_ALLOWED_ORIGINS=Houd de toelatingslijst aan beide kanten identiek
Beide kanten valideren het callbackdoel: de app accepteert alleen <scheme>://auth plus de geconfigureerde productie-origins, en de server controleert dezelfde lijst die is opgebouwd uit EXPO_PUBLIC_APP_SCHEME en MOBILE_ALLOWED_ORIGINS. Callbacks met inloggegevens, onbekende schema's of lookalike-achtervoegsels worden afgewezen voordat er ook maar een cookie beweegt.
In productie is MOBILE_ALLOWED_ORIGINS vereist en moet deze exacte, niet-lokale HTTPS-origins bevatten — wildcards worden niet geaccepteerd. De app wordt gebundeld meegeleverd terwijl de server zijn omgeving per request leest, dus een schema- of originwijziging vereist zowel een nieuwe app-build als een serverdeploy; wie slechts één kant wijzigt, laat overdrachten gesloten falen.
De andere wachtwoordloze methoden
Hetzelfde aanmeldscherm biedt eenmalige e-mailcodes (requestEmailOtp gevolgd door verifyEmailOtp) en sociale aanmelding via Apple of Google via signIn.social met een callbackURL. Passkeys verschijnen wanneer AUTH_PASSKEY_ENABLED=true op de server staat; de passkey- en tweefactorinstellingen van een account blijven in de webapp onder Instellingen → Beveiliging.
Verificatie en probleemoplossing
Oefen op de beoogde build een callback bij koude start, een terugkeer naar een draaiende app, een geannuleerd browserblad en een verlopen sessie. De getypeerde fouten — passkeyUnavailable, browserFailed, untrustedCallback, missingCookie, malformedCookie, cookieStoreFailed — beschrijven elk een eigen breuk; stateMismatch betekent dat de nonce niet ongewijzigd heen en weer reisde en de poging terecht is geweigerd.
Als elke overdracht wordt afgewezen, vergelijk dan EXPO_PUBLIC_APP_SCHEME in de uitgebrachte build met het schema van de server en MOBILE_ALLOWED_ORIGINS — het paar loopt uiteen wanneer de ene kant opnieuw is gedeployd zonder de andere.