SSO & Social Login / 02 / Declined on principle

We don't ship
social login. That is a decision, not a gap.

"Sign in with Google" and "Sign in with Apple" feel free.
They are not. The price is paid in your customers' data — and you do not set that price. Saving money on security should not mean selling your customers' data.

0Third parties in the auth path
100%Your user list stays yours
∞Future term changes you skip
01 · How social SSO actually works

Every social login routes your user through a company that is not yours.

When a user taps "Sign in with Google," your app hands the authentication moment to Google. Google verifies the user, decides whether to allow it, and hands back a token. That round-trip is the product.

In exchange for not building login yourself, you give the identity provider a permanent, real-time signal: which of your users are active, when they log in, how often, and from where. The provider sees the heartbeat of your product. You see a token.

This is not a misuse of social login. It is how social login is designed to work. The data exposure is the mechanism, not a side effect.

02 · What the provider sees

The token you receive is small. The data they collect is not.

A plain comparison of what crosses the wire on a social login — what comes back to you, versus what the identity provider records on their side.

What your app receives
What the provider records
An ID token A signed assertion that the user is who they claim to be.
A login event, tied to your app That this specific user authenticated into your product, timestamped.
Basic profile fields Name, email, avatar — the scopes you requested.
Frequency and recency How often the user returns to your app, and when they last did.
A session your code manages You hold the session — until the user signs in again.
A cross-app graph Your app becomes one more node in the provider's map of that person's digital life.
The asymmetry

You receive an answer to one question — "is this user real?" The provider receives an ongoing feed about your business. The trade is not equal, and it does not expire.

The principle
Saving money on security should not mean selling your customers' data to the largest advertising companies on earth.
03 · Two ways to authenticate

Outsource the login, or own it. The difference is who keeps the data.

Social SSO

Sign in with Google / Apple / Facebook

  • The identity provider sees every login into your app.
  • Your user list becomes visible to a third party in real time.
  • Your users' activity feeds a profile you do not control.
  • If the provider changes terms, deprecates the API, or locks the account, your login breaks.
  • "Free" — paid in data, not invoices.
TwinShield

Hardware-bound auth on your own server

  • No third party sits in the authentication path.
  • Your user list never leaves your infrastructure.
  • Login activity is yours — no external profile is built.
  • No vendor can change terms on a login flow you fully own.
  • Priced in plain currency. No data changes hands.
04 · Why we left it out

We could have shipped social login in a day. We chose not to.

Adding "Sign in with Google" is a few hours of work. Every auth platform includes it because it is easy to build and easy to sell. TwinShield deliberately does not.

The entire premise of TwinShield is that your users, your credentials, and your keys stay inside your environment. Hardware-bound keys at the root, an auth server you host, a policy you control. Shipping social login would put a third party back in the middle of the exact path we built TwinShield to clear.

It would be inconsistent to hand you control with one hand and route your users through an advertising company with the other. So the feature is not missing. It was declined — on principle.

Keep your users yours.

If owning your authentication — keys, users, and login data — matters to your product, that is the conversation we want to have.

Talk to us →