Social login runs on OAuth 2.0 and OpenID Connect, open protocols that let a website or app (the "relying party") delegate the question "who is this person?" to an identity provider such as Google, Apple, or Facebook. Instead of storing a password for you, the site receives a signed token from the provider saying you authenticated there. The protocol design is solid. The privacy questions come from who the provider is and what sits in the middle of your logins from then on.
What the Identity Provider Learns
Every time you use the button, the provider is a participant in the login, so it necessarily observes it. Over months of normal use, that adds up to a record the provider would have no other way to collect:
- The full list of services you use. Every relying party you have ever connected appears in your account's third-party access page. That list is a map: which dating app, which mental-health service, which forum, which job-search site.
- When and how often you use them. Fresh sign-ins and token refreshes tell the provider which of those services you touched this week.
- Correlation across all of it. The same stable identifier ties those services together, and ties them to everything else the provider already knows about you: your search history if it is Google, your social graph if it is Meta.
None of this requires anything underhanded. It falls directly out of the architecture: an authentication broker sees authentications. Whether that observation feeds an advertising profile depends on the provider's policies, which are long documents that change.
What the App Learns, and the Graph API Lesson
The data flowing the other direction is governed by scopes: the app requests your email address, name, and profile photo, and you approve the grant on the consent screen. Today's defaults are reasonably narrow. They were not always. Until Facebook tightened its Graph API in 2014 and 2015, an app you authorized could request data about your friends, who had never installed it. That design decision is how a personality-quiz app harvested the profiles that ended up at Cambridge Analytica, an affair that cost Facebook a five-billion-dollar FTC settlement in 2019.
The durable lesson is about consent screens generally: read the scopes, and treat any request beyond basic identity, contacts, calendars, message access, as a separate decision from "do I want to log in." A grant made once persists until you revoke it, and app permissions pages (Google's "Third-party apps & services," Apple's "Sign in with Apple" list, Facebook's "Apps and Websites") are worth an occasional audit. Delegated access tokens are also a phishing target in their own right; our post on OAuth phishing covers how consent screens get weaponized.
The Coupling Problem: One Account to Lose Them All
The less discussed cost is availability. If your Google account is suspended, whether through a policy enforcement action, a false positive in automated abuse detection, or a successful account takeover, every account behind that button is affected at once. You do not have a password for those services; your ability to enter them was the provider's signature, and the provider has stopped signing.
This is not hypothetical. Automated suspensions with slow or unsuccessful appeals are a steady genre of news story and court filing, and account-recovery locks after a takeover routinely take days. During that window, your logins at unrelated services are collateral. The same coupling makes the provider account a high-value target for attackers: compromising it yields not one account but the whole list, which is exactly the dynamic described in our post on account takeover attacks.
Open your provider's third-party access page and look at the list. Most people find services they forgot existed, with grants from years ago. Revoke what you no longer use, and check whether the services that matter to you offer a way to set a native password or a second login method, so a provider outage or suspension does not lock you out.
Sign In With Apple: The Partial Fix
Apple entered this market in 2019 with a privacy-differentiated version. Sign in with Apple offers relay email addresses: the app receives a generated address like x9k2f@privaterelay.appleid.com that forwards to your real inbox, so the app never learns your actual email and cannot easily join its records with other databases keyed on it. Apple also required, as an App Store rule, that apps offering other companies' login buttons offer Apple's too.
The relay addresses are genuinely useful, and disposable addressing is a tactic worth using everywhere, not only with Apple; see our email aliases guide. But the structural position is unchanged: Apple is now the broker who observes the logins and holds the availability coupling. You have selected a provider whose business model leans less on advertising, which is a real difference in incentives rather than a difference in architecture.
Comparing Your Options
| Method | Who sees your logins | If one account falls | Phishing resistance |
|---|---|---|---|
| Social login | The identity provider, every time | Provider account loss cascades to every linked service | Inherits the provider account's protections, and its consent screens are a phishing surface |
| Email + password manager | No third party in the login path | Contained, if passwords are unique per site | Good: the manager refuses to autofill on lookalike domains |
| Passkeys | Depends on where they sync; the sync provider does not participate in each login | Contained per site | Strongest: the credential is bound to the real domain by design |
For most accounts, a password manager generating unique credentials, or passkeys where the site supports them, gives you the convenience that made the social button attractive without placing a broker in the login path. The remaining defensible use case for social login is low-value accounts you would rather not exist at all: a one-time checkout, a commenting account. Even there, an alias address and a generated password cost only seconds more.
The Question Behind the Button
Authentication is a position of structural power: whoever holds it observes your behavior and controls your access. The social login button asks you to hand that position, for each new account, to one of a handful of companies whose core business is knowing things about you. Declining the button does not require new tools or any cryptography. It requires noticing that "faster" and "free" are how the position gets acquired.