Authentication & Access · Study deck
Authentication Methods for IoT
Carry the chapter's decisions forward in order.
Shield Shelly is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: JWT Structure and Algorithm Pitfalls A JWT has three base64url parts joined by dots: a header naming the algorithm and type, a payload of claims, and a signature over the header and payload.
- Explain: The device must hold three things: the CA certificate it trusts, its own device certificate, and its private key — which belongs in a secure element so it cannot be extracted.
- Explain: A salt is a unique random value per user that is mixed into the hash, so identical passwords produce different stored hashes and precomputed rainbow tables become useless.
Major section
Start With Who Is Signing In
Reusing one login pattern for both can turn one stolen secret into a fleet-wide failure.
- Multi-factor authentication means requiring independent kinds of proof from a person.
- An API means a named software entry point used by another program.
- A gateway is the device or service that joins two system paths.
Major section
Start With Who Is Signing In (continued)
TLS means protected transport that checks the service identity and can also check the client.
- A connected device is not yet a trusted device.
- This runway does not make one method best for every actor.
- The engineering question is which proof fits that actor and threat.
- Passwords are the simplest and the most attacked.
Major section
Start With Who Is Signing In (continued)
Certificates with mutual TLS are the gold standard for unattended devices, giving each unit a unique cryptographic identity.
- Tokens such as JWT carry the result of a prior authentication so an API does not re-check a password on every call.
- The Core Idea Certificates for devices Unattended devices cannot type passwords or codes.
- A reviewer needs to know it is a salted, deliberately slow hash, not a single fast digest.
Major section
Build the Method Around Risk
Selecting an authentication method is a risk decision, not just a technical one.
- A low-severity flaw on an internet-facing controller can outrank a high-severity flaw on an isolated bench device.
- The output is a method matched to the asset's real exposure.
- Higher; needs a CA, issuance, and revocation.
Major section
Build the Method Around Risk (continued)
Immune; there is no reusable shared secret.
- Constrained devices need room for a key in secure hardware.
- The header names the signing method, the payload carries readable claims, and the signature detects alteration.
- Critically, a JWT payload is not encrypted: it is base64url-encoded and fully readable, with the signature providing tamper-evidence, not confidentiality.
Major section
Under the Hood: What Each Method Proves
Current guidance (OWASP, RFC 9106) favors Argon2id, a memory-hard function; bcrypt, scrypt, and PBKDF2 with a high iteration count are acceptable alternatives.
- The deeper layer explains how each method actually authenticates and why each fails in a specific way.
- The result is a mutually authenticated, encrypted channel.
- The token is authentic and still valid.
Major section
Under the Hood: What Each Method Proves (continued)
A salt is a unique random value per user that is mixed into the hash, so identical passwords produce different stored hashes and precomputed rainbow tables become useless.
- Typical Argon2id parameters might be a few iterations over tens of megabytes of memory with modest parallelism, tuned so a single verification takes a fraction of a second.
- The verifier must decide the algorithm, not the token.
- The client truly holds its certificate's private key.
Major section
Under the Hood: What Each Method Proves (continued)
Because verification only needs the signing key, a server can validate a token without storing session state — the convenience of statelessness.
- An optional pepper — a secret kept separately from the database — adds defense if the hash store alone is stolen.
- The client then presents its device certificate and proves it holds the matching private key by signing a value in the handshake (the CertificateVerify step).
- Accepting a presented cert without the signature enables forgery.
Major section
Under the Hood: What Each Method Proves (continued)
A password alone offers no defense against an attacker who already holds a valid pair.
- The device must hold three things: the CA certificate it trusts, its own device certificate, and its private key — which belongs in a secure element so it cannot be extracted.
- JWT Structure and Algorithm Pitfalls A JWT has three base64url parts joined by dots: a header naming the algorithm and type, a payload of claims, and a signature over the header and payload.
- A trustworthy review names the method, its evidence, and the specific way it would break.
Deck summary
Key takeaways
Reusing one login pattern for both can turn one stolen secret into a fleet-wide failure.
- TLS means protected transport that checks the service identity and can also check the client.
- Certificates with mutual TLS are the gold standard for unattended devices, giving each unit a unique cryptographic identity.
- Selecting an authentication method is a risk decision, not just a technical one.
- Immune; there is no reusable shared secret.
Retrieval practice
Recall check 1 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q1You must authenticate ten thousand headless field sensors to a cloud service, with no human present at any device. Which method fits best?
Show answer
Answer: A Certificates give each device its own identity and support mutual TLS and per-device revocation, which suits large unattended fleets.
Retrieval practice
Recall check 2 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q2A developer proposes embedding each device's long-lived API secret inside the JWT payload so the backend can read it on every request. Why is this unsafe?
Show answer
Answer: C Tokens are readable by design.
Retrieval practice
Recall check 3 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q3During a mutual-TLS handshake, what specifically proves that the client legitimately owns the certificate it presented?
Show answer
Answer: D Certificates are public, so presenting one proves nothing.
Print reference
Answers
Answer key.
- A · Certificates give each device its own identity and support mutual TLS and per-device revocation, which suits large unattended fleets.
- C · Tokens are readable by design.
- D · Certificates are public, so presenting one proves nothing.