Ownership Scope
Over the years, identity management and authentication have evolved far beyond a simple username and password. Modern applications are often expected to support multiple authentication methods and external identity providers. Enterprise applications introduce additional requirements, including single sign-on (SSO), directory integration, automated user provisioning, and granular access control.
Meeting these requirements involves more than implementing authentication flows. Applications must also manage identities, sessions, permissions, and security policies while maintaining reliable integration with the rest of the system.
A fundamental architectural decision is how much of this responsibility the application should own and how much it should delegate to external systems. This choice affects implementation complexity, security responsibilities, operational overhead, flexibility, and long-term costs.
This section examines three ownership scopes: Managed, Hybrid, and Built, along with their trade-offs and the considerations that should guide the choice.
Scopes
-
Managed: Delegate all the identity and access management functions, to an external auth provider.
-
Hybrid: Delegate part of the subsystem to an external provider while building and operating the rest in-house.
-
Built: Build and operate the entire subsystem in-house.
Trade-offs
| Dimension | Managed | Hybrid | Built |
|---|---|---|---|
| Implementation effort | 🟢 Low. Integrate existing APIs, SDKs, and configuration. | 🟡 Moderate. Integrate external identity services with custom authorization. | 🔴 High. Design and implement the complete subsystem. |
| Architectural flexibility | 🔴 Limited by the platform's capabilities and extension points. | 🟡 High for authorization; authentication remains constrained by the provider. | 🟢 Maximum control over identity, authentication, and authorization. |
| Security responsibility | 🟢 Shared with the provider, which secures core identity infrastructure. | 🟡 Shared across the provider and internally maintained components. | 🔴 Full responsibility for security design, implementation, and maintenance. |
| Operational overhead | 🟢 Low. Core infrastructure and updates are managed externally. | 🟡 Moderate. Custom authorization components require operation and maintenance. | 🔴 High. All components require ongoing operation, monitoring, and updates. |
| Integration complexity | 🟢 Primarily configuration and integration with platform interfaces. | 🟡 Requires coordination between identity and authorization systems. | 🔴 Requires building and maintaining external integrations. |
| Vendor independence | 🔴 Core capabilities depend on the selected platform. | 🟡 Authentication depends on the provider; authorization remains independently controlled. | 🟢 Greater independence from identity platforms, with dependencies on underlying technologies. |
| Initial investment | 🟢 Low development cost, with recurring platform fees. | 🟡 Platform fees combined with custom development costs. | 🔴 High initial engineering and infrastructure investment. |
| Long-term maintenance | 🟢 Primarily integration updates, configuration, and platform changes. | 🟡 Provider integration plus maintenance of custom authorization. | 🔴 Continuous responsibility for the entire subsystem and its security lifecycle. |
Choosing a Scope
Choose Managed if all of these are true
- Your identity provider supports every authentication, identity management, and authorization capability your application requires, without substantial custom development.
- You're comfortable with the provider's authentication flows, authorization model, integration interfaces, and customization limits.
- Vendor dependency and the potential cost of switching providers are acceptable.
- The provider meets your security, compliance, performance, availability, and data-handling requirements.
- The provider's pricing model is sustainable at your anticipated scale.
Choose Hybrid if any of these are true
- Your application requires authorization rules that your identity provider cannot adequately express or enforce, such as complex resource relationships, inherited permissions, or context-dependent access.
- Authorization decisions depend on application-specific data that must remain under your control.
- You need a consistent authorization model across multiple applications, services, or identity providers.
- You want to expose a vendor-agnostic authorization API to your applications or customers, with independently controlled policies and evaluation logic.
- You need to evolve or replace your authorization infrastructure independently of your identity provider.
Prerequisite: An external provider must still be capable of satisfying your identity management and authentication requirements.
Choose Built if any of these are true
- You require direct control over identity records, credentials, or their lifecycle in ways that available identity platforms cannot support.
- Your application requires custom authentication protocols, credential mechanisms, or session-management behavior that existing solutions cannot accommodate.
- Regulatory, contractual, or security requirements prohibit delegating critical identity or authentication responsibilities to available platforms.
- Your performance, availability, isolation, or deployment constraints cannot be satisfied by existing identity solutions.
- Identity management or authentication is a core capability of your product, and its essential behavior cannot be implemented within the constraints of existing platforms.
Prerequisite: Your organization must have the expertise and resources to develop, secure, operate, and continuously maintain the complete subsystem.
Decision Rule
Choose the smallest ownership scope that satisfies all critical requirements.
Managed should be the starting point. Hybrid is justified when authorization needs independent ownership. Built is justified when identity management or authentication itself cannot reasonably be delegated.
A preference for additional control is not, by itself, sufficient justification for assuming additional engineering and operational responsibility.