I build useHUMA, a behavioral verification API that tells real humans apart from bots and AI agents. This week I added "Sign in with Google" to cut signup friction and then did a security audit on my own flows.
What I found: my password signup ran our behavioral check on every new account. My shiny new Google path didn't. It verified identity (Google confirms the email is real) but skipped humanity (is there an actual person here, or an agent driving a browser?).
An AI agent can complete a Google OAuth flow with a real account. So my "frictionless" new door was also my least defended one.
The fix took an afternoon: capture behavioral signals on the login/signup pages, carry them through the OAuth round-trip, score new accounts server side before creating them. Fail open, so a false positive never locks out a real user. Existing users never get re-checked.
Takeaways for fellow builders:
Every new "convenience" path you add (OAuth, magic links) is a new door. Audit them against the SAME threat model as your main flow.
Identity providers verify accounts, not presence. Those are different problems.
Dogfooding is the cheapest security audit you'll ever run.
Happy to answer questions about the audit process (I keep the detection specifics private, it's an arms race).
The real issue here isn’t OAuth vs password—it’s that identity and “human presence” are being treated as the same trust layer.
Once you separate those two, every authentication shortcut becomes a new surface area you have to explicitly re-evaluate against a different threat model, not just a UX improvement.