Continuing work on an SSO project reveals an interesting pattern: conversations about single sign-on quickly turn to logins, passwords, tokens, OAuth, OpenID Connect, and other authorization topics. This focus is understandable because users open a corporate portal, get redirected to a login page, enter credentials, and return authenticated. From the outside, SSO appears to be exactly that—one account, one login, access to multiple systems.
Yet during development, teams increasingly discuss different tasks. Some applications need extra user data from external corporate systems. Others require custom checks before issuing a token. Some want to notify an audit system of a successful login, while others need to trigger processes unrelated to password verification. All these tasks share one common point: the user always passes through SSO.
SSO therefore becomes more than an identity confirmation service. It is the single guaranteed point every employee traverses before reaching any corporate system. This raises a logical question: why not leverage this point for additional purposes?
SSO as a Unified Data Provider
Consider a typical corporate portal. After login it needs to display an employee’s photo, name, position, department, work phone, and manager contacts. Some data may reside in Active Directory, position and department in the HR system, projects in a resource management platform, clearance level in an IDM solution, and contacts in an internal directory. If the portal fetches everything itself, it quickly accumulates connectors, queues, caches, synchronization schedules, and error handling logic. The same problem repeats across CRM, Service Desk, and knowledge-base applications.
Instead, SSO can collect the necessary user context once and deliver it to connected systems as claims. Applications receive a signed token, verify it, and extract the allowed data set without knowing the original source of each attribute. This approach avoids the explosion of point-to-point integrations that occurs when each application independently connects to every corporate data source.
SSO does not need to become the single source of truth or physically store all records. The HR system remains the owner of personnel data, the IDM system owns access information, and the internal directory owns contact details. SSO’s role is to act as the single point of trust that aggregates and signs assertions from these authoritative sources.
OpenID Connect supports aggregated and distributed claims for exactly this scenario. An external provider can sign its own set of assertions, and the OpenID Provider includes that signed JWT in the overall response. Applications therefore receive verified statements without the SSO system itself asserting every fact.
SSO as an Authorization Processing Point
Between successful credential validation and token issuance lies a brief window where additional processing can occur. During this interval SSO can check employment status, verify network location, query a policy service, enforce MFA, display consent forms, fetch external claims, run custom scripts, or write detailed audit records.
The result is an authorization pipeline. Not every stage applies to every application. One system may need only basic login, another may require clearance verification, and a third may demand both external claims and mandatory MFA. Applications no longer implement this logic themselves.
SSO functions here as a Policy Enforcement Point (PEP) that consults an external Policy Decision Point (PDP). The emerging AuthZEN Authorization API 1.0 standardizes this exchange so that a PEP can send a request containing context and receive a decision that may be positive or negative, optionally including reasons or required actions.
This architecture keeps policy engines replaceable and prevents each application from duplicating the same checks. Instead of embedding roles directly in tokens, organizations can evaluate dynamic conditions—contract end dates, device compliance, risk scores—at the moment of access request.
