7 Operating Access Control
Sessions, Token Lifecycle, Timeouts, Privilege Elevation, and Defense in Depth
IoT session management, token lifecycle, refresh token rotation, idle and absolute timeout, privilege elevation, token revocation, defense in depth, JWT
7.1 Overview: Access Control That Lives Over Time
A login is not the end of the security story. A technician leaves a console open, a token leaks into a log file, a gateway needs emergency rights for five minutes, or a refresh token keeps minting new access after the human has gone home. Operating access control is the discipline that keeps those ordinary events from becoming standing access.
The earlier authentication and authorization chapters decide a single yes-or-no question. A real system must keep deciding, continuously, as users log in and walk away, as tokens age out, as a device temporarily needs more rights and then gives them back, and as credentials are revoked. This chapter is about access control as an ongoing process rather than a one-time check, and about layering several controls so that defeating any one of them is not enough.
Shield Shelly
“Security is not a wall, it’s a list of who can do what — and the proof that the list is enforced.”
In this chapter she audits time itself — every session, token, and elevated right must show when it expires and who can end it early.
Four moving parts carry that process. A session is the server’s record that a principal authenticated and is currently active. A token is the credential the client presents on each request to prove that session or authentication – it is temporary proof, not a permanent identity. Timeouts ensure nothing stays valid forever. Elevation grants extra rights briefly and then withdraws them. Around all of it, audit records what happened.
If you only need the intuition, this layer is enough: a token is short-lived proof of a prior authentication, not a standing key to the kingdom. Keep lifetimes short, provide a way to revoke, time out both idle and overlong sessions, and overlap controls so no single failure opens the door. Start with the rule you can test on every request, then layer timeouts, rotation, revocation, and audit around it. That is defense in depth.
Think of a day visitor. They sign in (a session record), receive a badge that expires that evening (a token with an absolute timeout), and have it reclaimed if they wander off unaccompanied (an idle timeout). A guard can escort them into a restricted room for a few minutes (elevation), and cameras record the whole visit (audit). No single one of these is the security; together they are.
7.1.1 The Live-System View
- Session versus token: A session is the server-side record of an active, authenticated principal. A token is the credential presented to prove it.
- Nothing lasts forever: Absolute timeouts end overlong sessions; idle timeouts reclaim abandoned ones. Tokens expire and can be revoked.
- Defense in depth: Sessions, tokens, timeouts, elevation limits, and audit overlap, so bypassing one control still leaves the others.
7.1.2 Everyday IoT Examples
- A dashboard that logs a user out after a period of inactivity is applying an idle timeout to reclaim an abandoned terminal.
- A token that is valid for years is effectively a permanent key; if it leaks, it is a standing breach until someone notices.
- “The request had a valid token” is not the whole story; a reviewer also asks whether the token had expired, been revoked, or exceeded its session limits.
7.1.3 Overview Knowledge Check
If you can separate sessions, tokens, timeouts, and elevation, you have the overview. Continue to Practitioner to run them in a real deployment where access keeps changing over time.
7.2 Practitioner: Run Sessions, Tokens, and Elevation
Operating access control means setting a handful of lifetimes and limits well, and coordinating them across the tiers of a system. The central trade-off is constant: shorter lifetimes shrink the window an attacker has with a stolen credential, but they cost more frequent refreshes, which on a battery device means more radio time and energy. Tune each lifetime to the risk it carries.
7.2.1 Choosing Token Lifetimes and Session Durations
Match the access token lifetime to the sensitivity of what it unlocks: very short for administrative or payment actions, minutes to about an hour for general device-to-cloud traffic, and longer only for low-risk read-only telemetry. For human logins, pair a short-lived access token with a longer-lived refresh token. Session duration follows the device class: a wearable may hold a long session with no idle timeout because it is personal and power-constrained; an industrial operator console should match a work shift and add a short idle timeout for walk-aways; an administrative console should be short on both counts.
7.2.2 Why Both Idle and Absolute Timeouts
The two timeouts defend against different failures. An absolute timeout caps the total session length so a session cannot live indefinitely, even for an active user. An idle timeout ends a session that has seen no activity, which is what protects an unattended terminal someone walked away from. A design needs both: absolute alone lets an abandoned terminal stay open until its hard limit, and idle alone lets an attacker keep a hijacked session alive forever with periodic activity.
7.2.3 Refresh-Token Hygiene
Refresh tokens are powerful because they mint new access tokens, so they need their own discipline. Rotate them on every use and make each one single-use: when a refresh token is exchanged, invalidate it and issue a fresh one. Track the refresh “family” so that if an old, already-used refresh token reappears, the system recognizes a likely theft and revokes the whole family. This turns a stolen refresh token from a quiet long-term foothold into a detectable, contained event.
Shelly’s Access Ledger
- Who: whoever presents a refresh token; each one is single-use and invalidated when exchanged.
- What: refresh tokens mint new access tokens, which is standing power if stolen.
- Proof: family tracking turns a reused old token into a theft signal that revokes the entire lineage.
7.2.4 Temporary Elevation, Not a Role Change
When a principal needs extra rights for a sensitive action, elevate specific capabilities for a short, time-boxed window up to a predefined ceiling, gated by additional authorization such as a second person’s approval. Elevation is not the same as changing someone’s role: it is temporary, bounded, and recorded, which keeps a precise audit trail of exactly when extra authority was used and why.
7.2.5 Coordinating Tiers to Avoid Zombie Sessions
Most IoT systems span tiers – an edge gateway, a cloud API, and a dashboard – each with its own session and token. If their timeouts are not coordinated, a “zombie session” appears: an operator walks away, the dashboard sits open, and because its refresh token is still valid it keeps acting even though the human is gone. The fix is to make the downstream tiers honor the upstream session state, so that a refresh is denied once the gateway session has hit its idle limit. Revocation has several mechanisms with different costs – short lifetimes, a server-side denylist, whole-session invalidation, and real-time token introspection (the most immediate, but it adds a lookup and latency to every request) – and a strong design combines them rather than relying on expiry alone. As an illustration, a stolen device holding a long-lived token can retain access for days until that token naturally expires; switching to short access tokens with rotating refresh tokens and a server-side revocation list cuts the worst-case exposure from days to minutes.
Shelly’s Access Ledger
- Who: the operator who walked away — the gateway’s idle limit already says the human is gone.
- What: a dashboard still minting access from its refresh token is a zombie session.
- Proof: downstream tiers deny refresh once the upstream session lapses, cutting worst-case exposure from days to minutes.
7.2.6 Practitioner Knowledge Check
If you can set lifetimes by risk, rotate refresh tokens, bound elevation, and coordinate tiers, you can stop here. Continue to Under the Hood for the validation logic and the stateless trade-off.
7.3 Under the Hood: Lifecycle, Revocation, and the Stateless Trade-Off
The deeper layer shows how each request is actually validated, how escalation is detected, and why statelessness and instant revocation pull against each other. The details are where defense in depth either holds or quietly fails.
7.3.1 Validation Order on Every Request
A token check is a sequence, and order matters. On each use the server should first check whether the token has been revoked (a denylist or session-invalidation lookup), then confirm it has not expired, then apply any refresh rules, and only then act – updating the last-activity time on success. Session validation runs in parallel: compare now against the session start for the absolute limit, against the last activity for the idle limit, and drop any temporary elevation whose window has passed. When a token is minted, its rights are clamped to the principal’s ceiling, so a token can never carry more authority than its owner is permitted.
Shelly’s Access Ledger
- Who: rights are clamped to the principal’s ceiling the moment a token is minted.
- What: revocation is checked first, then expiry, then refresh rules; only then does the request act.
- Proof: success updates last-activity, while absolute and idle limits are compared on the same request.
7.3.2 Refresh Rules and Family Detection
Refresh has its own guards. A refresh requested too soon (inside a minimum interval) or beyond a maximum refresh count should be denied; a successful refresh resets the access-token expiry. Single-use rotation plus family tracking is what catches theft: because each refresh token is invalidated when used, the reappearance of an already-used refresh token means two parties hold the same lineage, which signals a stolen token and triggers revocation of the entire family.
7.3.3 Detecting Privilege Escalation
Escalation detection compares what was attempted against the ceiling. Any requested right that lies outside the principal’s maximum authority is a forbidden bit, and a single forbidden bit marks an escalation attempt: it is audited and denied. Repeated attempts within a short window are treated as probing and can trigger a lockdown that terminates the session. The counter resets after the window passes, so a stray mistake does not permanently lock out a legitimate user.
7.3.4 What Makes a Token a Token
A JSON Web Token has three base64url parts: a header, a payload, and a signature. The signature is what makes the token trustworthy; it lets the server detect any tampering with the header or payload. A base64-encoded payload with no signature is not a token in any security sense – it is a readable, freely editable blob that anyone can forge. Encoding is not signing. Likewise, if you place authoritative permission flags inside a client-held token, that token must be signed, and you must accept that it stays valid until expiry; for instant revocation, keep the authoritative rights server-side and put only an opaque session reference in the token.
7.3.5 The Stateless Trade-Off, Stated Honestly
A signed token can be verified using only the signing key, with no session store – the appeal of stateless authentication is exactly this scalability. But that same property is the cost: a stateless token remains valid until it expires, so there is no built-in way to revoke it early. Adding a denylist or a token-introspection call restores prompt revocation, but it reintroduces the server-side lookup that statelessness removed, along with its latency. There is no free lunch: you trade instant revocation for statelessness, or you pay for state. Choose per the risk of the resource.
7.3.6 Quantifying a Stolen Token’s Window
It is useful to reason about exposure precisely. If a token has total lifetime T and is stolen with time t already elapsed, the fraction of its life still usable to the attacker is (T − t) / T. This is a deterministic fraction of remaining lifetime, not a probability – it simply says a freshly issued token gives the attacker nearly its full life, while one near expiry gives little. Shortening T shrinks every such window, at the cost of proportionally more refreshes.
7.3.7 Mechanisms and Failure Modes
| Mechanism | What It Guarantees | Evidence to Request | Failure Mode If Weak |
|---|---|---|---|
| Idle and absolute timeout | No session lives too long or sits abandoned. | Both limits enforced and tested at validation. | One limit alone leaves abandoned or endless sessions. |
| Refresh rotation | A stolen refresh token is detectable and contained. | Single-use rotation with family-reuse detection. | Static refresh tokens become silent long-term footholds. |
| Server-side revocation | Access can be withdrawn before expiry. | A denylist, session invalidation, or introspection. | Stateless-only tokens stay valid until they expire. |
| Elevation ceiling | Temporary rights never exceed the maximum. | Clamping to the ceiling plus escalation detection. | Unbounded elevation becomes privilege escalation. |
| Signed token | The token cannot be forged or altered. | A verified signature, never an unsigned payload. | An unsigned blob is trivially forged by the client. |
7.3.8 Common Pitfalls
- Calling an unsigned payload a token. Without a verified signature it is forgeable; encoding is not signing.
- Long-lived tokens with no revocation. A leaked token is then a standing breach until it expires.
- Only one timeout. Idle and absolute timeouts defend different failures; use both.
- Uncoordinated tiers. Mismatched timeouts across gateway, API, and dashboard create zombie sessions.
- Authoritative unsigned flags client-side. Permission flags in a client token must be signed, and even then need a revocation plan.
7.3.9 Under-the-Hood Knowledge Check
At this depth, operating access control is a set of overlapping, time-bound controls: ordered validation, rotating refresh tokens, bounded elevation with escalation detection, signed tokens, and a deliberate choice between statelessness and instant revocation. A trustworthy review traces a single request through every check and confirms that a stolen or revoked credential actually loses its power.
7.4 Summary
- Access control is an ongoing process: sessions track an authenticated principal, tokens prove that authentication on each request, timeouts bound validity, elevation grants brief extra rights, and audit records it all.
- A token is temporary, expiring proof of a prior authentication, not a permanent identity; keep lifetimes short and provide a revocation path.
- Match token lifetime to risk (very short for admin and payment, minutes to an hour for general traffic) and session duration to the device class, pairing short access tokens with longer refresh tokens for human logins.
- Use both idle and absolute timeouts: absolute caps total session length, idle reclaims abandoned terminals; each defends a failure the other does not.
- Rotate refresh tokens single-use with family-reuse detection so a stolen refresh token becomes detectable and contained.
- Elevate specific rights temporarily up to a ceiling with extra authorization, and detect escalation attempts that reach beyond the ceiling.
- Coordinate timeouts across edge, cloud, and dashboard tiers to prevent zombie sessions, and combine revocation mechanisms (short lifetimes, denylist, session invalidation, introspection).
- A JWT’s security comes from its signature; an unsigned payload is forgeable. Stateless signed tokens trade instant revocation for scalability, so early revocation requires added server-side state.
7.5 Key Takeaway
Treat access control as a continuous, layered process, not a one-time check. Keep tokens short-lived and signed, enforce both idle and absolute timeouts, rotate refresh tokens, bound and audit elevation, and coordinate every tier. Then decide deliberately: statelessness for scale, or server-side state for instant revocation. Defense in depth means no single control failing can open the door.
7.6 See Also
- Capability-Based Access Control: See where the permission flags and elevation ceilings used here come from.
- Access Control for IoT: Step back to the models and least-privilege scoping these sessions enforce.
- Authentication Methods for IoT: Revisit the tokens, certificates, and MFA that begin every session.
- Auth & Authorization Basics: Return to the AAA foundation behind sessions, tokens, and audit.