Pairwise Subjects And Privacy In Multi-Client Ecosystems

The sub claim looks small, but it often becomes the identity contract between an OpenID Provider and a relying party.

That contract is convenient when every application can store the same stable user identifier. It is also a privacy risk when unrelated clients can compare notes and discover that they are dealing with the same person. In a multi-client ecosystem with partner portals, business applications, mobile apps, and tenant-specific relying parties, the subject identifier is not just a claim. It is a correlation boundary.

ProAuth 3.0.0 adds pairwise subject identifiers as part of its broader standards and privacy work. The feature is deliberately opt-in per client application because it changes what the relying party sees as the user identity.

flowchart LR
    User["One ProAuth user<br/>local user GUID kept internally"]
    ProAuth["ProAuth issuer<br/>tenant + issuer + sector + secret"]

    ClientA["Client A<br/>app.example.com"]
    ClientB["Client B<br/>partner.example.net"]
    ClientC["Client C<br/>reports.example.org"]

    SubA["ID token / UserInfo<br/>sub = 4S7m...aQ"]
    SubB["ID token / UserInfo<br/>sub = h9Kc...2v"]
    SubC["ID token / UserInfo<br/>sub = Zp1x...Lt"]

    User --> ProAuth
    ProAuth --> ClientA --> SubA
    ProAuth --> ClientB --> SubB
    ProAuth --> ClientC --> SubC

    classDef principal fill:#0f172a,stroke:#0f172a,color:#ffffff
    classDef issuer fill:#eef6ff,stroke:#2563eb,color:#10233f
    classDef client fill:#ffffff,stroke:#64748b,color:#172033
    classDef subject fill:#f6f8fb,stroke:#94a3b8,color:#172033
    class User principal
    class ProAuth issuer
    class ClientA,ClientB,ClientC client
    class SubA,SubB,SubC subject

What `sub` Means

OpenID Connect defines sub as the subject identifier for the end user. It is locally unique within the issuer, never reassigned, intended for the client, and treated as a case-sensitive string. The practical consequence is simple: many relying parties use iss plus sub as their durable account key.

That is why subject handling needs care. If the sub changes, the relying party may not recognize the returning user. If the same sub appears in too many places, relying parties can correlate the user across those places.

OIDC addresses this with subject identifier types: public and pairwise.

Public Subjects Are Simple, But Correlatable

With a public subject identifier, the same ProAuth user receives the same sub value for clients under the same issuer. In ProAuth, existing clients use public subjects by default and receive the ProAuth user GUID as sub, as described in the pairwise subject documentation.

That behavior is operationally simple. It is easy for relying parties to store. It is easy for support teams to trace. It is also easy to correlate.

Public subjects fit clients that are intentionally part of the same trust and data-sharing model. They are less suitable when independent relying parties should not be able to join their user records just because they receive tokens from the same identity platform.

Pairwise Subjects Move The Boundary

With a pairwise subject identifier, ProAuth emits an opaque sub value that is specific to the user and the client sector. The relying party still gets a stable identifier for its own account linking, but unrelated clients do not receive the same identifier for the same ProAuth user.

In ProAuth v3, the client application setting is subjectType:

`subjectType`	External `sub` behavior
`Public`	Emits the ProAuth user GUID as `sub`. This is the default for existing clients.
`Pairwise`	Emits a deterministic opaque `sub` derived for the tenant, issuer, sector, and ProAuth user.

The important word is deterministic. Pairwise does not mean random on every login. For a stable tenant, issuer, sector, local user, and tenant secret, the relying party receives the same sub each time. That keeps normal sign-in, refresh, UserInfo, and token introspection behavior stable for that client while reducing cross-client correlation.

ProAuth keeps the actual ProAuth user id in internal token, session, audit, and revocation context. The pairwise value is what leaves the issuer boundary as the OIDC subject.

Sector Identifiers Decide Who Shares A Pairwise Subject

The sector is the grouping boundary for pairwise subjects. Two clients in the same sector receive the same pairwise sub for the same user. Clients in different sectors receive different values.

By default, ProAuth uses the lower-cased host of the registered redirect URI as the sector identifier. If a pairwise client does not configure sectorIdentifierUri, all of its registered redirect URIs must use the same host.

Use sectorIdentifierUri when multiple clients should intentionally share the same pairwise sub, or when one client has redirect URIs on multiple hosts. The ProAuth docs require that URI to use HTTPS, avoid userinfo and fragments, pass ProAuth remote URI security validation, return a JSON array of redirect URI strings, and include every registered redirect URI exactly as stored on the client application.

That model follows the OIDC sector identifier concept. The OIDC Dynamic Client Registration specification describes the sector identifier list as a way for sites under common administrative control to receive consistent pairwise subjects even when their domain names differ.

This is a design decision, not a formatting decision. If two relying parties share a sectorIdentifierUri, they are intentionally placed in the same subject-correlation group.

The Hidden Tenant Secret Is Part Of The Identity Contract

ProAuth stores a hidden tenant option named PairwiseSubjectSecret. The value is protected at rest and created lazily the first time a pairwise subject is issued for that tenant.

The pairwise value is derived from the issuer, tenant id, sector identifier, local subject, and that tenant secret. This matters for operations:

Changing the ProAuth user id changes the pairwise subject.
Changing the issuer changes the pairwise subject.
Changing the sector changes the pairwise subject.
Rotating PairwiseSubjectSecret changes pairwise subjects for that tenant.
Restoring a tenant without its original pairwise secret changes all pairwise subjects for that tenant.

The last point belongs in backup and recovery planning. A pairwise subject is privacy-preserving because it is opaque to relying parties, but it is still an identity key. The secret that helps derive it is part of the tenant’s identity continuity.

Switching A Live Client Is Breaking

Changing a live client from Public to Pairwise changes the sub value that the relying party receives. From the relying party’s point of view, the same human may now look like a different account.

That is a breaking relying-party identity contract change.

The failure mode is usually account linking. A relying party that stores local users by iss and sub may fail to find the existing account, create a duplicate account, ask the user to re-register, or lose access to application data that is attached to the old subject. The identity provider did not lose the user. The relying party lost the key it used to recognize the user.

For new clients, choose subjectType before production traffic starts. For existing production clients, treat a move to pairwise as a migration project:

inventory which relying parties key accounts by sub
confirm whether they also store a ProAuth user id, email, external id, or other linking attribute
define how old public subjects map to new pairwise subjects
rehearse the relying-party data migration outside production
coordinate the cutover with support, rollback, and duplicate-account handling

Avoid enabling pairwise casually on a client that already has real users. The privacy gain is real, but so is the account-linking impact.

Rotation And Migration Need A Plan

The same caution applies to sector and secret changes after pairwise is in use.

Changing sectorIdentifierUri can be correct when administrative ownership changes or when clients need to be regrouped. Rotating PairwiseSubjectSecret can be correct if the secret is suspected to be exposed. Moving redirect URIs between hosts can be correct during application modernization. None of these changes is just housekeeping once relying parties have stored pairwise subjects.

Plan them like account migrations. The relying party needs a way to connect the old subject to the new subject. Depending on the application, that may mean a precomputed mapping, an authenticated account-linking flow, an administrative import, or a carefully staged data migration. The right approach depends on who owns the relying party and what evidence it accepts for account continuity.

The safest default is to keep the sector and tenant secret stable for the life of the relying-party account relationship. Rotate or regroup only with a concrete migration path.

A Practical Rule

Use public subjects when clients are part of the same intentional account namespace and cross-client correlation is acceptable.

Use pairwise subjects when clients need stable local account linking but should not receive a shared identifier that lets them correlate the same ProAuth user across unrelated applications.

In ProAuth v3, the mechanics are straightforward: set subjectType to Pairwise, use sectorIdentifierUri only when a shared sector is intentional, and protect the hidden PairwiseSubjectSecret as part of tenant continuity. The architecture decision is more important than the switch.

Start with the ProAuth pairwise subject identifier documentation, then cross-check the client inventory before changing any production relying-party identity contract.