{
  "_meta": {
    "schema": "https://www.drawdecisiontree.com/decision-dag.schema.json",
    "source": "https://www.drawdecisiontree.com",
    "description": "DrawDecisionTree.com is a free tool for building, sharing, and embedding interactive decision trees. This file is the machine-readable export of a published decision tree. The `dsl` field contains the original source in the Decision DAG DSL; the `dag` schema is documented at the URL in `schema` above.",
    "links": {
      "interactive": "https://www.drawdecisiontree.com/t/drawdecisiontree/auth-method.html",
      "embed": "https://www.drawdecisiontree.com/embed/path/drawdecisiontree/auth-method",
      "dsl_reference": "https://www.drawdecisiontree.com/decision-tree-dsl-reference.html",
      "guides": "https://www.drawdecisiontree.com/guides",
      "schema_docs": "https://www.drawdecisiontree.com/decision-dag.schema.json",
      "author_trees": "https://www.drawdecisiontree.com/trees/drawdecisiontree"
    },
    "generated_at": "2026-05-29T12:05:39.251Z"
  },
  "author": {
    "handle": "drawdecisiontree",
    "first_name": "Andrew",
    "last_name": null,
    "avatar_url": "1d32d828-b6ca-40ec-bdd7-771fe7b9c36a/avatar-1778531481027.svg",
    "display_name": "Andrew"
  },
  "file": {
    "id": "710e4e4a-936f-4201-86c7-37c28467362f",
    "name": "Authentication Method Selection",
    "public_slug": "auth-method",
    "updated_at": "2026-05-12T16:53:43.587978+00:00",
    "url": "https://www.drawdecisiontree.com/t/drawdecisiontree/auth-method.html",
    "json_url": "https://www.drawdecisiontree.com/t/drawdecisiontree/auth-method/tree.json",
    "dsl_url": "https://www.drawdecisiontree.com/t/drawdecisiontree/auth-method/tree.dag"
  },
  "meta": {
    "description": "Authentication is a security-critical, high-friction decision to reverse — migrating users from one auth method to another requires coordinated password resets or credential migration campaigns. This tree eliminates methods that don't match your user type, enterprise requirements, and security posture, giving you a clear shortlist before you write a line of code.",
    "mode": "elimination",
    "entry": "Q1",
    "tags": [
      "security",
      "authentication",
      "identity",
      "backend",
      "architecture"
    ],
    "image": "https://images.unsplash.com/photo-1614064641938-3bbee52942c7?w=1200&q=80"
  },
  "questions": [
    {
      "id": "Q1",
      "text": "Do your enterprise customers require Single Sign-On through their corporate identity provider (Okta, Azure AD, Active Directory, Google Workspace)?"
    },
    {
      "id": "A",
      "text": "YES — enterprise SSO is a requirement or near-term roadmap item [SAML, OAUTH]"
    },
    {
      "id": "B",
      "text": "NO — individual consumer sign-up or internal tooling only [OAUTH, MAGIC-LINK, PASSKEY, BASIC, API-KEY]"
    },
    {
      "id": "Q2",
      "text": "Is the primary user a machine, service, or automated script rather than a human?"
    },
    {
      "id": "A",
      "text": "YES — machine or service authenticating programmatically [API-KEY]"
    },
    {
      "id": "B",
      "text": "NO — human users [OAUTH, MAGIC-LINK, PASSKEY, BASIC]"
    },
    {
      "id": "Q3",
      "text": "Is eliminating passwords entirely a security or user experience priority?"
    },
    {
      "id": "A",
      "text": "YES — we want to eliminate passwords for security or UX reasons [MAGIC-LINK, PASSKEY, OAUTH]"
    },
    {
      "id": "B",
      "text": "NO — password-based login is acceptable for our user base [BASIC, OAUTH]"
    },
    {
      "id": "Q4",
      "text": "Do your target users reliably have devices with biometric authenticators — Touch ID, Face ID, or Windows Hello?"
    },
    {
      "id": "A",
      "text": "YES — target users are on modern personal devices with biometrics [PASSKEY, OAUTH]"
    },
    {
      "id": "B",
      "text": "NO — must work on shared, older, or any device [MAGIC-LINK, OAUTH]"
    }
  ],
  "outcomes": [
    {
      "id": "OAUTH",
      "label": "OAuth 2.0 / OIDC (Social Login)"
    },
    {
      "id": "SAML",
      "label": "SAML 2.0 (Enterprise SSO)"
    },
    {
      "id": "PASSKEY",
      "label": "Passkeys (WebAuthn / FIDO2)"
    },
    {
      "id": "BASIC",
      "label": "Username and Password"
    }
  ],
  "dsl": "dag: Authentication Method Selection\nversion: 1.0.0\nimage: https://images.unsplash.com/photo-1614064641938-3bbee52942c7?w=1200&q=80\ndescription: Authentication is a security-critical, high-friction decision to reverse — migrating users from one auth method to another requires coordinated password resets or credential migration campaigns. This tree eliminates methods that don't match your user type, enterprise requirements, and security posture, giving you a clear shortlist before you write a line of code.\ntags: security, authentication, identity, backend, architecture\nentry: Q1\nmode: elimination\n\nQ1: Do your enterprise customers require Single Sign-On through their corporate identity provider (Okta, Azure AD, Active Directory, Google Workspace)?\n  hint: Enterprise B2B SaaS products almost always need SAML or OIDC SSO eventually — it is commonly a procurement blocker. If even one enterprise customer or prospect has asked for SSO, include it in your initial design rather than bolting it on later.\n  A: YES — enterprise SSO is a requirement or near-term roadmap item [SAML, OAUTH]\n  B: NO — individual consumer sign-up or internal tooling only [OAUTH, MAGIC-LINK, PASSKEY, BASIC, API-KEY]\n\nQ2: Is the primary user a machine, service, or automated script rather than a human?\n  when: Q1=B\n  hint: Machine-to-machine authentication — background jobs, CI/CD pipelines, microservices calling internal APIs, third-party integrations — belongs in a separate auth category. API keys are simpler to issue, rotate, and audit for non-human callers than any human-oriented flow.\n  A: YES — machine or service authenticating programmatically [API-KEY]\n  B: NO — human users [OAUTH, MAGIC-LINK, PASSKEY, BASIC]\n\nQ3: Is eliminating passwords entirely a security or user experience priority?\n  when: Q2=B\n  hint: Passwords are the root cause of the majority of account breaches — credential stuffing, phishing, and password reuse attacks all exploit password-based authentication. Passwordless methods (passkeys, magic links, social OAuth) eliminate these attack vectors entirely at the cost of a slightly different user experience.\n  A: YES — we want to eliminate passwords for security or UX reasons [MAGIC-LINK, PASSKEY, OAUTH]\n  B: NO — password-based login is acceptable for our user base [BASIC, OAUTH]\n\nQ4: Do your target users reliably have devices with biometric authenticators — Touch ID, Face ID, or Windows Hello?\n  when: Q3=A\n  hint: Passkeys (WebAuthn/FIDO2) require an authenticator — either a device biometric sensor or a hardware security key (YubiKey). Browser and OS support has reached mainstream coverage (Chrome, Safari, Firefox, iOS 16+, Android 9+, Windows 10+), but users on older or shared devices may not have a biometric option available. Magic links work on any device with email access.\n  A: YES — target users are on modern personal devices with biometrics [PASSKEY, OAUTH]\n  B: NO — must work on shared, older, or any device [MAGIC-LINK, OAUTH]\n\n[OAUTH]: OAuth 2.0 / OIDC (Social Login)\n  color: #4285F4\n  description: OAuth 2.0 and OpenID Connect (OIDC) allow users to authenticate with an identity they already have — Google, Apple, GitHub, Microsoft, or any OIDC-compliant provider — without creating a new password. From a security perspective, this delegates credential storage and breach response to the identity provider; if Google's password is compromised, that's Google's problem, not yours. Social login dramatically reduces sign-up friction for consumer apps and eliminates the need to build and secure a credential database. OIDC also serves as the foundation for federated enterprise SSO when combined with an identity provider like Okta or Auth0. The trade-off: users are dependent on their chosen provider account remaining accessible, and some users (particularly in enterprise or sensitive contexts) are reluctant to link accounts across services. Implement at least two providers (e.g. Google + email) to avoid single-provider lock-in.\n  code: AUTH_OAUTH\n\n[SAML]: SAML 2.0 (Enterprise SSO)\n  color: #FF6600\n  description: SAML 2.0 is the enterprise standard for Single Sign-On — it enables your application to accept authentication from a corporate identity provider (Okta, Azure AD, OneLogin, ADFS) without managing user credentials directly. When an enterprise customer configures SAML, their users log in once to their company SSO portal and are automatically authenticated into your product without a separate password. This is a standard procurement requirement for mid-market and enterprise B2B SaaS — many security teams will not approve a software purchase without SSO. SAML is XML-based and its configuration (metadata exchange, entity IDs, assertion consumer service URLs, certificate management) is significantly more complex than OAuth to implement from scratch. Use a library (passport-saml, python3-saml, OneLogin's SDKs) or an auth platform (Auth0, WorkOS, Okta) rather than implementing the protocol directly. OIDC is a more modern alternative where both parties support it.\n  code: AUTH_SAML\n\n[API-KEY]: API Keys\n  color: #6C757D\n  description: API keys are the standard authentication mechanism for machine-to-machine communication — background jobs, webhooks, CI/CD pipelines, server-side integrations, and third-party developer access. A key is a long, randomly generated token presented in an HTTP header (`Authorization: Bearer <key>` or a custom header), validated server-side on each request. API keys are simple to issue, simple to rotate, and simple to revoke. Scope keys to the minimum required permissions and enforce key rotation through your developer portal. The primary risks are accidental exposure in source code (use environment variables, never hardcode keys) and lack of granular permissions in naive implementations. For higher-assurance machine-to-machine auth — particularly between internal services — consider short-lived tokens via OAuth Client Credentials flow instead, which eliminates the long-lived secret problem.\n  code: AUTH_API_KEY\n\n[MAGIC-LINK]: Magic Links (Passwordless Email)\n  color: #00B4D8\n  description: Magic links send a one-time sign-in URL to the user's email address — clicking the link authenticates them without ever entering a password. The security model ties account access to email inbox possession, which is a reasonable assumption for most consumer applications (email is already a recovery mechanism in most password-based systems). Magic links eliminate the credential storage problem entirely, are phishing-resistant (the link is single-use and expires quickly), and provide a frictionless sign-up experience with zero password management overhead. The user experience trade-off is the round-trip to email — on mobile with Gmail or Apple Mail, this is usually a few seconds; on shared or slow devices it can disrupt flow. Set a short expiry (15 minutes), single-use enforcement, and deliver links over HTTPS only. Magic links work best for apps where sign-in frequency is low (users stay logged in for extended sessions) or where email is already central to the workflow.\n  code: AUTH_MAGIC_LINK\n\n[PASSKEY]: Passkeys (WebAuthn / FIDO2)\n  color: #7B2FBE\n  description: Passkeys are cryptographic credentials stored on the user's device — a private key secured by the device's biometric authenticator (Touch ID, Face ID, Windows Hello) and a corresponding public key registered with your service. Sign-in requires the user to verify their identity with a biometric or device PIN; the device cryptographically signs a challenge without sending any secret over the network. Passkeys are fully phishing-resistant (the key is domain-bound and cannot be used on a lookalike site), eliminate password databases entirely, and provide an extremely low-friction sign-in experience on supported devices. The WebAuthn spec has broad browser support as of 2023 (Chrome, Safari, Firefox, Edge), and passkeys can sync across a user's devices via iCloud Keychain or Google Password Manager. The implementation complexity is moderate — use a well-tested WebAuthn library rather than implementing the CBOR and assertion verification from scratch. Passkeys are the long-term direction of consumer authentication and represent a meaningful security improvement over any password-based alternative.\n  code: AUTH_PASSKEY\n\n[BASIC]: Username and Password\n  color: #868E96\n  description: Username and password is the most familiar authentication pattern and the most straightforward to implement, but it carries the highest ongoing security maintenance burden. You become responsible for securely hashing credentials (use bcrypt, scrypt, or Argon2 — never MD5, SHA-1, or SHA-256 alone), enforcing minimum password complexity, protecting against credential stuffing attacks (rate limiting, CAPTCHA, breach-database lookups via HaveIBeenPwned), and providing a secure password reset flow. Users reliably reuse passwords across services, which means a breach at any other site is a potential attack vector against your accounts. Username/password is appropriate for internal tooling, admin panels, or applications where your user base is small and controlled, and where the overhead of a third-party identity provider isn't justified. For anything consumer-facing at scale, pair it with MFA and invest in breach detection from the start.\n  code: AUTH_BASIC\n"
}