adr.zone

ADR Example: Managed authentication (IdP) vs in-house (ISO 42010 Companion 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, Outcome-First, or ISO 42010 Companion 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

ISO 42010 Companion — an architecture decision companion using ISO/IEC/IEEE 42010 vocabulary. Not a standard ADR format or conformity template—use it to connect stakeholders, concerns, views, and traceability to a related decision.

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.