Skip to content

PATTERN Cited by 1 source

Phishing-resistant MFA behind IdP

Pattern

Every internal application is a downstream relying party of a single identity provider (IdP). The IdP — and only the IdP — enforces phishing-resistant MFA (FIDO2/WebAuthn/Passkeys). No application enforces its own MFA, because every application trusts the IdP's assertion that the user cleared MFA at the IdP.

This is the discipline Fly.io canonicalises in their 2025-10-08 postmortem:

"This is, in fact, how all of our infrastructure is secured at Fly.io; specifically, we get everything behind an IdP (in our case: Google's) and have it require phishing-proof MFA. You're unlikely to phish your way to viewing logs here, or to refunding a customer bill at Stripe, or to viewing infra metrics, because all these things require an SSO login through Google." (Source: sources/2025-10-08-flyio-kurt-got-got)

Why it works

  • N × 1, not N × M. With N apps and M authentication methods per app, the integration surface is N×M. With one IdP that federates to all N apps, it's N×1. Security review scales.
  • Single chokepoint for MFA enforcement. Upgrade one thing (e.g. require Passkeys at the Google Workspace level) and all downstream apps inherit the new policy.
  • Single chokepoint for off-boarding. Disable the user at the IdP, they're out of everything.
  • Single chokepoint for audit and session revocation. One session log, one revocation API.
  • Phishing-resistance property propagates. The IdP's origin-bound credential (concepts/origin-bound-credential) is what the attacker would have to phish. Downstream apps only ever see federated tokens, not passwords.

Structure

User ──Passkey/FIDO2──→ IdP (Google Workspace / Okta / Entra)
                         │
                         │  SAML / OIDC assertion
                         ▼
                    ┌────┴────┬─────────┬─────────┐
                    ▼         ▼         ▼         ▼
                 Logs      Stripe    Infra    Everything
                 portal    admin     metrics  else

Every downstream surface — internal tooling, third-party SaaS, cloud console — is fronted by SSO. The user's authentication ritual happens once, against the IdP, using a phishing-resistant factor. Every subsequent app-to-app navigation is silent.

The coverage-gap failure mode

The pattern's guarantee is "whatever's behind the IdP is safe" — which implies whatever's not behind the IdP is not. The generalisable failure mode is a legacy shared account on a platform that doesn't federate (or where federation wasn't worth the effort because the platform was deprioritised).

Fly.io's canonical instance: their Twitter account sat outside the IdP regime because it was a deprioritised social presence shared with an external contractor. The Fly.io infrastructure — logs, Stripe, infra metrics — was unaffected when Kurt was phished; the Twitter account (the one thing outside the regime) was the one thing lost.

"Whatever you're operating that isn't behind phishing- resistant MFA, or, better yet, an SSO IdP that requires phishing-resistant MFA: that thing is eventually going to get phished." (Source: sources/2025-10-08-flyio-kurt-got-got)

When it fits

  • Employee-facing internal apps — almost universal fit. Internal tooling, cloud consoles, SaaS, metrics dashboards, billing admin. Ship SAML or OIDC and the IdP does the work.
  • Mid-size orgs and above — the IdP cost is amortised across many apps.
  • Regulated environments — SOC 2, ISO 27001, HIPAA explicitly reward the centralised-MFA-enforcement architecture.

When it doesn't fit

  • Customer-facing authentication. Your customers aren't on your IdP. They need passkeys on your product directly (see Cloudflare EmDash, sources/2026-04-01-cloudflare-emdash-wordpress-spiritual-successor).
  • Platforms that don't offer SSO at your plan tier. Social media, many B2C SaaS products, and small vendor tools often charge a premium for SSO — the "SSO tax". These become de-facto legacy shared accounts.
  • Emergency break-glass accounts. You need a non-IdP- dependent path in if the IdP is the thing that's down.

Composition

Anti-patterns

  • Per-app MFA re-enforcement. Every app forces its own TOTP, the IdP assertion is ignored. Defeats the single-chokepoint property; user gets MFA fatigue and re-uses weak factors.
  • Password + TOTP at the IdP. The IdP is the one thing that must be phishing-resistant. If the IdP is phishable, the whole tree is phishable.
  • "We'll move it behind SSO eventually" for accounts that don't support SSO at your tier. Pragmatic but must be tracked — otherwise you're running legacy shared accounts by accident, not by policy.

Seen in

  • Fly.io Kurt Got Got (2025-10-08) — canonical wiki instance. Google Workspace as IdP; every internal surface (logs, Stripe admin, infra metrics) is a downstream federated app; phishing-proof MFA (Passkeys/FIDO2) enforced at the Google layer; only legacy-social-account the Twitter/X credential lived outside the regime (sources/2025-10-08-flyio-kurt-got-got).
  • Yelp ZTA (2025-04-15) — Okta as IdP; every corporate network access point federated; OIDC + device posture as the authorisation gate (sources/2025-04-15-yelp-journey-to-zero-trust-access).
  • Fly.io SOC 2 (prior) — the same regime, described under-the-hood (Fly.io's 2022 SOC 2 narrative).
Last updated · 517 distilled / 1,221 read