The Composable Identity Pattern: Build What You Need, Skip What You Don't

There's a familiar pain point in enterprise software: you need one capability from an identity platform, but to get it you have to adopt the entire platform. You wanted SAML federation for a single enterprise customer, and now you're running a full Identity Access Management (IAM) suite with user management, workflow engines, and admin portals you'll never use. You're paying for it in licensing, complexity, operational overhead, and the attack surface you didn't ask for.

This is the monolith problem.

The software industry spent the last decade decomposing monolithic applications into modular, composable services. Gartner formalised this as the "composable business." Organisations built from interchangeable building blocks that can be assembled and reassembled as needs change. Martin Fowler's work on microservices laid the architectural foundation for how teams think about modularity. But somehow, the identity layer got left behind. Most IAM platforms are still monoliths: all-or-nothing, take-it-or-leave-it.

The composable identity pattern offers an alternative. Start with the core protocol support you need today. Add capabilities incrementally as your business demands them. Never pay the complexity cost of features you don't use. This post explains the pattern, shows what it looks like at each stage of a company's growth, and demonstrates why additive architecture is the future of identity infrastructure.

The Monolith Problem in IAM

If you've ever adopted an enterprise IAM platform, the story is predictable. You evaluated it for one or two capabilities — say, OpenID Connect and basic user authentication. But the platform doesn't sell capabilities à la carte. It sells itself. So you got the full suite: the user directory, the consent management engine, the admin portal, the reporting dashboard, the workflow orchestrator. Each one a dependency. Each one is an update to manage. Each one is a potential failure point.

The costs compound in ways that aren't obvious during procurement.

Vendor lock-in is the first and most durable cost. Once your user sessions, configurations, and integrations are woven into the platform, switching costs become enormous. Migrating users alone, with their credentials, MFA enrolments, and consent records, can be a multi-quarter project.

Feature bloat follows close behind. You're running infrastructure to support capabilities you never enabled. Your developers have to understand a system far larger than the one they're actually using to operate the parts they care about. Every upgrade cycle forces you to regression-test features you don't use but can't remove.

Then there's the upgrade cliff. Monolithic platforms version everything together. A security patch for the SAML module forces you to upgrade the entire platform, including breaking changes in modules you depend on. Teams delay patches because the upgrade scope is too large, and the security debt accumulates silently.

The fundamental issue is that monolithic IAM tries to be everything for everyone. A startup building a B2C SaaS product and a bank building a B2B API platform have radically different identity requirements. A system that tries to serve both optimises for neither.

In the application layer, we solved this problem years ago. Nobody deploys a monolithic ERP for every business need anymore. We compose solutions from specialised, interoperable services. The identity layer deserves the same treatment.

What Is Composable Architecture?

Composable architecture isn't a buzzword. It's a set of structural principles that have been formalised by both industry analysts and practitioners.

The Gartner Framework

Gartner defines the composable business around four principles, and each one maps directly to how identity infrastructure should work:

Modularity means capabilities are packaged as self-contained, interchangeable units. Applied to identity, this means OIDC is a module. SAML is a module. FAPI compliance is a module. User management is a module. Each works independently of the others.

Autonomy means each module can operate and evolve on its own schedule. You can upgrade your SAML support without touching your OIDC configuration. You can add financial-grade security compliance without refactoring existing clients.

Orchestration means modules can be assembled in different combinations depending on context. A financial services deployment might compose core authentication with FAPI and push authorisation requests. A healthcare deployment might comprise core authentication, SAML federation, and specialised consent flows. Same foundation, different assemblies.

Discovery means new capabilities can be integrated as needs emerge. When a customer suddenly requires a protocol or compliance profile you haven't needed before, you add that capability without re-architecting your identity infrastructure.

Fowler's Microservices Principles

Martin Fowler's foundational work on microservices established principles that apply just as well to identity infrastructure:

• Organised around business capabilities, not technical layers. Identity modules should be organised around protocol capabilities rather than internal implementation details: authentication, federation, and authorisation.
• Products, not projects. Each identity module has ongoing ownership and maintenance. It's not a build-and-forget artifact.
• Decentralised governance. Teams can choose which identity capabilities they need without a central committee having to approve every addition.
• Evolutionary design. The identity architecture can evolve incrementally, without big-bang migrations.

These principles aren't aspirational. They describe how the best infrastructure already works. Identity is simply catching up.

The Additive Model: Start Minimal, Grow Intentionally

The composable identity pattern follows one guiding principle: additive, not subtractive. Instead of starting with everything and disabling what you don't need, you start with the minimum viable identity surface and enable capabilities as requirements emerge.

Each addition is independent. Adding SAML doesn't change how your OIDC clients work. Adding FAPI compliance doesn't require modifying your existing token validation logic. And critically, there's no penalty for starting small. The minimal configuration today doesn't limit what you can do tomorrow.

Here's what the progression looks like in practice.

Stage 1: Core Authentication and Authorisation

You're building a SaaS product. Your identity needs are straightforward: user login and logout, API authorisation with access tokens and scopes, token refresh for long-lived sessions, and support for a handful of client applications — a web app, a mobile app, maybe a CLI tool.

This is the foundation, and it handles the vast majority of identity needs for most products. You configure your identity server with a few API scopes, a couple of client definitions, and a user store. Done. You move on to building the product that actually makes money.

Stage 2: Enterprise Federation

Your first enterprise customer arrives. They're a Fortune 500 company, and they have a hard requirement: their employees must authenticate through their corporate identity provider via SAML. This isn't negotiable. It's how their security team operates.

In a monolithic IAM world, this might mean migrating to an entirely different platform that supports SAML. A project measured in months, not days.

In the composable model, you add the SAML capability to your existing identity server. Your existing OIDC configuration doesn't change. Your existing clients don't notice. Your existing users aren't affected. You've added a capability, not replaced a system. The enterprise customer is onboarded, and your product roadmap doesn't lose a quarter to an identity rewrite.

Stage 3: Financial-Grade Security

Your product is expanding into regulated industries — financial services, healthcare, and government. These sectors have strict security requirements codified in profiles like FAPI (Financial-grade API). The requirements include pushed authorisation requests, signed request objects, certificate-bound access tokens, and other mechanisms designed to prevent token theft and replay attacks.

Once again, the composable model makes this additive. Your existing OIDC clients continue to work as before. Your SAML federation keeps working. You add the FAPI compliance capability for the specific clients and APIs that need it. New clients entering the regulated flow get the stricter security profile. Existing clients are unaffected.

Stage 4: Operational Maturity

You're running at scale now. Millions of users, dozens of services, multiple regulatory jurisdictions. Your operational needs have grown: you need distributed tracing through the identity layer, health checks that integrate with your infrastructure monitoring, centralised configuration management, and seamless integration with your orchestration platform.

This too is additive. Operational tooling layers on top of your existing identity infrastructure without changing authentication behaviour. It's another building block, composed alongside everything else.

The Critical Observation

Notice what didn't happen at any of these stages. There was no rip-and-replace. No user migration. No reconfiguration of existing clients. No "big bang 💥" upgrade that puts the business at risk. Each stage was purely additive. The investment made in Stage 1 carried forward through every subsequent stage.

Contrast this with the monolithic approach, where each of these transitions — adding SAML, adding FAPI, adding operational tooling — might have been a migration project with its own risk, its own timeline, and its own budget fight.

A Company That Grows Through Composability

To make this concrete, consider a fictional but realistic company: Acme Analytics, a B2B SaaS platform for data analytics.

At the seed stage, Acme's identity needs are simple. They need user login, API tokens for their SDK, and a few OAuth clients. They configure core OIDC and OAuth 2.0, knock it out in a sprint, and get back to building the product. They don't need SAML, SCIM provisioning, FAPI, or advanced user management. So they don't pay for any of it. Not in licensing, not in complexity, not in cognitive overhead.

After their Series B, their first enterprise customer lands — a Fortune 500 bank. The bank's requirement is non-negotiable: employees authenticate through the corporate identity provider via SAML. Acme adds the SAML capability to its existing identity server. One sprint. Enterprise customer onboarded. Product roadmap intact.

By Series C, Acme is entering the financial services vertical. Regulatory pressure intensifies. They need FAPI compliance for API security, pushed authorisation requests, and certificate-bound tokens. They add the FAPI capability. Existing clients are unaffected. New financial-grade clients are configured with a stricter security profile. When SOC 2 auditors ask about identity infrastructure, the audit is straightforward because everything runs through a single, well-defined system.

At scale, Acme runs dozens of microservices and serves millions of users across multiple regulatory jurisdictions. They layer on operational tooling: distributed tracing, health monitoring, and infrastructure integration for their deployment orchestration.

At no point did Acme rip and replace its identity system. At no point did they migrate users or reconfigure existing clients. Each stage was additive. Each investment is compounded. The identity infrastructure they built in their first sprint is still running underneath everything. Extended, never discarded.

What Composable Identity Is NOT

The composable pattern is specific, and it's worth clarifying what it doesn't mean.

It doesn't mean microservices for identity. You're not running separate services for OIDC, SAML, and FAPI that talk to each other over the network. It's a single identity server composed of modules. The composition happens at build time and configuration time, not at runtime via network calls. This is important. Decomposing identity into separate services would introduce latency, failure modes, and coordination complexity, defeating the purpose.

It doesn't mean a plugin marketplace. This isn't an ecosystem of third-party extensions with varying quality, compatibility, and support lifecycles. Composable identity modules are first-party, tested together, and supported by the same team. The quality is uniform because the ownership is unified.

It doesn't mean DIY assembly. You don't wire up protocol handlers from scratch. Each module is opinionated and production-ready. "Composable" means you choose which capabilities to include, not that you build those capabilities yourself.

And it absolutely doesn't mean optional security. You can't compose away security fundamentals. The core always enforces protocol compliance, token security, and cryptographic best practices. Modules add capabilities on top of a secure foundation; they don't weaken it.

Why This Matters Now

The composable identity pattern isn't just an architectural nicety. It addresses real pressures that are intensifying across the industry.

The protocol landscape is expanding. Five years ago, most teams only needed OIDC and OAuth 2.0. Today, enterprise customers demand SAML. Regulated industries require FAPI. Decoupled authentication scenarios call for CIBA. For organisations looking to accelerate velocity with AI tools and Agentic workflows, MCP and CIMD are top of mind. Each new protocol requirement is a potential migration project — unless your identity infrastructure is built to absorb new capabilities additively.

Compliance requirements are multiplying. GDPR, SOC 2, HIPAA, PCI DSS, PSD2, and emerging state-level privacy laws each impose specific requirements on authentication and access control. A monolithic identity platform that versions everything together makes compliance upgrades painful. A composable architecture lets you add compliance capabilities to the specific areas that need them.

Engineering teams expect composability. Modern developers are accustomed to building systems from composable, modular building blocks. They expect their identity infrastructure to work the same way — until it doesn't. When adding one capability requires understanding and upgrading the entire platform, it feels like a step backward.

Conclusion

The days of all-or-nothing IAM platforms are ending. Just as application architecture moved from monoliths to composed services, identity architecture is making the same shift.

The composable identity pattern suggests starting minimal, adding capabilities as needs emerge, and never paying for what you don't use. This mantra aligns with how modern engineering teams actually want to work: incrementally, iteratively, and with full control over what they deploy and operate.

This isn't theoretical. IdentityServer v8's additive architecture makes this pattern concrete for .NET teams. Each capability is a building block. Each addition is safe. Each investment carries forward.

The question for your team isn't whether you'll eventually need SAML, or FAPI, or advanced operational tooling. You will. The question is whether your identity infrastructure will gracefully absorb those requirements or whether each will be a migration project.

Sources and Further Reading

1. Gartner — Composable Business — https://www.gartner.com/en/information-technology/glossary/composable-business — Gartner's framework for building organisations from interchangeable, modular business capabilities.
2. Martin Fowler — Microservices — https://martinfowler.com/articles/microservices.html — The foundational article on microservices architecture.
3. Duende IdentityServer Documentation — https://docs.duendesoftware.com/ — Official documentation covering IdentityServer's modular architecture, SAML support, FAPI compliance, and infrastructure integration.
4. OAuth 2.0 Security Best Current Practice (RFC 9700) — https://datatracker.ietf.org/doc/html/rfc9700 — IETF best practices for OAuth 2.0 security.
5. FAPI 2.0 Security Profile — https://openid.net/specs/fapi-security-profile-id2-2-0.html — The Financial-grade API security profile.