In-app two-factor verification for shared sign-in
Opted-in applications can collect the central AllAuth authenticator or backup code in their own sign-in screen, while native verification and OAuth remain authoritative. Existing integrations keep the hosted challenge.
What changed
- Requires SDK 1.4.6 and the explicit brokerTwoFactor server option with the matching portable SignIn component. Existing customer packages, hosted integrations and direct application-owned providers are not changed automatically.
- The encrypted five-minute handoff is bound to the registered broker, exact app origin and an initiating-browser secret. Native factor consumption, attempt budgets, lockout, rate limiting and OAuth state/PKCE remain enforced; central cookies are never copied into the application.
- JSON-based primary sign-ins continue from the hosted page only after checking the native signed live pending cookie and signed authorization query. Missing, forged, expired, tampered or unsupported context retains the hosted flow.
- A one-use completion receipt restores the platform session only in the original browser, then resumes native OAuth and any required consent. The receipt lasts one minute; the native OAuth request expiry remains authoritative. No database migration is needed.
Release provenance
deployment
The initial in-app broker MFA service reached Railway SUCCESS in deployment 91002ca2-b1ce-46b2-bbde-95e0ca47c6ea at 2026-11-06T21:40:15.280Z from merge 4d6fcf973eaa24b74cf3ebd7fe63b3766cc2e301. Production smoke testing then identified the JSON-primary hosted-page continuation gap; a focused regression reproduced it on the original service. The continuation now requires a signed unexpired native pending cookie and signed broker query. Final corrected deployment and browser acceptance are recorded separately in the release receipt.
Reviewed package files: broker-two-factor.ts, mfa.ts, two-factor/page.tsx, broker-login.test.ts, allauth-in-app-two-factor.mdx