Using "Sign in with Google" or a similar provider instead of building your own password system is one of the better defaults I see in AI-scaffolded apps, and I don't want this post to talk anyone out of it. It removes a real, well-documented category of risk. It just doesn't remove nearly as much as the confidence people place in it afterward suggests.
What social login actually solves
Handing authentication to Google, Apple, or a similar provider means you're no longer storing passwords, no longer responsible for password reset flows, and you're inheriting whatever security investment that provider has put into protecting sign-in itself, things like breach monitoring and two-factor prompts. That's genuinely valuable, and it closes off an entire category of mistakes smaller teams commonly make when rolling their own password system from scratch.
What it has nothing to do with
Once Google confirms who someone is, everything your app does after that is entirely your own responsibility, and none of it is handled by the login provider. Does your app correctly check that the now-verified user is only allowed to see their own data. Does every API route re-verify the session on the server, or does it trust a value the frontend sent. Is there an admin route that only checks 'is someone logged in' rather than 'is this specific logged-in person an admin.' None of these questions have anything to do with whether Google or your own code checked the password, because they're not about identity. They're about what a confirmed identity is subsequently allowed to do.
A concrete way the confusion shows up
I've seen apps where the reasoning went roughly: 'we use Google sign-in, so auth is Google's problem, we don't need to test this.' Meanwhile the actual bug sitting in the app had nothing to do with how someone logged in and everything to do with what happened after: an API route that returned any user's data as long as any valid, currently logged-in session made the request, regardless of whose data was being asked for. Google had done its job perfectly. The gap was entirely downstream of it.
What to actually check regardless of login method
- Test the standard two-account check: log in as two different real accounts, both through the same social login, and try to reach one account's data from the other.
- Confirm every sensitive API route checks the session itself, server-side, rather than trusting a role or ID the frontend included in the request.
- Check that an admin distinction, if you have one, is verified against something in your own database, not assumed from any property of the login provider's response.
Social login is a real, good decision that removes one genuine risk from your plate. It just moves the finish line, it doesn't erase it. Everything past 'who is this person' still has to be built and checked by you, exactly as carefully as if you'd built the login screen yourself.