Token Handling

Storing only a digest keeps the table from being a pile of live bearer credentials: a leaked read yields nothing a sensor could present. One row per device keeps revocation targeted, so killing one sensor does not strand the whole fleet.

A token in script-readable storage loses to script injection; a token in a cookie the browser attaches automatically loses to cross-site forged requests. Neither is safer until you name the threat you are buying down.

No. A scope records the ceiling the issuer put on what the caller may ask for; it grants nothing on your service. Your own authorization rules still decide, and both the scope check and your rule must pass.

At least 128 bits from a cryptographically secure generator; a fixed, recognisable leading segment plus a non-secret key identifier; and a fast cryptographic digest such as SHA-256 as the verifier. A deliberately slow password-hashing function is the wrong tool for a high-entropy machine key.

The private signing key should rest in the smallest place that can still mint — ideally a hardware module or a signing service that returns tokens and never the key — and exactly one component should be permitted to use it.

A unique index on the stored digest makes a presented credential its own lookup key. The row also carries a family identifier for the rotation lineage and a state column; superseded rows must stay until expiry, or a replay looks merely unknown.

A credential in a URL is copied into access logs at every hop, into the referring-page header on same-origin asset requests, into shared caches, and into history, bookmarks and pasted-link previews. The log copies are the ones nobody can recall.

Size the window from measured client clock spread plus the longest legitimate retry delay, then accept that it bounds rather than prevents replay: a captured signature works until the signed timestamp ages out. Narrowing it further needs a shared seen-value store with the same lifetime.

Reject those tokens now — an unobtainable key is not evidence of validity — and schedule one bounded refetch instead of one per request. Tokens whose key identifier is already held keep verifying normally, so the outage stays confined to the unknown ones.

Because a station holds several keys for different jobs. Per-key permissions mean a leak exposes only what that job needed; per-key ceilings stop a runaway backfill starving the live feed; and revoking one key leaves the others running. Effective authority is the key's scope intersected with the account's.

The job record carries the authorization decision rather than the credential: the subject it acts for, one action on one resource, the rule that allowed it, and a deadline after which the job is dropped rather than run late.

A canonical string fixes which bytes both sides sign: method, path, query in a defined order, a closed named set of headers, and a digest of the body as received. Anything outside it is unsigned and an intermediary may rewrite it undetected.

A platform-managed key store isolates a credential per application, keeps it encrypted at rest and can gate reads behind a device unlock. It does not protect the credential in use: anything running as that application can still ask for it.

Because the verifier, not the sender, must decide how a token is checked, and that set has to change on the issuer's rotation schedule across a fleet deployed in waves. An inherited default is invisible in review and can drift between environments.

Cache the decision you derived, keyed on a keyed digest of the token rather than the token itself, for the shorter of a configured TTL and the credential's own remaining life. The TTL you pick is exactly the revocation lag you are accepting.

Not instantly: the leaked key keeps working for as long as any cached verification answer lives, so the honest number is the worst-case cache lifetime plus propagation unless an invalidation is published. The replacement rides an overlap — issue a second key, let the station cut over, retire the first on a watched deadline.

Neither run it nor drop it: park the job and escalate to someone who holds current authority, with the window's deadline attached. A withdrawn entitlement settles permission, not whether a commitment already made to a third party is void.

Ship consumers a version that accepts two verification keys, confirm by measurement that they are running it, only then start signing with the new key, and withdraw the old one after the last token it signed has expired.

Revoke every refresh row for that subject, then write one suppression entry keyed by subject and a cut instant so already-minted short-lived tokens are rejected. The list stays small: each entry expires with the tokens it suppresses.

It converts a credential theft into a session ride. Injected script can still act as the user while the page is open, but there is no portable token to carry away and replay later from elsewhere. The cost is a stateful hop in the request path.

Freeze facts that change rarely and are cheap to be wrong about for one token lifetime; look up per request any fact whose being wrong is expensive or irreversible. The token lifetime is the staleness budget, and someone must sign off that number.

Sign the worst case, not the write. Revocation lag is a minted token's remaining lifetime plus the time a suppression entry needs to reach every verifier; only the second term belongs to this service, and shortening it buys a dependency.

Versioned coverage rules, two signing secrets accepted at once so rotation is rolling rather than a cutover, a secret scoped per purpose, an explicit at-least-once delivery promise with an idempotency key, diagnosable rejections, and published test vectors.

Let custody diverge at the edge and converge at the server. The two clients face genuinely different threat surfaces, so one model serves one of them badly — but two models are only affordable if the server side stays a single credential format, verification path and revocation story.