adr.zone

ADR Example: Managed authentication (IdP) vs in-house (ISO 42010–inspired format)

Software architecture decision example for end-user auth: when a small team accepts vendor coupling to ship MFA, OAuth, and recovery flows safely. The markdown below is identical in substance across formats; use the toggle to see how Nygard, MADR, Y-Statement, or an ISO-42010–inspired field list presents the same tradeoffs.

When this type of decision shows up

  • You need enterprise SSO and recovery flows and cannot fund a full in-house security team for auth surface area.
  • Compliance and legal need clear data residency, subprocessors, and incident responsibilities spelled out in contracts.
  • You will still own token validation, key rotation, and service-to-service identity in a follow-up ADR or platform guide.

Format

Preview

Use a managed authentication provider

Architecture description record (ISO/IEC/IEEE 42010–inspired). Lightweight, Git-friendly fields. Not a full conformance report to the standard—use the vocabulary of stakeholders, concerns, and views to align the decision with the architecture description.

Record ID (cross-ref): ADR-42010-0030

System / subject scope

Customer-facing app, backend services validating tokens, external IdP for user identity.

Stakeholders and roles

Product engineering, security, DPO/legal, enterprise IT for SSO.

Stakeholder concerns (to be addressed in the architecture description)

Account security, availability of login, compliance with residency and processor rules, time-to-delivery.

View and viewpoint (what is shown, and from which perspective)

Viewpoint: security / identity. View: where tokens are minted, how apps validate them, and what we outsource.

Decision

Use a managed provider for end-user auth; app code validates standards-based tokens. Legal signs off on terms and data flow.

Rationale (with respect to the concerns and alternatives)

Concerns: security and speed to baseline controls. A managed service addresses threats we would otherwise underfund; architecture description must still show our validation layer and data boundaries.

Architectural impact (elements, relationships, and operational follow-through)

Token validation library standardization; key rotation; incident response split with vendor.

Traceability (requirements, policy, SLOs, other ADRs)

Security review record; DPA and subprocessors on file; follow-up ADR for service-to-service auth.