my friend recently lost a three-year saas.
he got an email from google: "your account has been suspended for violation of our policies."
no detail. no reference number. no human attached. eight years of gmail, gone. youtube, gone. drive, gone. play store purchases, gone. the small saas he'd been running for three years, gone, because every single piece of his stack was glued to that one account.
he can't log into notion. three years of product specs, customer notes, contract drafts, vendor agreements, financial forecasts. all of it lived behind "sign in with google."
he can't log into figma. design system, brand assets, every mockup he'd ever made. same story.
linear. roadmap, every bug, every customer ticket. same.
vercel. his production deployment was tied to a github account whose recovery email was the dead gmail. he can still see the site is up. he just can't touch it.
stripe. he can see no payments, can't refund, can't even read his own MRR. the dashboard auth path went through google.
he still doesn't know what he did wrong. google never told him.
main lesson here is you should not sign in with google, here are the main reasons why.
1/ you don't own your login. you rent it from google.
when you click "sign in with google", you are not creating an account on the app. you are telling the app "google will vouch for me." which means: as long as google vouches for you, you have an account. the day google stops vouching, you don't.
there is no contract. there is no SLA. there is no court you can appeal to. there is a form, and the form is read by a model, and the model says no.
the famous case is andrew spinks, the developer of terraria. 15 years on gmail. account disabled in january 2021 without explanation. lost youtube, drive, every play store purchase he'd made. he got it back, but only after publicly cancelling the stadia port of his game and the story going viral. the normal appeal process did nothing for him. it's not designed to.
2/ one account, one bullet.
people sell sso as "more secure than passwords." it's false.
sign in with google vs. a password manager + a unique alias per site + a hardware 2fa key: sso loses on every axis except convenience. distributed risk for concentrated risk. statistically, the expected loss is the same. emotionally and operationally, it isn't even close. losing 1/20 of your stack hurts. losing 20/20 ends your business.
every security person knows this.
3/ the failed-startup oauth flaw, and google said "won't fix"
in january 2025, truffle security disclosed a flaw in how google's oauth handles domain ownership changes.
when a startup dies, its domain goes on the open market. somebody buys it for $12. they spin up google workspace on that domain. they recreate the old employee emails, alice@deadstartup..., bob@deadstartup...
now they go to slack. notion. zoom. chatgpt. they click "sign in with google" as alice. and they're in. into the old company's data. because slack and notion only check the email and the google domain claim, neither of which changed.
google's first response was to close the report as "won't fix" and classify it as "fraud and abuse" rather than an oauth bug. they only reopened it after the researchers' shmoocon talk got accepted and the story got viral. final bounty: $1,337. a meme amount for an industry-scale flaw.
if "sign in with google" had a vulnerability that lets a $12 domain purchase unlock your old HR system, what other architectural choices is the same team making?
4/ password reset doesn't save you anymore
most people, when they hear "google account compromise," think: change the password, reset the sessions, done.
it doesn't work anymore.
late 2023, researchers found an undocumented google oauth endpoint called multilogin that, given a refresh token, regenerates fresh session cookies. by 2024, over ten malware families had built it in, lumma, rhadamanthys, the usual suspects. they steal the token from chrome, regenerate cookies, and keep your session alive.
even after you reset your password.
the only real fix is to manually revoke every active session and every third-party oauth grant from your google security page. which nobody does, because nobody knows that's what they need to do.
5/ consent phishing eats your 2fa
the second piece of the security myth is "i have 2fa, i'm fine."
consent phishing sidesteps 2fa entirely.
the attacker doesn't try to authenticate as you. they put up a real google consent screen, the actual google domain, valid cert, your real account already logged in, and ask you to grant their malicious app a permission like "read your email" or "manage your drive." you tap allow. You've now given a stranger a token with the exact permission they asked for, signed by Google, valid for months.
your password didn't help. your 2fa didn't help. you were never asked to authenticate. you were asked to authorize. completely different mechanism.
token theft accounted for 31% of microsoft 365 breaches in 2025. in march of the same year, attackers pivoted device-code phishing to google. in august, the salesloft/drift breach harvested oauth tokens for salesforce and google workspace integrations at scale.
6/ the button tracks you whether you click it or not
the "sign in with google" button is not an image. it's a google-hosted script. every page that has the button is loading code from google's servers, which means google sees the page load, the referrer, the user agent, and, if you're logged into google in another tab, exactly who you are.
you don't have to click it. you just have to load a page that has it.
apple solved a different problem with "sign in with apple", the hide my email relay, where each app gets a unique forwarding alias. google has no equivalent. your real, primary email goes to every app, forever, and that email is the master key to every password reset you'll ever do.
7/ the convenience is real.
sso is more convenient. one click, no signup form, no new password to remember. for low-stakes services, a podcast app, a news site, a random tool, that convenience is worth it.
the issue is that people don't sort. they use the same google login for the podcast app and the company stripe and the freelance accountant's portal and the bank-adjacent fintech and the cloud provider. and they do this because the click is the same in every case.
the right rule isn't "never use sso." it's: if losing access to this service for 30 days would damage your work or your money, do not use sso. create a real account. use a password manager. use an alias email from fastmail, proton, or apple's relay. set up 2fa with a hardware key.
for everything else, sso is fine. just stop treating it as the default.
what to do
- audit. open myaccount[.]google[.]com/connections. look at every app you've granted access to. revoke everything you don't recognize or haven't used in six months.
- separate. anything that touches your money or your work, stripe, your domain registrar, your cloud provider, your accounting software, your slack, should not authenticate through google. period. real account, real password, real 2fa.
- alias. stop giving your real email to every app. proton, fastmail, simplelogin, and apple's relay all generate per-app aliases. if one leaks, you burn that alias and move on.
- break the recovery chain. your password manager, your cloud accounts, your domain registrar, none of their recovery emails should point to your gmail. if your gmail dies tomorrow, you should still be able to recover everything that matters.
- assume the worst case. sit down for ten minutes and ask: if my google account vanished tonight, what would i lose?