Cross-Domain Identity

When a business operates multiple domains (e.g. example.com and example-shop.com), each domain has its own isolated cookie space. A visitor on example.com has one _dfid, and the same visitor on example-shop.com gets a completely different _dfid. Signal’s Identity Hub service bridges this gap, linking these separate identities together in a server-side identity graph so they resolve to the same person.

The Problem

Browser security prevents cookies from being shared across different domains. A cookie set on example.com is never sent to example-shop.com, even if both sites belong to the same business. This is a fundamental browser security property — not a bug.

Without cross-domain identity resolution, a visitor who browses products on example.com and then purchases on example-shop.com appears as two separate anonymous users. Attribution is broken, funnel analysis is incomplete, and vendor APIs receive disconnected events.

The Solution: Identity Hub

The Identity Hub is a standalone service that acts as a shared identity bridge between domains. It runs on a shared subdomain (e.g. id.company.com) and links visitor identities across domains in a server-side identity graph. Each domain keeps its own _dfid — the linkage happens entirely on the server.

With cross-domain identity:

  example.com         → _dfid = "aaa-111"
  user clicks link to example-shop.com
  → link routes through Identity Hub
  → Identity Hub returns its hub identity to the destination
  → example-shop.com  → _dfid = "bbb-222" (keeps its own identity)
  → server links hub identity to both "aaa-111" and "bbb-222"

  Different local IDs, same person — resolved server-side

Flow Modes

Signal supports two cross-domain identity resolution flows. The mode is selected per-organisation in the identity settings:

Why OIDC Is Recommended

The OIDC flow performs the identity exchange entirely server-to-server, with no client-side token handling. The visitor’s existing _dfid on each domain is unaffected.

How It Works (OIDC Flow)

The OIDC flow follows the same pattern as OAuth 2.0 Authorization Code with PKCE:

1. User clicks a cross-domain link — Datafly.js generates a PKCE challenge and redirects the browser to the Identity Hub
2. Identity Hub issues an authorization code — reads the visitor’s identity and returns an opaque, single-use code via redirect to the destination domain
3. Server-to-server exchange — the destination’s Ingestion Gateway exchanges the code with the Identity Hub via a backchannel request, verifying the PKCE challenge
4. Identity linked server-side — the Ingestion Gateway links the hub identity to the visitor’s canonical identity graph. If this hub identity was previously seen from another domain, the canonical identities are merged automatically. The visitor keeps their existing _dfid on the destination domain.

The authorization code is single-use and expires after a short time window. The PKCE exchange ensures that even if an attacker intercepts the code from the URL, they cannot use it without the verifier.

Configuration

Cross-domain identity is configured per organisation in the Management UI or via the Management API.

To enable cross-domain identity:

1. Navigate to Organisation Settings > Identity > Cross-Domain
2. Enable cross-domain identity resolution
3. Select the flow mode (OIDC recommended)
4. Set the Identity Hub URL (e.g. https://id.company.com)
5. Add all domains that should share identity (e.g. example.com, example-shop.com, example-blog.com)

The Identity Hub must be deployed on a domain that is accessible from all participating domains. A common pattern is to use a shared corporate subdomain (e.g. id.company.com) or a dedicated identity domain.

Automatic Link Decoration

Datafly.js can automatically decorate outbound links to configured cross-domain destinations. When enabled, any <a> tag pointing to a domain in the cross-domain group is rewritten to route through the Identity Hub.

Link decoration is enabled in the Datafly.js configuration:

<script
  src="https://data.example.com/datafly.js"
  data-pipeline-key="dk_live_abc123..."
  data-cross-domain="true"
></script>

When data-cross-domain is set to true, Datafly.js:

1. Fetches the list of cross-domain domains from the source configuration
2. Observes the DOM for matching outbound links (including dynamically added links)
3. Rewrites href attributes to route through the Identity Hub
4. Preserves the original destination path and query parameters

Programmatic Decoration

For JavaScript-driven navigation (e.g. single-page app route changes, window.location assignments), you can use the Datafly.js API to generate a decorated URL:

const decoratedUrl = datafly.crossDomainUrl('https://example-shop.com/checkout')
window.location.href = decoratedUrl

DNS Configuration

The Identity Hub needs a DNS record pointing to the service:

id.company.com → A record or CNAME to Identity Hub load balancer

In Kubernetes deployments, this is typically an Ingress resource with TLS termination.

Edge Cases

Visitor Has No Identity on the Hub Domain

If a visitor reaches the Identity Hub without an existing identity (first interaction with the hub):

1. The hub generates a new hub identity and sets it as a cookie on the hub domain
2. Redirects to the destination with the new hub identity
3. On the destination, the Ingestion Gateway links the hub identity to the visitor’s canonical identity

On subsequent cross-domain navigations, the hub’s cookie is present and the hub identity is linked to both domains’ canonical identities, unifying the visitor across sites.

Destination Already Has an Identity

This is the most common case. The visitor already has a _dfid on the destination domain from a previous visit. With server-side linking, there is no conflict to resolve:

1. The visitor keeps their existing _dfid on the destination — it is never overwritten
2. The Ingestion Gateway links the hub identity to the visitor’s canonical identity on the destination
3. If the hub identity was already linked from the source domain, the two canonical identities are merged automatically

Both local identities coexist. The merge happens in the server-side identity graph, so no “which identity wins” decision is needed.

JavaScript-Disabled Browsers

Cross-domain identity works without JavaScript because the mechanism is based entirely on HTTP redirects and cookies. The only requirement is that the browser follows redirects and accepts cookies.

However, automatic link decoration requires JavaScript (Datafly.js). For JavaScript-disabled visitors, links must be pre-decorated in the server-rendered HTML.

Safari 17+ Bounce Tracking Protection

Safari 17+ tracks domains that are only visited as part of redirect chains and classifies them as bounce trackers. If the Identity Hub domain is never visited directly by the user, Safari may delete its cookies.

Mitigation strategies:

• Link Decoration — Transfers identity directly in the link without a redirect through a third domain. Immune to bounce tracking protection.
• Storage Access API — The hub page can request storage access permission from the user, but this requires a user interaction gesture and is not seamless.
• Server-side identity graph — When users authenticate on both sites via identify(), the server can stitch the identities without any client-side mechanism.

For most multi-TLD deployments, the recommended approach is to use Link Decoration for user-initiated navigations and the Identity Hub (OIDC flow) as a fallback for direct arrivals.

Choosing a Cross-Domain Strategy

Signal provides three complementary mechanisms — customers can enable any combination: