What breaks when claims are shared too broadly in SSO?

Over-sharing claims weakens privacy, expands downstream exposure, and makes access decisions depend on data the application does not actually need. In practice, the problem is not only leakage but governance drift, because claim release decisions start to outlive the business justification that created them.

How Broad Claim Release Undermines the SSO Trust Model

SSO works because the application receives only the assertions it needs to make a narrow access decision. When claims are released too broadly, the application starts depending on identity data that is not essential to the transaction, and that expands the blast radius if the token, session, or federation trust path is misused. The OpenID Connect Core 1.0 specification is a useful reference for where those assertions fit in the sign-in flow.

That over-sharing also creates design drift. Teams often add claims to solve one local integration need, then those fields become embedded in downstream business logic, reporting, and authorisation checks. Once that happens, removing a claim becomes a breaking change, even if the claim was never part of the original access requirement.

In practice, the issue is less “too much information” in the abstract and more “too much authority attached to unnecessary data.” If an application uses attributes it should never have trusted for its decision, the federation boundary no longer contains the risk, because the extra data now shapes behaviour beyond the identity provider.

Why Over-Sharing Claims Becomes a Governance Problem

Claim release should be treated as a governed contract, not a convenience setting. Every additional claim creates a retention question, a justification question, and an ownership question: who approved it, why it exists, and what must happen when the business need changes. Without that discipline, SSO configuration tends to accumulate exceptions faster than it is reviewed.

Two patterns are especially common. First, applications request broad profile data because it is easier than refactoring the authorization model. Second, teams keep old claims “just in case,” even after the original use case has disappeared. Both patterns produce governance drift, where the federation policy no longer reflects the current business process.

That drift matters because SSO is often treated as a trust anchor for many applications at once. A weak claim-release decision in one integration can therefore spread into multiple downstream systems, and each copy makes later cleanup harder. Identity Provider and SSO Security Guide covers the defensive side of that trust boundary, including federation monitoring and token handling.

Which Claims Are Usually Over-Shared, and Why That Matters

The highest-risk claims are the ones that are not required for sign-in but are still used to personalise, route, or authorise requests. Common examples include group membership, role names, department, manager, location, cost centre, entitlement lists, or external identifiers that let downstream systems correlate a person across environments.

Those fields can be useful, but only when they are deliberately tied to a business purpose. If they are released by default, they can expose more about a user than the relying party needs, and they can also create brittle dependencies. A group rename, directory cleanup, or org restructure can then break access in places that should never have depended on that detail.

Over-sharing is also a reliability issue. Large or chatty claim sets increase the chance that one application starts depending on a claim format, value, or hierarchy that another application never intended to guarantee. The result is inconsistent access behaviour across applications that are supposedly using the same SSO source of truth.

Risk and Threat Considerations

Over-broad claim release increases privacy exposure, widens lateral visibility across applications, and makes downstream compromise more valuable because a single assertion can unlock multiple business paths. It also raises the chance that an attacker who obtains a valid session or token can learn more than necessary from the claims themselves.

Failure mechanism: The identity provider releases attributes that exceed the relying party’s actual need, and downstream systems start using those attributes as de facto trust inputs, which expands the blast radius of any token, session, or federation issue.

Impact: Sensitive user context can leak across services, authorization logic becomes harder to change safely, and claim release decisions can outlive the business justification that created them.

Practitioner Guidance

What to verify: For each relying party, verify that every released claim is tied to a documented use case that is still active. If the application only needs authentication, keep the assertion minimal and avoid shipping profile data that merely makes integration easier.

Decision rule: If a claim is used for authorization, treat it as part of the access model and review it with the same discipline as a role or policy change. If it is only used for display or convenience, prefer an application lookup or a narrower claim before you make it a federation requirement.

Common mistake: Treating claim release as a one-time setup task. In practice, the security test is whether the business can remove that claim without breaking access, proving that the integration still has a clean separation between identity proof and application-specific logic.

Practitioner takeaway: The safest SSO design is not the one that sends the most context, it is the one that keeps identity assertions narrowly scoped, periodically re-justified, and easy to withdraw when the business need changes.

Related resources from NHI Mgmt Group

• What breaks when sensitive personal information is shared too broadly with processors?
• What breaks when a custom GPT is shared too broadly?
• When does an NHI become too risky to keep as-is?
• What breaks when a custom SSO implementation is too tightly coupled to tenant-specific IdP settings?