On this page
  1. What defines a type of authentication
  2. Passwords: The default with the widest attack surface
  3. One-time codes: Proof of a second thing
  4. Magic links: Authentication by inbox control
  5. Passkeys and WebAuthn: Credentials bound to your domain
  6. Federated sign-in: Someone else authenticates
  7. Enterprise SSO: The customer’s identity provider
  8. Client certificates and mTLS: Mutual proof
  9. API keys and service accounts: Authenticating machines
  10. Combining them: The realistic stacks
  11. Where AI assistants get this wrong
  12. Checklist
  13. FAQ
    1. How many types of authentication are there?
    2. What is the difference between MFA and 2FA?
    3. Is SMS two-factor authentication worth enabling?
    4. What is the difference between authentication and authorization?
  14. Related topics
  15. Sources
concept

What Are the Different Types of Authentication (and What Is Each One For)?

Passwords, one-time codes, passkeys, magic links, social sign-in, SSO, certificates, and API keys — how each authentication type works, what it's for, and where it's weak.

Information Securitybeginner12 min readUpdated 2026-09-12

Quick answer

  • A type of authentication is defined by what counts as evidence: something you know, have, or are.
  • Roughly eight families appear in production: passwords, one-time codes, magic links, passkeys, federated sign-in, enterprise SSO, client certificates, and API keys.
  • Strength comes from the evidence being hard to copy, phish, and replay — not from the number of steps in the login form.
  • Two factors must come from different categories. A password plus a security question is one factor asked twice.
  • Machines authenticate too, with API keys and service accounts, and those need scoping rather than MFA.
  • Each family below stands alone — read the one you’re considering and the ones beside it.

What defines a type of authentication

Authentication is the process of establishing that a caller is who they claim to be. A type of authentication is defined by the evidence it accepts, and that evidence falls into three categories:

  • Something you know — a password, a PIN, an answer to a question.
  • Something you have — a phone, a hardware key, a device holding a private key.
  • Something you are — a fingerprint, a face, a voice.

Everything below is built from those, and each family inherits the weaknesses of whichever one it relies on. Knowledge can be guessed and phished. Possession can be stolen, borrowed, or relayed. Biometrics can be copied in the narrow sense that a fingerprint is a fingerprint — which is why biometrics work as a local unlock for a stronger credential rather than as a standalone factor over a network.

Passwords: The default with the widest attack surface

A password is a shared secret the user types and you store hashed. It’s universal, it needs no hardware, and it’s the source of most account compromises in practice — through reuse, guessing, and phishing rather than through anyone breaking the hash.

Use when: you have no reason to adopt something else, and users expect a familiar login. Weakness: people reuse them, so a breach at another site becomes a breach at yours, which is the entire premise of credential stuffing.

One-time codes: Proof of a second thing

A one-time code is a short-lived value delivered somewhere the user controls — a TOTP app, an SMS message, or an email — and typed back to prove access to that channel. It is usually a second factor rather than the primary one, and the channel’s security is the method’s security.

Use when: you need a second factor with no hardware purchase, or a fallback when a stronger method is unavailable. Weakness: SMS codes can be relayed in real time by an attacker proxying the login, and phone numbers can be ported; email codes depend on the security of an inbox.

A magic link is a single-use URL emailed to the user; clicking it proves control of that inbox and signs them in. There is no password to choose, store, or forget.

Use when: onboarding friction matters more than the strength of the credential — newsletters, low-stakes accounts, invitations, or temporary access. Weakness: anyone with access to the inbox can sign in, links leak through email forwarding, shared mailboxes, and scanners that pre-fetch URLs, and the token must be single-use and short-lived to limit the damage.

Passkeys and WebAuthn: Credentials bound to your domain

A passkey is a key pair generated by the device. The private half never leaves the platform keystore; the public half is registered with you, and authentication is a signature challenge over your domain name. Because the credential is bound to your origin, a passkey entered on a lookalike domain simply won’t work — the browser won’t offer it.

Use when: you want sign-in that resists phishing by construction, or you want to remove passwords from new accounts. Weakness: recovery. Losing the device must not mean losing the account, and the recovery path is usually the weakest link once passkeys are in place.

Federated sign-in: Someone else authenticates

With OAuth and OpenID Connect, a provider authenticates the user and hands your app a token describing them. You never see a password, which removes password storage, reset flows, and MFA enrollment from your codebase.

Use when: consumer apps want fewer passwords, or you’d rather not own credential handling at all. Weakness: the token must be verified properly — signature, issuer, audience, expiry — and the identity it carries has to be mapped onto a local account, including what happens when the email changes.

Enterprise SSO: The customer’s identity provider

SAML and OIDC federation let a customer’s IT department authenticate their employees, with your app consuming the resulting assertion and issuing its own session. Access is granted and revoked centrally, which is why enterprises require it.

Use when: you sell to organizations and they ask how their people sign in. Weakness: attribute mapping is where mistakes happen — a mismapped group can grant an employee an administrative role, and a rotated certificate can break every login quietly.

Client certificates and mTLS: Mutual proof

In mutual TLS, both sides present certificates, so the client proves its identity as part of the connection rather than after it. There’s no password to phish and no token to replay.

Use when: service-to-service traffic inside a trusted boundary, device fleets you control, or high-assurance internal systems. Weakness: certificate distribution, renewal, and revocation are operational work, and it’s a poor fit for consumer users who can’t be asked to manage key material.

API keys and service accounts: Authenticating machines

A machine caller needs a credential too, and a user session is the wrong shape: no interactive login, no browser to hold a cookie. The options are a scoped API key, an OAuth client-credentials grant, or a signed request. Each is a non-human identity that needs an owner, a scope, an expiry, and rotation.

Use when: server-to-server integrations, scheduled jobs, agents, and third-party developers. Weakness: keys are long-lived secrets that end up in repositories, logs, and CI configuration, and a key with broad scope is an incident waiting for a place to happen.

Combining them: The realistic stacks

Four combinations cover most applications, and each is a deliberate trade:

  • Consumer web app: a password or a federated identity, plus a TOTP second factor, on a server-side session. Passkeys offered alongside as an upgrade.
  • B2B application: federated sign-in through the customer’s IdP for enterprise accounts, local credentials for smaller ones, and role mapping from the IdP’s groups.
  • Internal tool: SSO against the company directory, so deprovisioning an employee revokes access everywhere at once.
  • Machine-to-machine: scoped keys or client-credentials tokens, one per consumer, rotated on a schedule and stored outside the repository.

Where this bites vibecoders

The failure pattern isn’t choosing a weak method — it’s stacking steps and assuming that’s strength. An assistant asked to “make login more secure” will often add a security question, an email code, and a CAPTCHA, which is more friction without a second factor: all three are things the user knows or receives in a channel an attacker might also hold. The other common shape is a method adopted without its operational half — passkeys with no recovery design, federated sign-in where the token is decoded but its audience never checked, API keys that authenticate a service perfectly and are scoped to everything. Every one of these passes a demo. What catches them is asking about the factor category and the recovery path: what does the user have that an attacker doesn’t, and what happens when they lose it?

Where AI assistants get this wrong

  • Treating a security question as a second factor, when it’s the same category as a password.
  • Decoding a federated token without verifying its signature, issuer, audience, or expiry.
  • Adding SMS as the only second factor and calling the account phishing-resistant.
  • Building passkey support with no account-recovery path designed.
  • Issuing one API key with full access instead of per-consumer scoped credentials.
  • Storing session state in process memory, so every deploy signs everyone out.
  • Authenticating a machine caller with a user’s credentials copied into a config file.

Checklist

  • Name the factor category for every step in your login flow.
  • Require two factors from different categories for anything valuable.
  • Prefer an authenticator app or a passkey over SMS where you control the choice.
  • Verify federated tokens fully — signature, issuer, audience, expiry — before trusting them.
  • Design account recovery before you enable passkeys.
  • Give machines their own scoped credentials, never a borrowed user session.
  • Store sessions server-side so logout and revocation actually work.
  • Deprovision access from the identity source when using SSO.

FAQ

How many types of authentication are there?

Three factors — something you know, something you have, something you are — and about eight families of method built on them: passwords, one-time codes, magic links, passkeys, federated sign-in, enterprise SSO, client certificates, and API keys. The families differ in what counts as evidence, which determines how easily the evidence can be copied, phished, or replayed.

What is the difference between MFA and 2FA?

Two-factor authentication means exactly two factors from different categories, most commonly a password plus a code. Multi-factor authentication means two or more, and can include a passkey plus a device check. The label matters less than the requirement: factors must come from different categories, because a password plus a security question is still one factor asked twice.

Is SMS two-factor authentication worth enabling?

Yes, if the alternative is single-factor passwords. It blocks automated credential stuffing and most bulk attacks. It is not phishing-resistant — a code can be relayed by an attacker in real time, and phone numbers can be ported — so use it as a step up from passwords, and prefer an authenticator app or a passkey where you control the choice.

What is the difference between authentication and authorization?

Authentication establishes who a caller is; authorization decides what that caller may do. They fail differently: an authentication bug locks people out, while an authorization bug quietly shows one user another user’s data. Most serious flaws in generated applications are authorization bugs in code that authenticates correctly.

Sources

Share: