Skip to content

ADR-0008: OpenIddict for identity and OAuth2/OIDC

Decision

This page records a decision and its status. A Proposed decision is not binding; an Accepted decision is binding on the Factory until amended or superseded.

  • Status: Accepted
  • Date: 2026-01-01
  • Deciders: Security Architect, Identity Lead
  • Tags: identity, security, auth

Reviewed 2026-10-09 — retained, subordinated to canonical ADR-0101

  • Disposition: retain OpenIddict as the implementation choice.
  • Binding canonical decision: ConnectSoft.Documentation ADR-0101 (accepted 2026-06-30) assigns token issuance to the Authorization Server only, accounts/credentials/MFA/memberships to the Identity Service, route policy to the gateway, domain and tenant authorization to backends, and frontend auth state to the Blazor Shell. APIs accept access tokens, not ID tokens. This ADR's wording ("coarse RBAC at the gateway; ABAC through PolicyEngineService") is Target; no PolicyEngineService exists.
  • Verified: ConnectSoft.AuthorizationServerTemplate, ConnectSoft.IdentityTemplate, Extensions.IdentityPlatform and Extensions.ResourceServer exist; DerechHaLev runs an AuthServer and an Identity service from them.
  • Provenance: Date is the 2026-06-17 bulk-commit value.

Context

The platform needs standards-based authentication and token issuance that supports multi-tenancy (tenantId claim), RBAC/ABAC, and service-to-service identities, and that can be embedded in generated products (see Security Architecture). The factory ships an AuthorizationServerTemplate and IdentityTemplate.

Decision

Use OpenIddict as the OAuth2/OpenID Connect authorization server. JWTs carry tenantId, subject, roles, and scopes. Coarse RBAC is enforced at the gateway; fine-grained ABAC decisions go through the Governance PolicyEngineService. Generated products inherit this via the identity/authorization-server templates.

Decision drivers and consequences

Positive

  • Standards-based, .NET-native auth embeddable in factory and generated products.
  • Consistent token/claim model enabling tenant isolation and service identities.

Negative / trade-offs

  • Operating an authorization server (key management, rotation) is the platform's responsibility.

Neutral

  • External IdPs can federate into OpenIddict where required.

Alternatives considered

Alternative Why not chosen
Managed IdP only (e.g. Entra ID) Less control for embedding in generated multi-tenant products; federation still supported.
Duende IdentityServer Licensing/cost considerations; OpenIddict meets needs.