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

ADR-0030: Use a managed authentication provider

Status

Accepted

Context

The team is small. We need secure login, MFA, password reset, OAuth for enterprise, and auditable sessions. In-house auth would compete with product work and still risks subtle security mistakes.

Decision

Adopt a managed authentication provider for interactive login and token issuance. App services validate access tokens. Credential storage and many OAuth footguns stay with the provider. Legal reviews data residency and subprocessors before we lock a vendor contract.

Consequences

Positive: faster path to MFA and federation; less custom crypto. Negative: vendor cost, less flexibility for exotic flows, subprocessors in compliance scope. Follow-up: platform ADR for token validation, key rotation, and service-to-service identity.