Public, Pairwise, and Ephemeral Subject Identifiers in OpenID Connect

What the sub claim is

OpenID Connect Core defines two subject identifier types: public and pairwise. A newer OpenID Foundation specification, OpenID Connect Ephemeral Subject Identifier 1.0, adds a third: ephemeral. The three types answer one question differently. Who should be able to tell that two logins belong to the same person?

The answer drives your data model. A sub that repeats lets you build an account. A sub that never repeats does not. If you are new to ID Tokens and discovery, start with OpenID Connect explained and come back.

Public subject identifiers

A public sub is the same value for a given user at every RP that talks to the OP. It is the OIDC Core default and the type most providers issue unless an RP asks for something else. It is simple, and it makes the user trivially correlatable across every application that receives it.

Public identifiers are reasonable inside one organization. Your web app, mobile app, and support console all see the same sub, so joining records across them is easy. The cost appears once tokens leave your control. Two unrelated RPs that receive the same public sub can join their datasets on it with no further effort. Under GDPR, that value is personal data, and a shared one is a ready-made correlation key. See GDPR and CIAM for the regulatory side.

Pairwise subject identifiers

A pairwise sub is different for each RP sector but stable over time within that sector. The same user gets one value at a retailer and a different value at a bank, and each value repeats on every login. See the pairwise subject identifier glossary entry for the short definition.

The sector is the host of the RP's redirect_uri by default. An RP that runs several hosts and wants one shared identifier across them registers a sector_identifier_uri. That URL returns a JSON array of redirect URIs, and the OP computes the pairwise value from the sector host rather than each redirect host.

OIDC Core suggests deriving the value by hashing the sector identifier, the user's local account ID, and a salt the OP keeps secret. Any method works if the output is stable per user per sector and cannot be reversed or computed by an outsider.

Pairwise stops cross-RP correlation through sub. It does nothing about a single RP tracking a user over time. That RP still sees the same value on every visit, which is exactly what it needs to maintain an account.

Ephemeral subject identifiers

OpenID Connect Ephemeral Subject Identifier 1.0 is authored by N. Sakimura (NAT.Consulting) and E. Jay (Illumila) in the OpenID Foundation's AB/Connect working group. It defines the subject_type value ephemeral alongside Core's public and pairwise. See the ephemeral subject identifier glossary entry for the one-line definition.

The spec has two privacy goals. The first is to stop a single RP from linking a user's separate visits. The second is to stop colluding RPs from correlating a user across services by comparing identifiers. Pairwise already handles the second for honest sectors. Ephemeral handles both, because no value ever appears twice.

The status matters for planning. Public review ran from July 17 to September 15, 2026. The Final Specification member vote ran from September 16 to September 30, 2026. The vote has closed. Our sources had not confirmed the result at the time of writing, so treat the document as a proposed final specification until the OpenID Foundation announces the outcome.

The three types side by side

The table compares the three types on the properties that decide which one you can use.

How an RP requests each type

Subject type is a property of the client registration, not of a single authorization request. The RP and OP agree on it once, and every ID Token for that client follows it.

• Discovery. The OP lists the types it issues in the subject_types_supported array of /.well-known/openid-configuration. A provider that supports all three advertises ["public", "pairwise", "ephemeral"].
• Registration. The RP sets subject_type in its client metadata. Through OpenID Connect Dynamic Client Registration this is a field in the registration request. Through an admin console, it is usually a setting on the application.
• Sector configuration. For pairwise, the RP may also register a sector_identifier_uri to share one identifier across several redirect hosts.

A registration request asking for ephemeral looks like this:

{
  "client_name": "Age Check Service",
  "redirect_uris": ["https://verify.example.com/callback"],
  "subject_type": "ephemeral",
  "response_types": ["code"],
  "grant_types": ["authorization_code"]
}

Check discovery before you register. If ephemeral is missing from subject_types_supported, the OP does not issue it. Fail closed in that case. An RP that silently accepts a public sub when it asked for ephemeral has lost the privacy property it was designed around.

The design consequence: no account keyed on sub

An ephemeral sub cannot be a primary key. That is the whole point of it, and it changes what the RP can build. (This section is our implementation guidance, not text from the spec.)

Most RP code does a lookup on iss plus sub at login, then creates or loads a user row. With ephemeral identifiers, every login creates a new row and none of them ever match again. You end up with an ever-growing table of one-visit strangers, and any feature that assumes a returning user breaks.

Ephemeral sub fits interactions where the RP needs an answer, not a relationship:

• Age gates. "Is this person over 18?" The RP needs a yes or no plus proof the OP vouched for it.
• Membership checks. "Is this person a current member of the co-op, union, or student body?"
• Residency checks. "Does this person live in the region this service is licensed for?"
• One-shot verification. A single eligibility check before a download, a vote, or a form submission.

If the product needs saved preferences, order history, or a subscription, it needs an account. Use a pairwise sub for that and collect as few other claims as possible. The identity data modeling guide covers how to keep identifiers separate from profile data.

What to log instead of sub

Audit still matters when the identifier is disposable. Log the session, not the person.

• Session-scoped sub. Store it only for the life of the session, so you can correlate events inside that one interaction.
• The decision and its evidence. Record the claim you relied on (for example, an age-over-18 result), the iss, the ID Token's iat, and the jti if present.
• Your own request ID. Generate a random transaction ID per check and log it beside the decision. That is what support and auditors use.
• Retention limits. Set a short retention window for these logs. A long-lived log that stores IP address, user agent, and timestamp can rebuild the linkage the identifier was meant to prevent.

Do not hash the ephemeral sub into a "stable" key or join it to anything that outlives the session. That recreates a persistent identifier with extra steps.

Pitfalls that defeat the point

Ephemeral sub protects one claim. The privacy outcome depends on everything else in the token and the session.

• Weak randomness at the OP. The spec calls for a cryptographically secure random number generator. A predictable or colliding generator risks two users receiving the same value and an account mix-up at any RP that misuses it.
• Linking through other claims. Releasing email, phone_number, a stable device ID, or a customer number next to an ephemeral sub gives the RP a correlation key anyway. Request only the attribute the decision needs. See data minimization and PII.
• Over-broad attributes. A full birthdate lets the RP narrow down a person. An "over 18" boolean does not. Selective disclosure formats exist for exactly this reason.
• Side channels. Cookies set by the RP, fingerprinting scripts, and analytics IDs all survive across visits. An ephemeral sub cannot undo tracking that happens outside OIDC.

What the spec leaves open

The specification does not address how ephemeral identifiers interact with refresh tokens, the UserInfo endpoint, or logout. Treat each of these as an open question for now:

• Refresh tokens. A refresh token that outlives the authentication session raises the question of which sub later tokens carry. Avoid issuing refresh tokens to ephemeral clients until your OP documents its behavior.
• UserInfo. Confirm the OP returns the same session-scoped sub from UserInfo as in the ID Token. A mismatch breaks the standard OIDC check that the two values agree.
• Logout. Front-channel and back-channel logout identify the user by sub or sid. Test how your OP handles both before relying on them.

Age signals, wallets, and unlinkability

The spec's stated motivation is a certification target. Ephemeral identifiers are a condition for showing that OpenID Connect and Self-Issued OpenID Provider (SIOP) deployments meet Unlinkability Level 3A+ of ISO/IEC 27551, the standard for attribute-based unlinkable entity authentication.

That puts ephemeral sub next to wallet-based credentials. In SIOP, the user's own wallet acts as the OP. A wallet that presents an age attribute under a fresh identifier each time gives the RP a verified answer and nothing to track. The same pattern applies to platform age signals, where an app receives an age bracket rather than an identity.

The architecture of age assurance, including how to treat an age result as a claim with provenance rather than a profile field, is covered on the main site in age assurance compliance architecture. For credential formats and wallets more broadly, see decentralized identity for CIAM.

Vendor support today

As of October 2026, no CIAM vendor profiled in CIAM Compass is known to advertise ephemeral in subject_types_supported. That is expected for a specification whose final vote closed days ago. Pairwise support is more common, but it varies by plan and product, so verify it the same way.

The reliable check is the provider's own discovery document:

curl -s https://<issuer>/.well-known/openid-configuration | jq .subject_types_supported

If the array contains ephemeral, register a test client and confirm three things. Two logins by the same user produce different values. The value is identical across the ID Token and UserInfo within one session. Refresh and logout behave the way your design assumes.