Pairwise Subject Identifiers

LoginRadius supports pairwise subject identifiers for OAuth 2.0 and OpenID Connect (OIDC) clients. With pairwise enabled, each application, or group of applications you control, receives a different sub value for the same user. Separate applications cannot correlate users by comparing identifiers.

The sub (subject) claim identifies the authenticated user in ID Tokens, Access Tokens, and UserInfo responses. By default, LoginRadius issues a public sub, which is the same for every client. Pairwise subjects, defined in OpenID Connect Core 1.0, Section 8, replace that shared value with a client-specific one.

Pairwise subjects are available for:

OAuth 2.0 and OIDC clients configured in the Admin Console or through the Management API
Clients registered through OpenID Connect Dynamic Client Registration (DCR)
Outbound SSO integrations to external applications

Use cases

Pairwise subjects address privacy and compliance requirements that a shared identifier cannot meet. Enable them when any of the following apply:

Privacy between applications: Unrelated or third-party applications on one identity provider, such as a health app and a marketing app, cannot link the same person across services.
Compliance and certification: Pairwise support meets privacy-by-design expectations under regulations such as GDPR, and satisfies OIDC profiles or RFPs that require it.
Controlled grouping: Applications under your control share one identifier when you place them in the same sector.
Third-party self-service: Partners registering through DCR request pairwise subjects without admin involvement.

Public vs. pairwise identifiers

The subject type is set per client. Public remains the default, so existing clients are unaffected unless you change them.

Attribute	Public (default)	Pairwise
`sub` value	Same for every client	Different for each sector
Cross-application correlation	Possible by comparing `sub`	Not possible across sectors
Stable for the same user and client	Yes	Yes
Reversible to the underlying user ID	Not applicable	No, it is a one-way value
Redirect URI requirements	Standard OAuth 2.0 rules only	At least one, with one shared host or a sector identifier document
Best for	First-party apps that share user records	Third-party, partner, or privacy-sensitive apps

Two clients receive the same pairwise sub for a user only when they belong to the same sector. Two clients in different sectors always receive different values.

How pairwise subjects work

LoginRadius derives each pairwise sub from the client's sector identifier, the user, and a secret held only by LoginRadius. The same inputs always produce the same value, so a user's sub stays stable for a given sector across logins and token refreshes.

Sector identifier

The sector identifier is a hostname that decides which clients share a sub. LoginRadius resolves it in the following order:

Sector identifier URI: If the client has one configured, its hostname is the sector identifier. Use a sector identifier URI to group multiple redirect hosts you control into one sector.
Redirect URI host: Otherwise, LoginRadius uses the hostname of the client's redirect URI. All redirect URIs must share one host in this case, so the result is the same for every login.

The diagram below shows how LoginRadius resolves the sector identifier and derives the pairwise sub.

If no sector identifier can be determined, LoginRadius rejects the request rather than issuing a public sub. Pairwise clients never silently fall back to public identifiers.

Subject derivation

The pairwise value is a one-way cryptographic hash of three inputs:

Sector identifier: makes the value different for each sector.
User identifier: makes the value different for each user.
Per-tenant secret: generated randomly by LoginRadius and never exposed to clients, which makes the value impossible to predict or reverse.

Without the secret, a relying party that knows or guesses a user's identifier still cannot compute or reverse the pairwise sub.

Configure pairwise subjects

Set the subject type to pairwise on the client. If the client uses more than one redirect host, also provide a sector identifier URI. LoginRadius validates the configuration on save, so a client cannot be saved in a state that would fail at login.

Client settings

The same two settings are available in the Admin Console, the Management API, and DCR, under different field names.

Setting	Admin Console and Management API	Dynamic Client Registration	Values
Subject type	`SubjectType`	`subject_type`	`public` (default) or `pairwise`
Sector identifier URI	`SectorIdentifierURI`	`sector_identifier_uri`	Optional absolute HTTPS URL

A blank subject type is treated as public. On update, omitting the sector identifier URI keeps the stored value, and sending an empty string clears it.

Requirements for pairwise clients

A pairwise client must meet all of the following conditions before LoginRadius accepts the configuration:

The client has at least one redirect URI.
Without a sector identifier URI, all redirect URIs use the same host.
With a sector identifier URI, the hosted document lists every configured redirect URI.
Pairwise support is enabled for the tenant. If pairwise support is not available on an existing tenant, contact LoginRadius Support.

Host a sector identifier document

A sector identifier document proves that you control every redirect URI in the group, as defined in OpenID Connect Dynamic Client Registration 1.0. Host a JSON array of redirect URIs at the sector identifier URI:

[
  "https://app.example.com/callback",
  "https://portal.example.com/callback",
  "https://mobile.example.com/oauth/redirect"
]

The document must meet the following rules:

Served over HTTPS at an absolute URL with no query string or fragment.
Returned with Content-Type: application/json and a 2xx status, without redirects.
A small JSON array of strings only, served promptly.
Contains every redirect URI configured on the client. Matching is case-insensitive.

LoginRadius fetches the document only when you create or update the client, not during user logins. Keep the host available when you change client settings, and update the document before adding a new redirect URI to the client.

Dynamic Client Registration

Third-party developers request pairwise subjects by including subject_type and, optionally, sector_identifier_uri in the registration request. The same validation applies as for admin-managed clients. Invalid values return the standard invalid_client_metadata error.

Behavior across tokens and flows

For a pairwise client, every response where LoginRadius returns a subject uses the same pairwise value. Your application sees one consistent sub per user.

Where the subject appears	Pairwise client behavior
ID Token	`sub` is the pairwise value
Access Token (JWT)	`sub` is the pairwise value
UserInfo response	`sub` matches the ID Token
Token introspection	`sub` matches the issued tokens
Refresh Token grant	New tokens carry the same `sub`
Back-channel logout token	`sub` matches what the client already received, so the logout maps to a local session
Discovery metadata	`subject_types_supported` lists `public` and `pairwise`

The discovery metadata advertises what the server supports. It does not indicate how a specific client is configured.

note

If the subject cannot be generated at runtime, for example because a sector identifier cannot be resolved, LoginRadius returns a server_error instead of falling back to a public sub. For back-channel logout, a failure affects only that client's notification. Other clients in the session are still notified.

Best practices

Decide on the subject type before users start signing in, because switching an existing client changes the sub its users receive.

Choose early: Changing from public to pairwise, or changing the sector, gives existing users a new sub, so plan a migration if your application stores sub as a user key.
Key users on sub with the issuer: Identify users by the iss and sub pair, not by email or other mutable claims.
Group only what you control: Place applications in one sector only when they belong to the same organization and are allowed to share user identity.
Keep the sector document current: Add new redirect URIs to the document before adding them to the client.
Share identifiers through sectors: Do not use a pairwise sub for cross-application lookups. Place services that need a shared identifier in the same sector instead.
Minimize other identifying claims: Pairwise changes only sub, so limit claims such as email through scopes and claim configuration.