adr.zone

ADR Example: Managed authentication (IdP) vs in-house (MADR 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

  • Status: proposed
  • Deciders: <team or role>
  • Technical story: <issue link> · Date: <YYYY-MM-DD>

Context and Problem Statement

We need production-grade user login and enterprise OAuth without a dedicated internal auth team. Building the full surface in-house is a security and opportunity-cost risk.

Decision Drivers

  • Time to secure defaults (MFA, recovery, OAuth)
  • Small engineering headcount
  • Audit and subprocessors handled professionally

Considered Options

  • In-house stack — full control; high long-term cost and risk
  • Managed IdP — faster; vendor dependency

Decision Outcome

Adopt a managed IdP for interactive users; services consume verified tokens. Vendor choice gated by DPO/legal.

Consequences

  • Shorter time to auditable auth
  • Ongoing cost and contract dependency
  • Glue for odd enterprise IdP still possible

Pros and Cons of the Options (summary)

Managed wins for this team now; con is long-term price and less bespoke UX control.

Confirmation

Security + DPO; procurement path recorded.