Social Login as Cross-Device Identity Infrastructure

The Strongest Identity Signal on Your Site Is a Button

The industry has spent a decade building elaborate machinery to guess whether the phone in someone's hand belongs to the same person as the laptop on their desk: canvas fingerprints, probabilistic device graphs, IP-plus-user-agent heuristics. All of it is inference, and all of it degrades — browsers randomize fingerprint surfaces, households share IP addresses, and advertising IDs get reset.

Meanwhile, the strongest cross-device signal most sites will ever see is sitting in their login form. When a visitor clicks "Sign in with Google" on a laptop on Monday and taps the same button on a phone on Friday, both sessions present the same OAuth subject — an account identifier the provider keeps stable for your application. That is not a guess about a device. It is an authenticated assertion about a person.

A fingerprint guesses that someone is back. A login proves it. That is the entire difference between probabilistic and deterministic identity.

This post explains how ClickStream turns social login into identity infrastructure: what an OAuth subject is, why it outranks every device-derived signal in the identity graph, and how per-tenant HMAC hashing makes these keys useful for social login cross-device tracking inside one customer's account while remaining cryptographically unlinkable across customers.

What an OAuth Subject Is — and Why It Survives Device Changes

Every major social login provider issues a stable user identifier when someone authenticates with your app:

• Google — the sub claim in the ID token
• Apple — the Sign in with Apple user identifier
• Facebook — the Facebook user ID
• LinkedIn — the LinkedIn member ID

These identifiers name an account, not a device. They survive everything that breaks device-scoped identity: clearing cookies, switching browsers, buying a new phone, moving between home and office networks. Even Apple's "Hide My Email" relay doesn't matter here — the relay obscures the email address, not the subject identifier your app receives.

Compare that with the workhorse of web identity, the first-party cookie. ClickStream's server-set cookie persists up to the ~400-day browser maximum, which is excellent — on the one device and browser where it was set. The cookie anchors each device's timeline; the OAuth subject is the bridge between those timelines. You need both, and they do different jobs.

Deterministic vs. Probabilistic: Where a Login Ranks

ClickStream's identity graph scores every identity signal by how much confidence it contributes to resolving a person. The weights are explicit in the resolution engine, and the ordering is the honest part:

A social login subject carries roughly three times the weight of a device fingerprint, and it earns three properties in the graph that no probabilistic signal gets:

1. It never decays. The graph edges a shared login creates are deterministic with no expiry. Fingerprint and geo edges age out; a login link doesn't, because accounts don't drift the way devices do.
2. It anchors the deterministic confidence band. ClickStream classifies every resolved person into confidence bands based on their strongest first-party anchor. An authenticated login puts a person in the deterministic band — the band gets a confidence floor of 0.72, and each additional independent deterministic anchor (an email hash, a CRM ID) adds corroboration on top. A person known only by fingerprint or MAID can never rise above the probabilistic band, no matter how many weak signals accumulate.
3. It can corroborate weaker signals. A shared mobile advertising ID alone is never enough to merge two profiles — MAIDs are resettable and shared on family tablets. The graph demands independent evidence before folding profiles together, and a shared authenticated login is exactly the kind of independent deterministic key that clears that bar.

One more property matters for trust: social login keys can only be created by an actual authentication on your own site. A partner data sync cannot assert one. Purchased or synced identity data enters the graph on a different, lower tier — a login key is always first-party evidence.

Per-Tenant HMAC: Two Customers Cannot Cross-Link the Same Person

Here is the obvious objection: if a Google sub is globally stable, doesn't collecting it build exactly the kind of cross-site tracking identifier the industry is trying to retire? It would — if it were stored raw or hashed with a plain, unkeyed hash. ClickStream does neither.

The raw OAuth subject never leaves the collector. At ingestion, the collector shape-validates the raw value, prefixes it with its provider, and computes an HMAC-SHA-256 digest using a secret key that belongs to that one tenant:

// Inside the collector — the only place the raw subject ever exists
hmacGoogleId = HMAC_SHA256(tenantKey, "google:" + googleSub)
// → 64-char hex digest, deterministic per tenant, meaningless outside it

Two consequences fall out of this construction:

• Provider domain separation. The google: / facebook: / apple: / linkedin: prefix is hashed along with the subject, so a numeric Facebook ID can never collide with a numeric LinkedIn ID that happens to share the same digits. Each provider's keyspace is cryptographically walled off from the others.
• Cross-tenant unlinkability. The same person logging into two different ClickStream customers' sites with the same Google account produces two unrelated digests, because each tenant's HMAC key is different. Neither customer — nor anyone who obtained both databases — can join them. There is no rainbow table to build, because without the tenant key there is nothing to precompute against.

This is a deliberately different design from how the ad-tech ecosystem treats hashed emails, where the same unkeyed SHA-256 digest of an email is portable across every vendor that holds it — portability is the point of that system, and the privacy cost of it. ClickStream keeps a raw SHA-256 email hash only for the third-party enrichment lookups a customer explicitly uses; every internal graph join runs on the tenant-keyed HMAC instead. Social login subjects go one step further: downstream of the collector, no unkeyed form of the subject exists at all.

The practical meaning: social login cross-device tracking in ClickStream is a within-your-tenant capability by construction, not by policy. It is enforced by key material, not by a promise in a DPA.

How Cross-Device Stitching Actually Happens

Walk through the lifecycle of one person across two devices:

1. Monday, laptop. A visitor signs in with Google. The site passes the OAuth subject to the ClickStream tracker; the collector HMACs it with the tenant key and forwards the digest. The visitor's identity-graph node — already anchored by the laptop's first-party cookie — gains a soc_google signal.
2. Friday, phone. The same person signs in with the same Google account on their phone. Same tenant, same subject, same key — so the collector computes the identical digest.
3. Resolution. The graph looks the digest up in its signal index, finds the laptop node already holding it, and folds the phone's anonymous sessions into the same person. Every pre-login pageview from the phone's cookie is retroactively attributed to that person, the same way cross-device identity resolution works for email-based identification.

The lookup itself can be stored without tenant scoping precisely because the per-tenant HMAC already provides the isolation — a digest from another tenant can never match, so the index cannot leak across accounts even by bug. The architecture of that resolution loop — nodes, signal edges, merge gates, and review states — is covered in depth in Inside the Identity Graph.

Wiring It Up

The pixel does not intercept your OAuth flow and never sees provider tokens. You pass the subject explicitly, after your own authentication completes. Once the ClickStream snippet is installed, the tracker is available as window.cs, and one call per provider does the job:

// After your OAuth flow verifies the user, hand the provider's
// stable user ID to the tracker. Provider is one of:
// 'google' | 'facebook' | 'linkedin' | 'apple'

window.cs.setSocialId('google', idTokenClaims.sub);    // Google: `sub` claim
window.cs.setSocialId('apple', appleAuth.user);        // Apple Sign-In user ID
window.cs.setSocialId('facebook', fbResponse.userID);  // Facebook user ID
window.cs.setSocialId('linkedin', linkedinProfile.id); // LinkedIn member ID

From there the SDK attaches the ID to the identity block of subsequent events, and the collector performs the HMAC step described above. The SDK persists the value locally only when the visitor has granted marketing consent, so consent-revoked sessions don't quietly carry the key forward — and even in debug mode it logs only a truncated prefix of the ID.

If your login also yields an email address, send that too — identify() and setSocialId() are complementary, and a person holding both anchors resolves with higher confidence than either alone. That combination is also what powers the compliant handoff from anonymous history to a named record, covered in From Anonymous Visitor to CRM Contact.

What Social Login Keys Don't Do

The limits matter as much as the mechanics:

• They only exist when people log in. A social key is created by an authentication event on your property. Coverage is a function of your login adoption, which is why we won't quote you a universal match-rate percentage — it's your funnel's number, not ours.
• They cannot build a cross-customer profile. The per-tenant HMAC makes the same person's key on two customers' sites cryptographically unrelated. ClickStream could not assemble a cross-tenant identity from these keys even if it wanted to.
• They don't replace device signals — they organize them. Cookies still anchor each device's timeline; behavioral scoring still runs per session. The login key is the spine that connects timelines into a person. For the visitors who never authenticate at all, weaker shared-context evidence is a separate, explicitly probabilistic story — see Households and Workplaces, Without a Form Fill.

The Bottom Line

Social login is usually discussed as a conversion optimization — fewer form fields, fewer abandoned signups. It deserves to be discussed as identity infrastructure. One OAuth subject, HMAC-hashed per tenant, gives you:

• A deterministic cross-device key that survives cookie clearing and device changes
• A confidence anchor that places a person in the deterministic band with a floored resolution score
• Corroborating evidence that lets weaker signals like MAIDs merge safely
• Cryptographic tenant isolation — cross-device inside your account, unlinkable outside it

Fingerprints try to recognize a device that never asked to be recognized. A login is a person telling you who they are. Build your identity graph on the second thing.