Building a mental model of SSO from three identity perspectives

At a glance

What this is: This is a three-perspective explanation of how SSO works, and its key finding is that identity provider setup, attribute mapping, and session handling create different obligations for employees, admins, and developers.

Why it matters: It matters because IAM teams must govern federated access consistently across human identity programmes, linked application access, and the lifecycle controls that determine who can connect, authenticate, and be deprovisioned.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.

👉 Read WorkOS' explanation of how SSO works across employee, admin, and developer views

Context

Single sign-on is more than a login convenience. It is a federation model that connects an identity provider, the application, and the attributes that travel between them. This article is useful because it separates the employee experience from the admin workflow and the developer integration path, which is where SSO programmes often become unclear.

For IAM teams, the real question is not whether SSO works, but what it assumes about identity lifecycle, profile data, and session control. The article points toward the operational work hidden behind federation: provisioning, deprovisioning, group mapping, and sign-out behaviour across connected applications.

Key questions

Q: How should security teams govern SSO across multiple enterprise applications?

A: Treat SSO as a lifecycle and trust problem, not only a login convenience. Security teams should define the identity provider as the source of truth, standardise the attribute set each app receives, and test that onboarding, role changes, and offboarding propagate cleanly across every connected application.

Q: Why do profile mappings matter so much in federated identity?

A: Because applications usually consume claims from the identity provider rather than discovering user data themselves. If name, role, or group mappings drift, access decisions can become inconsistent across apps, and the same user may inherit different entitlements depending on how each integration interprets the assertion.

Q: What breaks when single logout is treated as the same thing as offboarding?

A: Users may appear signed out while still retaining valid access paths in other systems. Single logout ends a session, but offboarding removes future access. IAM teams need both controls, plus directory and app-level revocation checks, to make sure the user cannot silently return through another entry point.

Q: How do teams know if SSO is actually reducing identity risk?

A: Look for complete revocation, consistent attribute mapping, and reduced per-app account sprawl. If access can only be managed centrally but not fully removed downstream, the programme has simplified administration without fixing governance. Measure the number of app-specific exceptions and failed deprovisioning cases.

Technical breakdown

How identity provider federation works in SSO

SSO depends on a trust relationship established before a user ever signs in. The application knows which identity provider to redirect to, and the identity provider returns an assertion or token that proves authentication and carries selected identity attributes. In practice, that means the app is not authenticating the user itself. It is consuming a claim set produced by the identity provider under a federation standard such as SAML or OIDC. The technical burden sits in mapping domains, certificates, redirect endpoints, and the profile fields the app expects.

Practical implication: inventory every federated app, its IdP dependency, and the exact attributes it consumes before you standardise SSO onboarding.

Profile assertions and attribute mapping across apps

The article shows that profile data does not originate in the application. Name, email, role, and similar fields are maintained upstream and passed through during login. That creates a governance issue as much as a technical one, because each app may need a different subset of fields and may interpret them differently. Attribute mapping becomes the bridge between directory truth and application behaviour. If those mappings drift, access decisions and user entitlements can diverge from the source system of record.

Practical implication: define a minimum attribute contract for enterprise apps and review every mapping when a role, group, or claim changes.

Single logout and deprovisioning are not the same thing

Logout in federated identity is not just local session termination. A single logout flow may need to notify the identity provider so that the upstream session ends as well. That is different from deprovisioning, which removes or disables the ability to sign in later. The article correctly hints that these are separate control planes. One governs current session state, the other governs future access. Confusing them leads to users who appear signed out but still retain live access paths elsewhere.

Practical implication: treat session termination, app access removal, and directory offboarding as distinct controls in your access governance model.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SSO is a lifecycle governance problem, not just an authentication pattern. The article focuses on the login flow, but the real work is who gets onboarded, what profile data is asserted, and how access is removed later. That makes SSO part of joiner-mover-leaver governance, not a standalone sign-in feature. Teams that treat it as a front-end convenience usually miss the downstream control obligations.

Federation shifts trust from the application to the identity provider, which raises the cost of attribute mistakes. Once the app relies on upstream claims, the quality of name, role, and entitlement data becomes a control boundary. If those attributes are stale or inconsistent, the application inherits the error at scale. Practitioners should treat attribute accuracy as an access control dependency, not an administrative detail.

Single sign-on simplifies user experience while increasing blast radius if deprovisioning is weak. Centralised access makes revocation easier only when the upstream directory and downstream app entitlements are tightly governed. If revocation is partial, a departing user can retain app-specific access even after the central account changes. The implication for IAM teams is to measure revocation completeness, not just SSO adoption.

Developer-led SSO integration is where hidden identity debt accumulates. The article notes that each provider has quirks on top of SAML and OIDC, which means every integration decision becomes a governance choice about claims, logout, and configuration drift. That is why enterprise identity architecture needs reusable standards, not one-off application exceptions. Teams should standardise the integration pattern before app sprawl hardens into policy drift.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• A separate NHI Mgmt Group finding shows that NHIs outnumber human identities by 25x to 50x in modern enterprises, which is why federation and lifecycle controls cannot be managed ad hoc.
• That visibility gap is why teams should also review the NHI Lifecycle Management Guide when building provisioning, revocation, and offboarding workflows.

What this signals

SSO programmes are often rolled out as user experience improvements, but the governance burden lands in directory hygiene, claim design, and offboarding accuracy. When identity becomes federated, weak lifecycle discipline shows up as inconsistent access across applications rather than a single obvious failure.

Federation drift: the gap between what the identity provider asserts and what each application actually trusts will widen unless teams standardise mappings and testing. That makes SSO architecture a control-plane issue, not a convenience feature, and it is one reason the OWASP Non-Human Identity Top 10 remains relevant wherever credentials and claims are delegated across systems.

For practitioners

• Map the full federation trust chain Document which identity provider each application trusts, which protocol it uses, and which attributes it consumes before rollout. Include redirect targets, certificate ownership, and the system of record for each claim.
• Separate provisioning from session management Treat onboarding, live session termination, and offboarding as distinct controls. A user can be signed out locally while still holding valid access elsewhere if the upstream session and downstream entitlements are not handled together.
• Standardise attribute contracts for enterprise apps Define the minimum profile fields every application may request, then constrain custom claims to approved cases. Review role mappings and group assignments whenever an app or identity provider changes.
• Test deprovisioning end to end Validate that removing a user in the source directory actually revokes application access, not just the visible login session. Include SSO, SCIM, and app-local permissions in the test path.

Key takeaways

• SSO is really a federation and lifecycle governance model, not just a faster login flow.
• Attribute mapping and revocation completeness determine whether centralised identity control actually reduces risk.
• Teams that do not test end-to-end offboarding can simplify access administration without fixing access governance.

Key terms

• Identity Provider: An identity provider is the system that authenticates a user and issues identity assertions to applications that trust it. In SSO, it becomes the upstream authority for login decisions, profile data, and session context, so its configuration directly affects downstream access control and revocation behaviour.
• Federated Authentication: Federated authentication lets one organisation or platform accept a login performed by another trusted identity system. The application no longer verifies the user directly. Instead, it consumes signed claims or assertions, which makes trust relationships, certificates, and attribute mapping part of the security boundary.
• Single Logout: Single logout is a federated sign-out mechanism that attempts to terminate a session across the application and the upstream identity provider. It is not the same as deprovisioning. A user may be logged out locally while still retaining other valid sessions unless the full trust chain is closed.
• Attribute Mapping: Attribute mapping is the process of translating identity data from a source system into the fields an application uses for access and user profile logic. It is a governance control as much as an integration task, because incorrect mappings can create inconsistent entitlements across apps.

Deepen your knowledge

SSO federation, attribute mapping, and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building identity controls across multiple applications, it is worth exploring.

This post draws on content published by WorkOS: Building a mental model of identity providers from scratch. Read the original.