Principals & Credentials
The entities that act, and the secrets that prove who they are.
By the end of this lesson, distinguish principals from credentials and reason about credential strength.
A principal is something that can act: a user, a service, a device, an agent. A credential is what a principal uses to prove it is that principal. Passwords, API keys, private keys, and passkeys are all credentials — they differ mainly in how hard they are to steal and replay.
Credential strength, roughly
- From weakest to strongest: passwords, API keys, one-time codes, asymmetric keys/passkeys, hardware-bound keys.
flowchart TB a["Password (shared secret)"] --> b["API key (long-lived secret)"] b --> c["TOTP / OTP (time-bound)"] c --> d["Private key / passkey (asymmetric)"] d --> e["Hardware-bound key (non-exportable)"]
The critical property is whether a credential is a shared secret (both sides know it, so either side leaking it is fatal) or asymmetric (the prover holds a private key and never transmits it). Passwords and API keys are shared secrets. Passkeys (WebAuthn) use asymmetric keys — the server only ever sees a public key, so a server breach cannot leak a usable credential.
This is where the abstraction starts leaking.
'The API key is in an environment variable' is where most breaches start. Shared secrets sprawl into logs, git history, CI, and screenshots. Asymmetric and hardware-bound credentials exist precisely because humans cannot keep shared secrets.
Credential replay
- Trigger
- A shared-secret credential (password, API key, bearer token) is captured in transit or at rest.
- Symptom
- An attacker authenticates as the principal with no further compromise needed.
- Blast radius
- Everything the principal can do, until the credential is rotated.
- Mitigation
- Prefer asymmetric/proof-of-possession credentials; scope and short-live secrets; rotate on exposure.
Deep dive: Token Replay
Stronger credentials cost operational effort: passkeys need enrollment and recovery flows; private keys need distribution and rotation. The right level depends on blast radius — a read-only public API can tolerate an API key; a payment service should not.
Why is a passkey safer than a password even against a database breach?
The server stores only a public key. There is no shared secret to steal — the private key never leaves the user's device.