Authentication & Access Control · Study deck

IoT Access Control: OAuth and Identity Lifecycle

A screen-free device cannot type a normal web password.

Shield Shelly is your guide for this deck.

access-controlrbacabac

Shield Shelly, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Explain: The lower route presents that token with a concrete maintenance request, evaluates the subject, action, resource, context, policy, and scope, then records the allow/deny outcome for audit and lifecycle handling.
Explain: An authorization flaw lets the right person do the wrong thing - privilege escalation, or accessing another user's object by changing an ID (insecure direct object reference).
Explain: Least privilege shrinks the blast radius: a compromised low-privilege account or token can do little, whereas over-broad grants turn any breach into a full compromise.
Trace codes, polling, tokens, and expiry in the device flow.

Major section

Identity and Access Control Roadmap

Application programming interface means a defined way for software systems to request actions or data; it is often shortened to API.

A gateway means the boundary system that connects local devices to another network or service.
This runway does not prove that every account or service is secure.
When you later use hardware, the same process applies.

Worked route from OAuth device authorization to a scoped access token and a least-privilege decision on a building-alarm request.

Major section

Identity and Access Control Roadmap (continued)

The top route separates user identity proof from OAuth authorization and ends with a scoped access token.

The deeper sections separate authentication, authorization, accounting, credentials, trust, lifecycle controls, and access evidence.
Learn how IoT systems prove identity, issue trust, and limit what each user or device can do.
Authorization then uses a model.

Major section

Identity and Access Control Roadmap (continued)

A system can authenticate you flawlessly and still must separately decide what you may touch.

The system must also know who is connecting, what that identity is allowed to do, and how to revoke access when something goes wrong.
Keeping them distinct is the foundation of the whole module.
Grant the minimum permissions a role needs.

Major section

Identity and Access Control Roadmap (continued)

An IoT system is not secure just because it uses encryption.

For beginners, the key idea is simple: authentication answers "Who are you?" and access control answers "What are you allowed to do?": Both are required.
If either one is weak, attackers can move from a single stolen password or device key into the rest of the IoT system.
Getting through the door is not the same as being allowed everywhere inside.

Major section

Identity and Access Control Roadmap (continued)

The worked route makes the chapter's key sequencing rule visible: signing in or receiving a token does not by itself authorize every operation.

The lower route presents that token with a concrete maintenance request, evaluates the subject, action, resource, context, policy, and scope, then records the allow/deny outcome for audit and lifecycle handling.
The only difference is that credentials come from real devices, cards, keys, or certificates instead of examples on the page.
Authentication asks "who are you?" - it proves identity: Authorization asks "what are you allowed to do?" - it grants permissions.

Major section

Identity and Access Control Roadmap (continued)

Logging in as yourself (authentication) does not entitle you to read someone else's records (authorization).

Mixing the two is the root of a large class of real security bugs, where a correctly logged-in user reaches data that was never theirs.
Intuition: authentication is showing your ID at the door; authorization is the guest list deciding which rooms your badge opens.
Authentication and access control provide the identity and permission layer for IoT security.

Major section

Identity and Access Control Roadmap (continued)

Identities have a lifecycle: provision, rotate credentials, and - critically - revoke on role change or offboarding.

password + SMS code -> know + have = real MFA password + security question -> know + know = NOT real MFA fingerprint + hardware key -> are + have = real MFA.
Because authentication and authorization are separate, they fail in separate ways - and both must be tested.
Stale, un-revoked access is a leading cause of breaches; deprovisioning is as important as onboarding.

Major section

Identity and Access Control Roadmap (continued)

An authorization flaw lets the right person do the wrong thing - privilege escalation, or accessing another user's object by changing an ID (insecure direct object reference).

Least privilege shrinks the blast radius: a compromised low-privilege account or token can do little, whereas over-broad grants turn any breach into a full compromise.
Logs turn "someone changed this" into "this identity changed this at this time," which is essential for both response and deterrence.
So the identity layer is five verbs, not one: identify, authenticate, authorize, log, and revoke.

Deck summary

Key takeaways

Application programming interface means a defined way for software systems to request actions or data; it is often shortened to API.

The top route separates user identity proof from OAuth authorization and ends with a scoped access token.
A system can authenticate you flawlessly and still must separately decide what you may touch.
An IoT system is not secure just because it uses encryption.
The worked route makes the chapter's key sequencing rule visible: signing in or receiving a token does not by itself authorize every operation.

Retrieval practice

Recall check 1 of 5

Shield Shelly says: answer from memory, then check your reasoning.

Q1What proves possession, knowledge or device identity without granting every operation?

AAuthentication Protocols and Proof

BAccess-Control Policy Decision

CDevice and User Identity Lifecycle

Show answer

Answer: A Authentication protocols prove possession, knowledge, or device identity across a defined channel and threat boundary; they do not by themselves grant every operation.

Retrieval practice

Recall check 2 of 5

Shield Shelly says: answer from memory, then check your reasoning.

Q2An IoT deployment uses 5,000 battery-powered sensors with 32 KB RAM and a five-year coin-cell target. Each sensor can receive a unique protected pre-shared key, and the backend supports DTLS. The devices send small, infrequent reports. Which offered authentication approach is the best candidate to test against this resource budget?

AFull TLS 1.3 mutual authentication with 4096-bit RSA certificates

BUsername and password authentication over HTTP

CPre-shared keys (PSK) with DTLS for lightweight mutual authentication

DOAuth 2.0 with JWT tokens refreshed every hour

Show answer

Answer: C Unique, protected PSKs with DTLS avoid a large public-key handshake and can provide mutual authentication for this constrained traffic.

Retrieval practice

Recall check 3 of 5

Shield Shelly says: answer from memory, then check your reasoning.

Q3Complete the Python code to implement HMAC-based device authentication for an IoT gateway:

Amessage = f"{device_id}:{timestamp}:{payload}"

Bmessage = device_id + payload

Cmessage = hashlib.sha256(payload).hexdigest()

Dmessage = f"{payload}:{shared_secret}"

Show answer

Answer: A HMAC authentication combines device_id, timestamp, and payload into a message string, then signs it with the shared secret using HMAC-SHA256.

Q4What is the difference between authentication and authorization?

ABoth names mean the same login step, with no separate permission check.

BAuthorization proves identity; authentication grants permissions.

CAuthentication proves identity; authorization decides permitted actions.

DAuthentication applies to humans and authorization only to devices.

Show answer

Answer: C Identity (authentication) and permissions (authorization) are distinct decisions.

Retrieval practice

Recall check 4 of 5

Shield Shelly says: answer from memory, then check your reasoning.

Q5Why is 'password + security question' not considered true multi-factor authentication?

ASecurity questions are encrypted and passwords are not.

BBoth are the same factor type (something you know).

CIt is true MFA, because it uses two separate fields.

DBecause security questions count as 'something you are'.

Show answer

Answer: B MFA requires different factor types so one theft does not defeat all factors.

Retrieval practice

Recall check 5 of 5

Shield Shelly says: answer from memory, then check your reasoning.

Q6A correctly logged-in user changes the numeric ID in a request URL and views another user's private record. Which control failed?

AAuthentication: the user must have forged their login.

BAuthorization: authentication succeeded

CEncryption: the record should have been encrypted.

DNothing failed; logged-in users may see all records.

Show answer

Answer: B Being authenticated is not being authorized; per-object permission checks were missing.

Print reference

Answers 1 of 2

Answer key.

A · Authentication protocols prove possession, knowledge, or device identity across a defined channel and threat boundary; they do not by themselves grant every operation.
C · Unique, protected PSKs with DTLS avoid a large public-key handshake and can provide mutual authentication for this constrained traffic.
A · HMAC authentication combines device_id, timestamp, and payload into a message string, then signs it with the shared secret using HMAC-SHA256.
C · Identity (authentication) and permissions (authorization) are distinct decisions.

Print reference

Answers 2 of 2

Answer key.

B · MFA requires different factor types so one theft does not defeat all factors.
B · Being authenticated is not being authorized; per-object permission checks were missing.