Signing in with Google or Facebook: what you're actually handing over
You’ve seen the buttons a hundred times. You land on some new app or service, and instead of a signup form, there’s “Continue with Google” and “Continue with Facebook” sitting above a smaller, greyed-out “use email instead” link. One click, no password to invent, no email to confirm. It feels like the app is doing you a favor. Mechanically, something more specific is happening, and it’s worth knowing what before you click.
What the button is actually doing
These buttons run on a protocol called OAuth 2.0, usually layered with OpenID Connect (OIDC) for identity. When you click “Continue with Google,” the app doesn’t ask you for a password at all. It redirects your browser to Google, Google checks that you’re already logged in (or asks you to log in), and then Google asks you a specific question: “This app wants your name, email address, and profile picture. Allow?”
If you say yes, Google generates a token and hands it back to the app. That token proves to the app “this person is who Google says they are” without the app ever seeing your Google password. The app never touches your credentials. That part is genuinely a security improvement over typing your password into every random website that asks for one.
But the token also carries whatever data the app requested in its “scopes.” Scopes are the specific permissions an app asks for: email address, basic profile info, sometimes calendar access, sometimes contacts, sometimes (on Facebook) your friends list or public posts, depending on what the app declared it wants and what you approved. The consent screen you glance past and click through is the actual contract.
The data that moves, and the data that doesn’t
For a typical login-only integration, what crosses over is narrow: your name, your email address, your profile photo, and a unique identifier tied to your Google or Facebook account. The app doesn’t get your password, and by default it doesn’t get your browsing history, your search history, or your other Google account activity. Facebook and Google both restrict scopes pretty aggressively compared to a decade ago, and both require apps to declare and justify broader permissions.
Where it gets more interesting is on the other side of the connection, not the app’s side but Google’s or Facebook’s side. Every time you use “Sign in with Google” on a new service, Google’s systems record that your Google identity is now linked to that app. Facebook does the same. This is the part that doesn’t show up on the consent screen, because it’s not something the app is asking for. It’s a side effect of how the login flow works: the identity provider necessarily sees which apps you’re authenticating into, and roughly when, because it’s the one issuing the token.
Why this matters more than password reuse
If your only concern is password security, social login is a genuine upgrade over reusing the same password across ten sites. A breach at some small app you signed up for in 2019 can’t leak a Google or Facebook credential that was never stored there in the first place.
The privacy question is a different one: identity consolidation. Google and Facebook already know a great deal about you from their own products. Using their login button on outside apps extends that visibility into services that have nothing to do with search, email, or social feeds. Over time, that builds into a fuller picture of what apps and services you use, tied to a single persistent identity, sitting with a company whose business model includes advertising built on exactly that kind of profile.
This isn’t a hidden conspiracy. It’s a direct consequence of how the protocol works: the identity provider is structurally in the loop on every login. The tradeoff isn’t “Google is stealing your data,” it’s “you’re routing more of your digital footprint through an account that already aggregates a lot about you, in exchange for not managing another password.”
The account-linking risk that’s easy to miss
There’s a second, more practical issue that has nothing to do with advertising: single point of failure. If you sign up for a service using “Continue with Google” and years later lose access to that Google account (locked out, hacked, changed jobs and it was a work account, whatever the reason), you can lose access to every service you registered that way in one shot. There’s often no fallback password to reset, because one was never created. Recovering access means going through each individual app’s support process, and some smaller apps don’t have a clean recovery path for this scenario at all.
This is worth weighing against the convenience. For a low-stakes app you’ll use for a week, it’s a reasonable tradeoff. For something you’re relying on long term, tying its access to a third-party account you don’t fully control adds a dependency that a standalone email and password (managed properly) doesn’t have.
Google and Facebook aren’t identical here
The mechanics are similar, but the two platforms sit in different positions. Google’s OAuth implementation is widely used across the software industry generally, well beyond consumer apps, and its consent screens have gotten more specific about listing exactly which scopes an app requests. Facebook Login is used more heavily in consumer and social contexts, and historically has been the one more associated with apps requesting broader social-graph data such as friends lists, which is part of why its reputation on this topic is rougher than Google’s, even though both run on the same underlying OAuth pattern. Neither one is inherently the “safe” choice; the actual exposure depends on what scopes a given app requests and what you approve, not just which button you clicked.
Matching this to what you’re actually protecting against
None of this means social login is something to avoid categorically. It means the right call depends on what the app is and what you’re trying to protect.
For something disposable, a forum account, a one-off tool, a service you’ll use twice, the convenience of social login is a fine trade. There’s little sensitive data at stake, and you won’t remember a unique password for it anyway.
For something tied to your finances, health information, work identity, or anything you’d be unhappy to see connected to your Google or Facebook profile, a separate email and password, generated and stored in a password manager, keeps that account’s identity from being visible to Google or Facebook at all. It also means losing access to your Google account doesn’t cascade into losing access to your bank’s companion app or your health portal.
A middle option worth knowing about is Apple’s “Sign in with Apple,” which includes an option to relay a unique, forwarding email address to the app instead of your real one. That limits what the app itself can see, though it doesn’t change the underlying dynamic that Apple, as the identity provider, still sees which apps you’re signing into, the same structural fact that applies to Google and Facebook. Passkeys are a newer, separate mechanism (not tied to social login at all) that let you authenticate with a device credential instead of a password, and they’re worth understanding on their own terms rather than as a drop-in privacy fix, since what they solve is credential theft, not identity-provider visibility.
The reasonable middle ground
Treat the social login button as what it is: a convenience feature with a real security upside (no password stored at the app) and a real visibility cost (the identity provider sees the connection). Reserve it for accounts where that tradeoff makes sense, and default to a separate email and a password manager for anything you’d rather keep out of Google’s or Facebook’s view of your digital life. No single choice here makes you private. It’s a series of small decisions about which company gets to see which parts of what you do.
If you want more explainers like this one that stay grounded in how the tools actually work, head back to the homepage for the rest of what we’ve covered.