How does authenticating a person differ from authenticating a thing, machine or service?
For persons the key requirement is usability, so they use passwords, biometrics, OTPs and smartcards in interactive protocols and face mainly social attacks; for machines it is automation, so they use certificates, API keys and tokens in background protocols and face mainly technical attacks.
| Person | Thing / machine / service | |
|---|---|---|
| Main requirement | Usability (Benutzerfreundlichkeit) | Automation |
| Authentication means | Passwords, biometrics, OTP, smartcards | Certificates, API keys, tokens |
| Protocols | Interactive: OAuth, OpenID Connect, SAML, Kerberos | Automated, in the background: TLS, mutual TLS, token-based authentication |
| Main threats | Social attacks such as phishing or password theft, human mistakes | Technical attacks: exploiting software vulnerabilities, certificate theft, man-in-the-middle |
The differences follow from one fact: a machine has no memory, fingers or face, and nobody is there to type a code at 3 a.m. Its secret must be stored somewhere and used automatically, which makes protecting that stored secret (a private key or API key in a config file, a vault or an HSM) the central problem. A person, in turn, can be fooled, so human-facing authentication must resist phishing and mistakes while staying usable enough that people do not work around it.
Go deeper:
Mutual authentication (Wikipedia) — both sides authenticate each other, the typical pattern between machines.
RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication — how a service authenticates with a certificate instead of a shared secret.