How an identity control plane extends beyond sign in
A shared identity control plane coordinates authentication, access policy, organizational context and identity events across connected systems. Applications still enforce decisions and retain their own business rules.
A successful sign-in establishes who a user is. The application still needs to decide what that user may do, which organization they are acting for and whether their access remains valid as circumstances change.
For a small application, those responsibilities may be managed within the application itself. As more systems serve the same users, separate account stores, session controls and role models can make access harder to review and change consistently.
An identity control plane provides a shared place to coordinate those responsibilities. The term describes an architectural role, rather than a certification or a guarantee of capability. The useful question is which decisions the layer manages and how connected systems enforce them.
OXU Identity Platform follows this approach. It is designed to combine identity and sessions with shared access policy, organizational context, application entitlements and an identity event trail.
A simplified comparison of sign-in alone and continuing access checks. Applications need an explicit integration for authorization; a successful sign-in does not establish permission for every action.
The decisions that continue after sign in
Several operational questions become more important as systems are connected. Disabling an account in one place may leave a local session active elsewhere. A role change may not reach an application that relies on older token claims. Separate logs may identify the same person differently.
Organizational context also matters. An administrator who manages one workspace should not gain authority over another simply because both workspaces use the same identity provider. The application needs enough context to apply the intended boundary.
A shared layer can make these decisions more consistent without replacing the applications. It manages the common identity responsibilities, while each application retains its business logic, data controls and enforcement points. Connecting the two requires more than directing a browser to a common login screen.
Four responsibilities of a control plane
Authentication and session lifecycle
The layer authenticates the user and issues the relevant session, token or assertion for the integration. OIDC supports authentication built on OAuth 2.0, while SAML provides another established integration path for applications and partners that use it. [1]
MFA and passkeys belong within that authentication process. Session controls also need to define what happens when a user signs out, changes roles or leaves an organization. Applications must handle their own sessions consistently with the shared policy.
Authorization using current context
Authorization evaluates whether a request is allowed for a particular user, organization, workspace, role and application. A system can ask the shared layer for a decision and then enforce the result alongside its own business rules.
Where an application makes a fresh authorization check against updated policy, a revocation can affect the next checked request. That is a property of the integration, not of OIDC or SAML alone. Cached decisions, token lifetimes, local sessions and propagation delays can change when access actually ends. [2]
This is why revocation should be tested with an active session and a real application action. A central administrative change is only part of the result; the application must stop permitting the affected access.
Integration with connected systems
OXU provides OIDC and SAML integration paths for internal and third-party systems. These protocols help applications reuse shared authentication rather than implement every part independently.
Authorization checks, session handling and event collection still need to be connected where required. The goal is a repeatable integration with clear responsibilities. The amount of configuration or development depends on the system; a single configuration pass is not a universal outcome.
An identity event trail
A shared layer can bring authentication events, grants, revocations and policy changes into a consistent record. Stable identifiers make it easier to relate those events to the relevant user and organization.
That record supports operations and access reviews, but it is not automatically a complete history of business activity. To answer what a person viewed or changed inside an application, teams may also need application logs, reliable correlation and appropriate retention.
Shared identity responsibilities and connected applications. OIDC and SAML provide authentication integration paths; runtime authorization and application event reporting require their own enforcement and integration.
Comparing the two architectural scopes
The distinction is about responsibility, not the product label. Some services described as login services include broader controls. Evaluate the actual behavior of the layer and its connected applications.
Responsibility — Sign in focused service compared with Identity control plane:
- Primary scope — Sign in focused service: Authenticate users at entry — Identity control plane: Coordinate authentication and shared access decisions
- Revocation — Sign in focused service: May depend on each application’s sessions — Identity control plane: Coordinate changes and verify application enforcement
- Protocols — Sign in focused service: Support varies by service — Identity control plane: Provide agreed integration paths such as OIDC and SAML
- Organizations — Sign in focused service: May be represented locally — Identity control plane: Represent organizational context and entitlements centrally
- New applications — Sign in focused service: May need separate identity work — Identity control plane: Reuse shared functions through a defined integration
- Evidence — Sign in focused service: May focus on login events — Identity control plane: Correlate identity events with application evidence where needed
Where OXU is intended to fit
OXU Identity Platform is intended for organizations that need several connected systems to share identity and access policy. Typical requirements include organizational units or workspaces, delegated administration and application entitlements that vary between those units.
It can also fit services used by customers or partners when their applications connect to the shared layer over OIDC or SAML. This should be distinguished from brokering sign-in across many external identity providers.
OXU is not positioned as a replacement for a company-wide employee directory covering every employee and every off-the-shelf SaaS application. It is also not positioned as a federation hub between many customer identity providers.
External directory group synchronization and instant revocation signals across multiple identity providers remain on the roadmap. Inbound user provisioning and authorization checks within connected applications should not be confused with those broader capabilities.
Start with an access change you can verify
Before connecting another system, map where identity, permissions and sessions are managed today. Then choose one concrete change, such as removing a user’s access to an application, and trace how that change reaches an active session and a subsequent request.
That exercise shows whether the shared layer coordinates the controls your organization needs. Our approach with OXU is to make those responsibilities clearer and reduce repeated identity work, with the integration scope and product limits stated from the outset.