Start with the door check
Do not start by memorizing every security term. Start with a person standing at a secure door. They say, 'I am allowed in.' The system now has three questions: what proof did they show, is that proof real, and what are they allowed to do after it checks out?
That is the whole map. A credential is the proof you present. Authentication is the check. Authorization is the boundary around what you can access. The rest of the article keeps returning to that door-check story while the examples get stronger.
Passwords, passkeys, private keys, certificates, tokens, device identity, and attestation are not random vocabulary. They are different ways to answer one practical question: why should this system trust this person, device, or request right now?
A credential is proof behind a claim
Picture a secure lab door. You say, 'I am MY,' or 'I should be allowed into this lab.' A good guard should not accept that statement by itself. The guard asks for proof.
That proof is the credential. It may be a password, employee badge, phone passkey, security key, digital certificate, identity file, or device credential inside a chip. The object changes, but the purpose stays the same: it supports a claim.
A credential is not the final answer. It is evidence the system can check. The system still has to decide whether the evidence is genuine, whether it belongs to the right person or device, and whether the requested access should be granted.
Credential, authentication, and authorization are three steps
These three words are often mixed together, so the amusement-park gate is a useful picture. The ticket or pass is the credential. Scanning it is authentication. Deciding which areas you can enter is authorization.
Passing authentication does not mean 'all access.' A valid employee badge may let you enter Lab A, view data, or use a tool, but it should not automatically open the VIP room or the admin console.
Good systems keep the steps separate. First ask what proof was presented. Then check whether it is real. Only after that should the system decide the allowed scope.
Shared secrets are easy to use and easy to lose
The simplest method is to reveal a secret. Passwords, PINs, pre-shared keys, and many API keys use this idea: if you know the secret, the system treats you as the right party.
The risk is also simple. If someone hears the secret, records it, steals it from a log, phishes it, or finds it in a leaked database, they may be able to act as you. A shared secret works only as long as it stays secret.
This is why reusable secrets are fragile for important systems. They are convenient, but every time they are typed, transmitted, stored, or compared, they create another chance to leak.
Challenge-response proves the secret without sending it
Challenge-response is a safer pattern. Instead of asking you to send the secret, the system sends a fresh challenge. Your device uses its secret to compute a response, and the server checks whether that response is correct.
Because the challenge changes each time, an old response should not work again. If an attacker records one successful login, that recording will not match the next challenge. That is the basic defense against replay attacks.
The system is no longer listening for your secret. It is checking whether you can produce the right answer for this specific challenge, at this specific time, for this specific exchange.
A password and a real cryptographic key are not the same
A password is made for humans. It is usually short enough to remember, so it may follow patterns, get reused, or appear in guessing dictionaries. A cryptographic key is made for machines. It should be long, random, and hard to predict.
A key derivation function, or KDF, can make password storage much safer by combining the password with a salt and doing work that slows down guessing. That is much better than storing a raw password.
But a KDF cannot perform magic. If the original password is weak, attackers can still try guesses offline until one works. For high-value systems, a true random key or hardware-backed private key is a stronger foundation than a human-memorable secret.
Keep the private key and send a signature
Asymmetric authentication uses a simple rule: the private key stays with you, and the public key can be shared. When the server sends a fresh challenge, your device signs it locally with the private key.
The server verifies the signature with the public key. It does not need to know, store, or receive your private key. If the signature checks out, the server knows the matching private key produced it.
This is why passkeys, hardware security keys, and device keys can be much safer than reusable passwords. A signature is proof made by the secret, not the secret itself.
A certificate says who a public key belongs to
A public key can verify a signature, but a bare public key does not tell you whose key it is. A certificate fills that gap by binding identity information, a public key, allowed uses, validity dates, and an issuer's signature.
That issuer is often a certificate authority, or CA. The CA is saying, in effect, 'I checked this identity, and this public key belongs to it.' The verifier can then trust the binding if it trusts the issuer and the certificate is still valid.
This is the basic idea behind HTTPS certificates, device certificates, and code-signing certificates. The key proves the signature. The certificate tells you who the key represents.
A token is a short-term ticket after authentication
A token usually appears after a stronger proof has already been checked. You first authenticate with a password, passkey, certificate, or other credential. Then the system issues a token that can temporarily act for you.
That token is useful because it can be short-lived and limited in scope. It may let you use one service for a few minutes, but not enter the admin room or use every API in the system.
The danger is that many tokens are bearer tokens: whoever holds the token can use it. That is why tokens need HTTPS, careful storage, expiration, rotation, revocation, and least-privilege scope.
Where the credential lives changes the risk
Security is not only about which algorithm you use. It also depends on where the secret lives. A key in a normal file is convenient, but weak permissions, malware, backups, or logs may expose it.
OTP and eFuse can hold fixed root data. Secure elements, TPMs, and HSMs try to keep keys and cryptographic operations inside a protected boundary. A PUF can derive a root key from device-specific physical behavior instead of simply storing the full key as static data.
When reviewing a credential design, ask practical storage questions: where is the key generated, can it be exported, where is it used, who can copy it, how is it rotated, and what happens if the device is lost or compromised?
Device identity gives every device its own name
People need identity, and devices do too. Device identity answers a basic question: which exact device is this? A good design often combines a unique device ID, a device key, and a device certificate.
If thousands of devices share the same secret, one broken device can put the whole fleet at risk. Each device should have its own credential so it can be recognized, traced, rotated, or revoked independently.
This matters for IoT, secure accessories, industrial systems, automotive electronics, and edge devices. A service may need to know not only which user logged in, but which device is making the request.
Attestation checks whether the device is trustworthy now
Device identity says, 'This is the real device.' Attestation asks a second question: 'Is this real device in a trustworthy state right now?' Those are not the same thing.
A genuine device may still be risky if its firmware was modified, debug mode is open, the secure-boot chain is broken, or the security version was rolled back. Attestation packages evidence about that current state so a verifier can make a trust decision.
Useful attestation evidence can include firmware measurements, secure-boot state, security version, debug state, configuration values, error counters, and health information. Strong systems check both identity and state before granting sensitive access.
A PUF can support the credential, but it is not the credential itself
A PUF is best understood as a hardware foundation. It uses chip-specific physical behavior to help reconstruct or protect a root key. That root key can then support device credentials, authentication, and attestation.
The system usually does not trust the PUF directly. It trusts a credential or proof built from it: a device key, a certificate, a signature, or attestation evidence. The PUF sits behind the scenes and makes the root secret harder to copy or steal.
The final lesson is practical. A credential proves a claim only when it is well protected, fresh enough, limited in scope, and tied to the right identity and state. Small credentials can protect large systems, but only when their lifecycle is designed carefully.
References
- NIST SP 800-63B: Authentication and Authenticator Management: Digital identity guidance for authenticators, lifecycle management, replay resistance, and phishing-resistant authentication.
- OWASP Authentication Cheat Sheet: Practical web-application guidance for authentication, password handling, MFA, and credential recovery.
- OWASP Session Management Cheat Sheet: Practical guidance on session identifiers, cookies, expiration, renewal, and session fixation risks.
- RFC 6749: The OAuth 2.0 Authorization Framework: Foundation for delegated authorization and access-token based flows.
- RFC 6750: Bearer Token Usage: Defines bearer-token usage and the risk that possession of the token is enough to use it.
- RFC 7519: JSON Web Token (JWT): Reference for JWT claims, signing, and compact token representation.
- RFC 5280: X.509 Public Key Infrastructure Certificate Profile: Reference for certificate fields, public-key binding, validity, and certificate path validation.
- W3C WebAuthn Level 3: Standard API for public-key credentials used by passkeys and hardware-backed authentication.
- FIDO Alliance: Passkeys: Industry explanation of passkeys and FIDO public-key authentication.
- RFC 9334: RATS Architecture: Architecture for remote attestation, evidence, endorsements, verifiers, and relying parties.