Notifications
Clear all
Topic starter
06/06/2026 1:35 am
TL;DR: SSO can be broken into three practical views — employee, IT admin, and developer — to show how identity provider setup, profile assertions, and logout orchestration fit together across enterprise access flows, according to WorkOS analysis. The model is incomplete, but it surfaces the integration and governance questions teams need to answer before scaling SSO.
NHIMG editorial — based on content published by WorkOS: Building a mental model of identity providers from scratch
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Map the full federation trust chain Document which identity provider each application trusts, which protocol it uses, and which attributes it consumes before rollout.
- Separate provisioning from session management Treat onboarding, live session termination, and offboarding as distinct controls.
- Standardise attribute contracts for enterprise apps Define the minimum profile fields every application may request, then constrain custom claims to approved cases.
What's in the full article
WorkOS' full article covers the operational detail this post intentionally leaves for the source:
- A step-by-step walk-through of the employee, admin, and developer flows across SAML and OIDC integrations.
- Examples of how profile fields move from the identity provider into downstream applications during login.
- The practical questions around JIT provisioning, group mapping, signed assertions, and certificate rotation.
- How logout and single sign-out differ from deprovisioning in real enterprise deployments.
👉 Read WorkOS' explanation of how SSO works across employee, admin, and developer views →
Identity providers from scratch: what SSO really means for IAM teams?
Explore further
06/06/2026 2:48 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Building a mental model of SSO from three identity perspectives
