Authentication

Authentication and permissions

Cloud credentials

Open Account → API & MCP to manage connections and keys. Workspace keys belong to one workspace; personal keys act with their owner's current access; aggregate connections retain their selected workspace grants. OAuth connections are also available for supported MCP clients.

Send REST credentials as Authorization: Bearer TOKEN. A key does not bypass workspace membership, resource restrictions, service grants, or plan entitlements. Access is checked on each request. Use the smallest available scopes and resource grants needed by each integration.

For resource logs, ingestion requires logs:write; querying requires logs:read. Resource discovery requires resource-read access. A write-only sender should not be given read or workspace-management privileges merely to test ingestion.

Cloud health at /v1/health is public. Other documented operations require authentication unless the live reference states otherwise. Inspect your identity using GET /v1/me; use GET /v1/workspaces to discover accessible workspaces.

Desktop credentials

Desktop tokens are created locally and cannot authenticate to the cloud. In a resource's Logs → Send logs here, enable the localhost listener and create a named sender. Store the returned token immediately and revoke it when no longer needed. Choose Create reader token in the same panel for a separate logs:read credential used by queries.

The optional HTTP listener binds to loopback. Owner operations use a private, peer-UID-checked Unix socket; possession of an HTTP token does not grant owner access. Desktop HTTP health also requires authentication.

Rotate and troubleshoot

Create a replacement key, update the sender's secret, verify a successful request, then revoke the old key. Revocation stops new requests but does not erase previously ingested logs.

• 401: credential is missing, invalid, expired, or revoked.
• 403: credential lacks current scope, workspace/resource access, or required entitlement.
• 404: check destination and IDs; inaccessible objects may not be exposed.

Never send local credentials to a cloud URL or cloud credentials to an untrusted forwarding endpoint. See forwarding for storing cloud credentials in the desktop keyring.

---

Published from the versioned Alshival documentation source. Edit the source rather than this generated page.