Thesis: Password and MFA belong on the app form we control. Hosted authorize is the Google (federated) door. Posting a password to hosted is the wrong shape.
What we shipped first
We collected email on our login page, then for native users advanced to a password step. An earlier path still treated hosted login as the place to finish password sign-in. That mixed two doors: our form and the hosted authorize URL.
The fix kept password (and MFA) on our form via the app-origin sign-in path. Google alone opens hosted authorize. We did not rebuild the hosted page into a password form.
The working shape
After email continue: Google → hosted authorize with the identity provider. Password → stay on our form and submit there only. Never POST the password to the hosted authorize URL.
// Password stays on our form. Hosted login is Google handoff only.
async function continueWithEmail(email, lookup) {
if (lookup.identityProvider === "Google") {
return authorizeHosted({ identityProvider: "Google" }); // hosted UI
}
return showPasswordStep(email); // our form — USER_SRP_AUTH
}
// Do not POST the password to the hosted authorize URL.Checklist
- Walk email continue for a native user — password step must stay on the app origin.
- Walk Google — only that path may open hosted authorize.
- Confirm the password field never posts to the hosted authorize URL.
- Do not treat “hosted can show a password field” as a reason to move native sign-in there.
Try the lab
Observe the hosted password failure, name the wrong door, choose “password on our form / hosted for Google,” then prove. Commands: observe · why · fix · prove.
Full page: Open this lab · All labs
Related: hosted login cannot carry the full legal footer. How we deliver: methodology · readiness.
Engineering commentary only — not audit, legal, or certification advice.