skip to content

In OpenID Connect, how can three clients run by one organisation receive the same pairwise sub for one user?

level: seniorimportance: nice to knowfreq 30%

answer

  1. grouping, not one per client
  2. common administrative control
  3. one shared name across several clients
  4. only the host part counts
  5. sector_identifier_uri, registered per client

basics

~20 s

Register all three clients with the same sector_identifier_uri. A pairwise value is derived per sector rather than per client, and the Sector Identifier is that URI's host component, so the three resolve to one sector and one shared sub.

solid answer

~50 s

A pairwise `sub` is derived per **sector**, not strictly per client. Where several clients sit under common administrative control, a provider **SHOULD** use `sector_identifier_uri` to group them — note the SHOULD, it is a recommendation rather than a requirement. Each of the three clients registers the same URI, and the **Sector Identifier used in the calculation is that URI's host component**, so all three land in one sector and one end user yields one `sub` across them. A fourth party's client, in a different sector, still receives an unrelated value, which is the point: correlation inside the estate, none across it. Where a client registers no `sector_identifier_uri`, the provider falls back to the host of that client's registered redirect URI — which is why clients published on three different hosts otherwise end up with three different subject values.

code

json · 4 lines
json
{
  "subject_type": "pairwise",
  "sector_identifier_uri": "https://identity.example-theatre.org/sector.json"
}

go deeper

for a junior

Know that a pairwise subject value is produced by the provider, and that two applications from the same organisation will not automatically be handed the same one.

for a middle

Explain that the grouping is registered rather than inferred: clients that should share a value name the same sector_identifier_uri, and the host component of that URI is what enters the calculation.

for a senior

Show that you fix the sector before the clients ship, and that you can say what a client joining or leaving one does to the identifiers those clients already hold.

for a principal

Decide how wide a sector should be. Too wide and you have recreated shared public identifiers inside the estate; too narrow and every internal product carries its own re-identification work.

## The problem the sector solves Pairwise subject identifiers are defined to stop clients correlating one end user, and they do that well. The awkward case is the organisation that runs several clients itself and genuinely needs them to recognise the same person: a volunteer scheduler, a public ticketing site and a donor portal, all pointed at one provider. Under a plain pairwise policy those three are strangers to each other. Switching the whole provider to `public` to fix it would also hand every unrelated third-party client the same shared identifier, which is a much larger concession than the problem requires. The **sector** is the middle setting. A pairwise value is derived from a sector identifier rather than from the client directly, so any clients that resolve to the same sector receive the same `sub` for a given user. ## How a client is placed in a sector | Registration | Sector identifier used | Effect | |---|---|---| | `sector_identifier_uri` registered | the **host component** of that URI | every client naming that URI shares one sector, and one `sub` per user | | no `sector_identifier_uri` registered | the host of the client's registered redirect URI | clients on different hosts land in different sectors; two clients sharing a host would share one | The first row is what the specification recommends for clients under common administrative control: providers using pairwise values for such a set of clients **SHOULD** use `sector_identifier_uri`. It is a SHOULD, and stating it as a MUST teaches a false certainty — but it is the mechanism the specification offers, and there is no other supported way to declare the grouping. Two details are worth holding precisely: - It is the **host component** that enters the calculation, not the whole URI string. Two clients may name URIs that differ in path and still be in the same sector, provided the host matches. - The URI names a document the provider retrieves. That retrieval is how the provider establishes that the set of clients claiming the sector really is the set entitled to it, rather than taking one client's word for it. ## Working it through 1. The provider's policy is pairwise, so by default each client would receive its own subject values. 2. The three in-house clients each register the same `sector_identifier_uri`, hosted on the organisation's own name. 3. The provider derives the Sector Identifier from that URI's host and uses it as an input for all three. 4. A user who volunteers, buys a ticket and donates presents one `sub` to all three, and they resolve to one account with no linking work. 5. An unrelated partner's client registers no such URI — or one on its own host — falls into a different sector, and receives a subject value that matches nothing the three in-house clients hold. ## What grouping costs The sector is not a free knob, and the cost is the same one that makes the whole subject policy a design decision rather than a configuration detail: - **Moving a client into a sector changes the values it is issued.** The sector is an input to the derivation, so from that moment on the provider hands that client a different set of subject values. Everything the client has already stored stops matching, and returning users look like new ones. - **Moving a client out has the same effect in the other direction.** Leaving a sector is not a rollback; it produces a third set of values unrelated to either of the first two. - **A wide sector is public subjects with extra steps.** Group enough clients and you have restored full correlation inside that group, which may be exactly what you want — but say so deliberately rather than discovering it. - **The grouping is administrative, not technical.** The specification frames it around common administrative control. Putting a partner's client into your sector because it is convenient hands that partner your estate's identifier for every shared user. - **It is per-sector, not per-user.** A sector groups clients. It does not group, segment or otherwise touch end users. ## The interview version The answer an interviewer is listening for has three beats: pairwise values are derived per sector; clients are placed in a sector by registering a common `sector_identifier_uri`, whose **host** is what counts; and the grouping must be decided before those clients store anything, because changing it invalidates every identifier they hold. A candidate who reaches only the first beat has read the specification; one who reaches the third has operated it.

  • What happens to a client's stored sub values when it is moved into a sector?
    They stop matching. The sector identifier is an input to the derivation, so every value that client receives afterwards is different. Returning users look like accounts it has never seen, until the client re-identifies them by some attribute of its own.
  • If a client registers no sector_identifier_uri, what does the provider use instead?
    The host component of that client's registered redirect URI. Clients published under different host names therefore fall into different sectors and receive unrelated values, while two clients that happen to share a host would fall into the same sector.
  • Why does the provider retrieve the document the sector_identifier_uri points at?
    Because the grouping cannot rest on one client's assertion. Retrieving the document from that host is how the provider establishes which clients are genuinely entitled to the sector, rather than letting any registration claim membership of someone else's.

saying these in an interview costs you the question

  • sector_identifier_uri is mandatory whenever pairwise subjects are issued
  • The whole URI string, path included, is the sector identifier
  • Clients in one sector still get different values the application must map together
  • Moving a client into a sector is harmless, the provider just recomputes its values
  • A sector groups end users rather than clients