Sign in with Google, Facebook, or X: what you actually trade for the convenience

The signup screen has four buttons. The first three are colored logos - Google, Facebook, Apple, sometimes X, sometimes Microsoft - and the fourth is a small gray link that says "or sign up with email". The colored buttons are one click; the gray link is a form, an email verification, a password to pick, a captcha. The maths of friction means most people press a logo without thinking about it, and most of the time that is fine. Sometimes it is not.

This article is a working person's version of the trade. What does each big button actually send to the new site? What does the upstream provider learn about your habits in exchange? What happens to the account if the provider closes, suspends, or charges for the relationship? And when is the boring email-and-password path quietly the better privacy choice?

How "Sign in with X" works, in one paragraph

All the colored buttons run a variant of OAuth 2.0 with an OpenID Connect identity layer on top. When you click the button, the third-party site (call it the "relying party") sends your browser to the provider's consent screen with a list of scopes it wants - your email, your profile, sometimes more. You approve. The provider sends the browser back to the relying party with a short-lived token. The relying party trades the token for your basic profile (a stable user ID, your email, your display name, sometimes an avatar URL), and creates - or matches - an account with that ID. Future logins skip the consent step, because the provider remembers the grant and the relying party remembers the ID.

Two facts follow that are worth keeping in your head while reading the rest. First, the relying party does not get your password - that is the whole point - and it does not get a live pipe into the provider's data unless you separately grant scopes like Drive or Calendar. Second, the provider gets a permanent, time-stamped record of every relying party you ever clicked their button for. That second fact is the privacy trade, and it is roughly the same shape regardless of which logo you press.

Google: the default, and the most mapped

Google's button is the one most people see most often, partly because Android, Chrome, and Gmail prime users for it, and partly because the relying-party side is genuinely well-engineered. The basic sign-in scope (openid email profile) gives the new site your Google account ID, your verified email address, your display name, and a profile picture URL. That is it. Nothing about Gmail, nothing about Calendar, nothing about Drive. Sites that want any of those have to request named scopes that show up as their own line items on the consent screen ("This app wants to view files in your Drive"), which Google highlights and which a normal user will notice.

The privacy cost is on the other side: Google now has a precise, long-term log of every service you signed into with the button. You can see your own copy of that log at myaccount.google.com/permissions, which is also where you revoke an app's grant after deleting an account on the other end. The log is used internally for security signals (impossible-travel detection, suspicious-grant alerts), and it is the kind of record that becomes a target for legal requests. If your threat model includes someone subpoenaing Google to learn which services you use, the button is not the right choice for those services.

Operationally, Google is the most reliable provider in this list. Account suspensions happen but are rare for normal personal use, the recovery flow has improved a lot since the unrecoverable-account horror stories of the late 2010s, and OAuth tokens stay valid for a long time. If you are going to consolidate on one social login, Google is the pragmatic pick - paired with a password fallback on every site you care about.

Facebook: the broadest scopes, the most history

Facebook's login was designed in an era when the company actively wanted apps to read your friend graph and post to your wall. A lot has changed since the Cambridge Analytica fallout in 2018 and the Graph API v3 reset - the default scopes are narrower now, friend lists are no longer returned wholesale, and Meta runs a stricter app review for anything beyond the basics. The shape of the trade, though, is still distinct from Google's.

A typical Facebook login screen will request public_profile,email, and depending on the app, user_birthday,user_friends (now limited to friends who have also installed the same app), and occasionally user_photos or the Pages-management scopes. Each of those is a separate line on the consent screen and is reviewable. The catch is that Facebook accounts carry the longest commercial-tracking history of any provider in this list - Meta has been correlating off-Facebook activity into the social-graph profile for over a decade, and signing into a third-party site with the Facebook button feeds that correlation directly.

There is also the practical question of account stability. Facebook account lockouts have been a steady source of complaint for years - identity verification loops that ask for a government ID, recovery flows that dead-end, lost-access stories that play out on Reddit every week. If you sign up for a dozen services with the Facebook button and then get locked out of Facebook for a name-policy dispute or a hacked-account flag, those services become recovery problems all at once. For that reason alone, the Facebook button is the weakest of the major ones in 2026 for any account you would miss.

Apple: the only one with built-in privacy hedging

Apple's "Sign in with Apple" is the youngest of the major buttons (launched 2019) and the one with the cleanest privacy story, because Apple designed it after seeing the others operate for a decade and had a commercial reason to differentiate. Two features are unique to it.

First, the Hide My Email option. When the consent screen appears, you can choose to share your real Apple ID email or to let Apple generate a unique relay address per app - a7q9k2x4@privaterelay.appleid.com or similar. Mail sent to the relay forward to your real inbox, and you can disable the relay later from the Apple ID settings if the app starts spamming you. The relying party never sees your real address. None of Google, Facebook, X, or Microsoft offer an equivalent for their sign-in flows.

Second, Apple has publicly committed - and structured the product around the commitment - that it will not build a cross-site advertising profile from sign-in events. Combined with the relay-email option, that materially shrinks the data the provider accumulates about you. The catch is the same catch every social provider has: you are still concentrating identity with one company, and an Apple ID lockout is at least as painful as a Google one.

Apple's button has one real limitation: it is most useful on Apple devices. It works on the web and on Android, but the UX is smoothest on iOS and macOS where the consent flow is a Touch ID or Face ID prompt. If you live in the Apple ecosystem and the relying party offers the button, it is the strongest single choice in this list.

X (formerly Twitter): the one to phase out

The X login button is technically still OAuth, but the operational story has changed enough since the Twitter days to be worth a separate paragraph. The platform restricted free API access in 2023, re-priced developer tiers, and reshaped the terms multiple times, which means third-party integrations with the X login have broken unpredictably and a number of sites have removed the button. Suspensions have become more common and the appeal process less predictable, which raises the risk of losing the upstream account and the downstream accounts tied to it.

If you already have services tied to a Twitter/X account, treat it as a sunset relationship: log into each one, set a password or a recovery email, and consider migrating the primary login away from X to email or to another social provider. For new signups, there is almost no scenario in 2026 where the X button is the right pick.

Microsoft, GitHub, and the rest

Microsoft's button (called "Sign in with Microsoft" or sometimes "Microsoft Entra ID" in corporate contexts) is functionally similar to Google's - basic scopes return your account ID, email, and profile, and anything else is a named scope. The audience splits in two: personal Microsoft accounts (Outlook.com, Xbox, OneDrive) and work or school accounts on Microsoft 365. The privacy trade looks like Google's; the lock-in risk is lower for personal accounts because Microsoft has less history of consumer account suspensions, and higher for work accounts because your employer's IT admin can terminate the upstream account when you leave the job.

GitHub's button is everywhere in developer tools and is generally well-behaved - scopes are explicit, the granular OAuth-apps permission model and the newer fine-grained personal access tokens let you see exactly what each integration can read or write, and the revocation UI is one of the better ones on the internet. The risk profile is the same as any social login: lose the GitHub account and you lose the downstream services.

Discord, LinkedIn, GitLab, Twitch, and the others all run the same OAuth pattern with their own scope conventions. None of them have the relay-email feature; all of them have the same lock-in risk; the privacy trade is shaped by how much commercial-tracking history the upstream company has on you, which for LinkedIn and Discord is substantial.

The case for the boring email-and-password path

Pressing the gray link instead of a logo takes ninety seconds longer the first time and zero seconds longer every time after. It also moves the identity dependency from a tech company you do not control to an email account you do (or to a password manager you do). Three scenarios where that is the right call:

• Anything you would be sorry to lose. Bank, tax-filing portal, primary cloud storage, password manager, domain registrar, anything with payment history attached. Tie these to email plus a strong password, with a passkey or hardware key as the second factor. Read the passkeys and MFA piece for the full stack.
• Anything you would rather Google or Meta not know you use. A second-opinion medical service, a legal-aid intake, a support forum for something personal, a dating app, a political-organizing tool. The provider's log of "which apps did this user authenticate to" is exactly the wrong kind of metadata to hand over for these.
• Anything that might outlive your current social relationships. An archive of writing, a domain you own, a long-lived community account. Email-and-password ages better than any social provider relationship; the email account itself can move between providers if you control the domain.

For everything else - a single-use signup to download a PDF, a forum you will visit twice, a trial of a SaaS you are evaluating - the button is fine and the time saving is real. The judgement is about which bucket the account belongs in.

A short checklist before you press another logo

1. Decide on one primary social provider. Apple if you are on Apple devices and the site supports it; Google otherwise. Avoid spreading logins across three providers - it multiplies your lock-in surface without adding any defense.
2. Use Hide My Email when Apple offers it. Almost free, removes the relying party's ability to spam your real address, and gives you a kill switch.
3. Set a password the first time you sign in. Most large sites let you add one from account settings even when you signed up with a social button. This is the single most useful thing you can do to insure against losing the upstream account. A password generator that runs in your browser is enough.
4. Audit your grants once a year. Google: myaccount.google.com/permissions. Apple: Settings → Apple Account → Sign in with Apple. Facebook: Settings → Apps and Websites. Revoke the ones you do not recognize; the relying party will fall back to email at next login if you also set a password.
5. For accounts that really matter, skip the buttons. Email and password and a second factor. The hour you save with single sign-on is not worth the day you lose if the provider relationship goes sideways.

Where this fits in the wider privacy picture

Social login is one slice of a bigger story about how identity gets tracked on the modern web. The other big slice is what the browser leaks before you have typed anything at all - the IP, the User-Agent, the fonts, the canvas signature - covered in the five things your browser sends piece. Together they explain why "I never told that site my name" and "that site somehow knows it is me" are both routinely true.

Privvert's tools all run locally in the browser - no upload, no account, no button to press. The reasoning is on the privacy page, and the rest of the practical guides are on the blog.