Skip to content

ADR-0016: Identity Platform End-to-End Responsibility Model

  • Status: accepted
  • Deciders: ConnectSoft Architecture Team
  • Date: 2026-06-30

Context and Problem Statement

ConnectSoft products rely on login, registration, token issuance, federation, MFA, API Gateway protection, Blazor Shell / microfrontend sessions, and backend authorization. Treating all of this as one generic "identity service" creates unclear ownership and makes it difficult to evolve templates consistently.

We need a company-level responsibility model that separates product, platform, gateway, frontend, and backend concerns while keeping one coherent identity platform story.

Decision Drivers

  • Standards-based OAuth/OIDC must remain the trust foundation.
  • Identity data, token issuance, API routing, frontend session UX, and backend resource authorization have different owners and failure modes.
  • External identity federation and MFA require explicit governance.
  • Factory templates must align without copying identity logic into every service or frontend.
  • Company documentation should summarize the model while technical contracts live in ConnectSoft.Documentation.

Considered Options

Option 1: One Identity Monolith

Put user management, OAuth/OIDC, gateway policy, UI session behavior, and backend authorization into one product/service boundary.

Rejected because it blurs ownership, couples unrelated release cycles, and makes gateway/backend authorization harder to govern.

Option 2: Every Product Owns Its Own Auth

Allow each SaaS product, gateway, and frontend to define its own login, tokens, users, and claims.

Rejected because it creates security drift, inconsistent federation, duplicated MFA behavior, and poor cross-product user experience.

Option 3: Separated Identity Platform Responsibility Model (Selected)

Adopt a platform model with explicit responsibilities:

  • Authorization Server owns OAuth/OIDC clients, scopes, consent, token issuance, signing keys, refresh, revocation, introspection, discovery, and JWKS.
  • Identity Backend owns users, credentials, profiles, MFA, recovery, roles, claims, tenant membership, and external account links.
  • API Gateway owns public API perimeter, route policy, CORS, throttling, coarse authorization, and trusted context propagation.
  • Blazor Shell and MFEs own login/session UX and use approved OIDC/PKCE or BFF-style integration.
  • Backend APIs own resource-level authorization, tenant isolation, business permissions, and audit events.

Decision

ConnectSoft adopts the separated Identity Platform responsibility model for new platform, template, and SaaS product work.

Company documentation will describe the product/governance view. Detailed technical flows, contracts, claims, headers, implementation backlog, and component documentation remain in ConnectSoft.Documentation.

Consequences

Positive

  • Clearer ownership across Authorization Server, Identity Backend, Gateway, frontend, and backend services.
  • Consistent support for federation, MFA, step-up, token lifecycle, and tenant-aware authorization.
  • Better template alignment and fewer duplicated security implementations.
  • Safer gateway and backend integration because context propagation is explicit.

Negative

  • Teams must understand the distinction between identity, authorization server, gateway, and resource-server responsibilities.
  • End-to-end features require coordinated documentation and test coverage across multiple repositories.
  • Migration from monolithic assumptions may require cleanup of older docs, samples, and template defaults.