4.4 Token-Based Authentication
Interactive users authenticate as above. Non-interactive callers do not, and the mechanisms are different enough to need their own section.
4.4.1 Session Tokens
A successful login returns a session identifier. Clients present it as a bearer token on every request.
Sessions are server-side and the identifier is opaque. It is resolved in-process, so validation costs nothing per request and there is no identity provider round trip.
Sessions have a bounded lifetime, configured centrally. Clients renew before expiry; renewal rotates the identifier.
-
Renewal comes in two forms: a rotation that issues a new session and invalidates the old one, and an in-place extension that keeps the same identifier. The portal uses periodic renewal on a timer.
A single failed renewal does not end a session. The session may still be valid and the next attempt may succeed, so a client must not log out on first failure — doing so produces spurious logouts on a brief network blip.
Expired sessions are reaped by a background task, with a grace window while a refresh token is present so that a client that has been briefly offline can recover.
4.4.2 Collector (Sensor) Tokens
Sensors do not log in. Each registered host is issued its own token, and this is the mechanism that makes remote and off-grid discovery safe.
A host is registered in the inventory and allocated a host identifier.
The platform issues a token whose subject is that host identifier, signed with the current signing key, with a bounded lifetime measured in months rather than hours.
The host is issued a signing key pair. The public key is certified by the platform and stored in the host inventory.
On submission, the collector reads the host identifier from the token, retrieves that host certificate, and verifies the signature against it. There is no shared secret, so one compromised host cannot submit as another.
Discovered material is additionally signed by the host and encrypted to the platform using a key derived from an ECDH exchange, so the payload is protected independently of the transport.
To revoke a host, remove it from the inventory. Its submissions then fail verification immediately, without waiting for the token to expire.
4.4.3 Signing Key Rotation
Signing keys are versioned. A new key becomes active for newly issued tokens.
The previous signing certificate remains retrievable so that tokens already in flight continue to validate.
Retire a previous key only after the longest-lived token issued under it has expired. Retiring early silently breaks every host still holding an old token.
Rotate on a schedule, and rotate immediately on suspicion of compromise. After an emergency rotation, redeploy to every host so that new tokens are issued.