Authentication & Authorization

Because the selection is filed server-side under the identifier the visitor had before signing in, and sign-in issues a new one. Carrying it over is an explicit step in the login handler, and not every item should be carried.

Nothing stops them. A cookie value is input the caller can retype, so a plain-text role claim is simply edited. The value must be an unguessable reference to a record the scheduler holds, or state the server can prove it wrote.

The idle clock restarts on every request and ends a session left unattended. The absolute clock counts from the sign-in that created the record, never restarts, and caps how long one authentication may keep counting.

A short-lived, single-purpose pre-authentication handle bound to one login attempt and to the factor still pending, carrying no authority to reach application endpoints. It must be its own credential, not a signed-in session record wearing a pending flag.

Pinning raises the cost of using a stolen session reference — the thief must also call from that network — but never prevents it. The price is paid by legitimate callers whose address moves: roaming clients, carrier re-addressing and shared egress pools.

Store a one-way digest of the key, never the key itself, alongside a non-secret prefix and last characters for display, the owning station, the key's permissions, and timestamps. The plaintext is shown once at creation and is not recoverable afterwards.

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.

A relying party parks one short-lived record per sign-in attempt, holding the value it sent as state, the nonce, the code_verifier, which provider was used, and the page the user was heading to. The callback request itself brings back almost none of that.

A machine token stays valid for the whole expires_in window the authorization server granted, so one acquisition serves thousands of polls. Acquiring per call adds a round trip to every request and hammers a shared, rate-limited endpoint for nothing.

No notification arrives. The next refresh of that user's stored grant is refused with invalid_grant, or an API call answers 401, and that refusal is terminal: mark the row dead and stop the work rather than retrying.

Record the issuer, the subject and, when the provider issues one, the provider session identifier on every local session row you create at login. Without that index an arriving logout notice names nothing you hold, and your endpoint can only discard it.

Renting moves the login path's uptime, its abuse handling and most of its key custody onto someone else; running your own leaves you all three plus the on-call rotation behind them. Neither choice moves your obligation to show who consented to what.

An acting-as session has two principals: the actor doing the work and the subject whose authority is being used. Carry only the subject and every record reads as the adjuster's own work, so nothing shows who really acted.

A check in the HTTP handler only runs when a request reaches that handler. A scheduled job, a message consumer or an import script call the ticket-closing code directly, so the guarded path is simply not on their route.

The charterer identifier must come from something the caller cannot rewrite: a claim in the verified credential, the hostname the request arrived on, or a header the edge sets and strips. A body field is caller-controlled input.

A permission string names one resource and one action together: establishment:inspect is the inspect action on establishment records. Keeping permissions as rows makes capability data rather than schema, so adding one is an insert instead of a new column and a deployment.

A relation tuple records one fact — this subject holds this relation on this object, written object#relation@subject. Permission becomes the set of stored tuples plus the schema's rules about which relations imply which, instead of a role value stored on the user row.

A pending-attempt record on the server: a digest of the delivered code, the sign-in attempt it belongs to, an expiry a few minutes out, a consumed marker, and the count of failed guesses against it.

A time-derived code is recomputed by the server from the shared secret and the clock, so it must hold that secret itself, not a digest. Encrypting it at rest protects it from a database read, and nothing more.

A passkey challenge is what makes each ceremony unrepeatable. The server generates it randomly, holds it against one pending ceremony and spends it on use, so a captured response cannot be replayed. The specification requires unguessable entropy and recommends at least 16 bytes.

A remembered device is its own server-side record — account, a hash of the issued value, issue time, absolute expiry — and the value it hands the browser is bound to one account and one browser profile, never to a person.

Every simultaneously valid code multiplies an attacker's odds per guess. A cap of five guesses against one live six-digit code is about five chances in a million; twelve live codes make the same cap worth sixty in a million.

A child identity table of (issuer, subject) rows, uniquely constrained on both columns together, lets one account be reached by several sign-in routes. It costs a lookup on every federated sign-in and a last-route rule the schema cannot enforce.

Take the domain from the typed address, look it up in a table of domains a tenant has verified, then follow that tenant to its identity-provider connection record and redirect. An unmatched domain falls back to local sign-in.

A helper-installed principal leaves the whole validation path unexercised. The test starts after the assertion would have been parsed, its signature checked, its audience and validity window enforced and its identifier recorded — so every rejection rule the service provider owns is untested.

Because the checks worth testing are rejections, and a stand-in that does not sign cannot produce a message that is signed by the wrong key. Holding a test keypair lets the suite mint both the accepted message and every rejected variant of it.

Deleting destroys attribution: the hours entries, corrections and approvals the driver authored can no longer be resolved to a person, and the identifier could later be handed to someone else. Deactivation keeps the identity resolvable while ending sign-in.