The Hidden Risks of “Sign In with Google”
Why password managers offer better security than single sign-on authentication
We've all clicked "Sign In with Google" for the convenience. One click, no password to remember, instant access. But that convenience comes with a hidden architectural flaw that most people don't discover until it's too late.There's a better way that's just as convenient, without the risk.
We’ve all seen it. You’re creating a new account on a website, and instead of filling out yet another registration form, there’s that tempting blue button: “Sign In with Google.” One click, and you’re in. No password to remember, no confirmation email to wait for, just instant access.
It seems like the perfect solution to our password fatigue problem. And in many ways, it is convenient. Sites like Medium, Spotify, Figma, and thousands of others have embraced this pattern, allowing users to authenticate using their Google, Apple, Microsoft, or GitHub credentials rather than creating site-specific accounts.
How It Actually Works
When you click “Sign In with Google,” you’re using what’s called OAuth 2.0 or OpenID Connect. Essentially, the website you’re trying to access redirects you to Google’s authentication service. You prove who you are to Google (usually because you’re already logged in), and Google sends a secure token back to the original site confirming your identity. The site trusts Google’s verification and lets you in.
From a user experience perspective, it’s brilliant. You don’t need to remember another password. You get one-click access to multiple services. And theoretically, you benefit from Google’s security infrastructure, including their two-factor authentication, anomaly detection, and security response teams.
The Problem Everyone Ignores
Here’s where things get messy. And I mean really messy.
Which provider did you use? Six months ago, you created an account on a service. Was it with your Google account? Your Apple ID? Or did you actually create a password? Good luck remembering. You can waste a significant amount of time clicking through different “Sign In with…” buttons trying to figure out which one you used originally.
Inconsistent implementation creates confusion. Some sites treat each sign-in method as completely separate accounts. If you sign in with Google one day and Apple the next, you might end up with two different accounts on the same service, each with different data and settings, and even credit card payments if it’s a subscription service. Other sites are smarter and link them by email address, but you can’t always tell which approach a site uses until you’ve already created the duplicate account.
Your Google account is now a single point of failure. And I don’t mean that in the theoretical, architectural sense. I mean it in the very real, “this happened to me and now I’m locked out of everything” sense.
Google’s automated systems occasionally flag accounts for suspicious activity and lock them. Sometimes they’re right. Sometimes they’re not. Either way, if your Google account gets locked, not only are you locked out of Google, but you are locked out of the potentially dozens of services you’ve authenticated with Google. So, not only have you lost access to google, but you’ve lost access to every other service and system that you use. And good luck trying to recover your accounts when you’ve also lost access to your email (since Gmail is also tied to your Google account).
I’ve talked to developers who lost access to their production deployment tools because their Google account was flagged during a vacation. The irony of being locked out of your security-focused password manager because of a security measure is not lost on anyone who’s experienced it.
Compromise multiplies. The reverse issue is even more problematic. What happens if someone does gain improper access to your Google account? This can happen through a phishing attack, a data breach, or social engineering. Anyone who has gained access to your Google account now not only has access to Google and your email, but they also have access to every single account you’ve linked to that identity. It’s the digital equivalent of using the same physical key for your house, your car, your office, and your safe deposit box. Once you lose it, everything you own is vulnerable to attack.
The Better Alternative
There’s a solution that gives you all the convenience of single sign-on without the existential risk: a password manager.
Modern password managers like 1Password, Bitwarden, or even the ones built into Safari and Chrome, offer something better than convenience. They offer independent security.
Here’s how it works in practice:
Every account gets its own unique, randomly generated password. Not a password you could ever remember or type, but something like `vK9$mL2#pQr8@nX5wZ3^hF7!jD4&tY6`. The password manager generates it, stores it, and automatically fills it in when you need it.
The experience is just as seamless. Modern password managers integrate directly into your browser and mobile devices. When you visit a login page, they auto-fill your credentials. One click, just like “Sign In with Google,” but without the architectural dependency on a third party website.
Your accounts remain independent. If one service has a breach, the compromised password is useless anywhere else. If you need to revoke access to one account, you can do it without affecting anything else. And with no central account like Google involved, having your Google account locked or hacked doesn’t compromise access to any other account or system.
Even Better: Passkeys
If you really want to step up your security game, use passkeys embedded in your password manager.
Passkeys use cryptographic keys instead of passwords. They’re resistant to phishing because they’re tied to specific domains. This means that a fake site can’t trick your passkey into authenticating inappropriately, eliminating many social engineering attacks. They’re resistant to breaches because the private key never leaves your device. And they’re still managed by your password manager, so you get the same seamless experience.
Sites like GitHub, Google, and PayPal already support passkeys. Other sites are adding support regularly. As of today, for me, probably around half of the accounts I use regularly support passkeys. And the number is growing quickly.
The Architecture Perspective
From a software architecture standpoint, “Sign In with Google” creates a dependency that violates one of our core principles: minimize coupling to external systems, especially when those systems are outside your control.
Every dependency introduces risk. When that dependency is managed by someone else’s security policies, incident response times, and business decisions, you’ve ceded control over a critical part of your user experience.
Password managers invert this relationship. Instead of your access depending on Google’s availability and policies, it depends on your own secure credential store. You control the recovery process. You control the authentication flow. You decide when and how to rotate credentials.
It’s the difference between building on rented land and owning your foundation.
What Should You Do?
If you’re currently using “Sign In with Google” for multiple accounts, you don’t need to panic and change everything immediately. But consider this your nudge to start moving in a better direction:
- Set up a password manager if you haven’t already. The ones built into your browser are fine to start with. Dedicated tools like 1Password or Bitwire offer even more features. I personally use 1Password, and have for many, many years.
- For new accounts, create unique passwords instead of using third-party sign-in. Let your password manager generate and store them.
- Gradually convert existing accounts. Next time you log into a service using Google, check if you can add a password to your account and unlink the Google authentication.
- Enable passkeys wherever they’re available. They’re the future of authentication, and they’re available now.
The goal isn’t perfection. The goal is to reduce your dependencies and increase your resilience. That’s good architecture, whether we’re talking about distributed systems or personal security.
Your accounts are too important to trust to a single point of failure. Even if that point of failure is as reliable as Google, it’s still a single point of failure.
Image created by ChatGPT
