The OpenID Foundation has approved the final specification for OpenID Connect Ephemeral Subject Identifier 1.0. If you're managing federated identity at scale, this changes how you can protect user privacy across relying parties without breaking interoperability.
OpenID Connect already serves billions of users across millions of applications. This new specification adds a privacy control that's been missing: the ability to issue temporary, context-specific subject identifiers instead of persistent ones that create tracking vectors across your federation.
What Changed
The final specification introduces a standardized method for identity providers to issue ephemeral subject identifiers during OpenID Connect flows. Instead of returning the same sub claim every time a user authenticates to a relying party, your identity provider can now generate unique, non-reusable identifiers per session or per authorization.
This breaks the correlation chain. A relying party receives a valid subject identifier for the current session but can't use it to track the user across subsequent authentications or correlate activity with other relying parties.
The specification defines:
- How identity providers signal ephemeral identifier support
- The lifetime semantics for ephemeral subjects
- Validation requirements for relying parties
- Metadata extensions for discovery
Key Findings
Ephemeral identifiers eliminate cross-site correlation by design. When you issue a fresh subject identifier for each authorization, relying parties can't build persistent profiles by tracking the same sub value over time. This isn't anonymization (you're still authenticating the user), but it prevents the identifier itself from becoming a tracking token. For GDPR Article 25 (data protection by design), this gives you a technical control that reduces processing to what's necessary for the current session.
Implementation requires coordination between your identity provider and relying parties. Your identity provider must support ephemeral subject generation and signal this capability in its metadata. Relying parties must handle non-persistent subjects correctly, which means they can't rely on sub for long-term user record linkage. If your federation includes third-party relying parties, you'll need to communicate this change and provide migration guidance.
Session management becomes more complex. With persistent subjects, you could tie sessions to a stable identifier. With ephemeral subjects, you need alternative correlation mechanisms. Options include issuing correlation tokens in back-channel communication, using claims other than sub for internal record linkage (where justified by processing purpose), or accepting that some relying parties will need to re-authenticate users more frequently.
Not every use case benefits from ephemeral identifiers. If a relying party needs to maintain user accounts, track consent history, or provide personalized services across sessions, ephemeral subjects create friction. The specification works best for stateless relying parties, single-session applications, or scenarios where privacy preservation outweighs continuity requirements.
Audit and compliance reporting need new approaches. Your security team is used to querying authentication logs by subject identifier. When those identifiers change per session, you'll need to implement alternative correlation for incident response. Consider maintaining an encrypted mapping table in your identity provider's audit logs, accessible only to security operations under defined procedures.
What This Means for Your Team
If you operate an identity provider in a federation with strict privacy requirements, this specification gives you a standards-based tool to reduce tracking risk. You're no longer choosing between interoperability (OpenID Connect) and privacy (non-persistent identifiers). You can implement both.
For identity governance administrators, the shift affects how you model user entitlements. You can't use ephemeral subjects as foreign keys in your entitlement catalog. You'll need to either maintain a protected mapping layer or use alternative claims (email, User Principal Name, internal employee ID) for entitlement assignment, then justify that processing under your data protection assessment.
The specification also changes your threat model for session hijacking. A stolen ephemeral subject identifier has limited value because it expires with the session and can't be reused for future authentications. This doesn't eliminate session hijacking risk, but it reduces the window and scope of compromise.
Action Items by Priority
Evaluate your federation's privacy requirements first. Not every federation needs ephemeral identifiers. If you're operating a workforce identity provider for internal applications, persistent subjects may be appropriate. If you're federating with external relying parties that don't need long-term user tracking, ephemeral identifiers reduce your exposure to cross-site correlation claims.
Audit your relying party dependencies. Identify which applications in your federation rely on persistent sub values for user account linkage, entitlement assignment, or audit trails. These applications will need refactoring before you can enable ephemeral identifiers. Build a migration plan that prioritizes low-dependency relying parties first.
Extend your identity provider metadata. Once you've implemented ephemeral subject support, publish the capability in your OpenID Provider metadata. Relying parties that support the specification will discover this automatically. For relying parties that don't, you'll need to provide configuration guidance.
Implement correlation mechanisms for security operations. Before you deploy ephemeral identifiers to production, ensure your security team can still investigate incidents. This might mean maintaining a time-limited mapping table between ephemeral and internal identifiers, accessible only through your privileged access workflow. Document the access procedure and retention policy.
Test session lifecycle edge cases. Ephemeral identifiers change how token refresh works, how you handle concurrent sessions, and how you process logout requests. Test these flows thoroughly in a staging environment with representative relying parties before rolling out to production.
Update your data protection documentation. If you're implementing ephemeral identifiers to meet GDPR or similar regulations, document the technical measure in your data protection impact assessment. Include the identifier lifetime, correlation controls, and the business justification for any persistent identifiers you still maintain.
