influxdata/influxdb · error · Error

Authorization error

Error message

Authorization error: {0}

What it means

Wraps `ResourceAuthorizationError` via `#[from]` into the server HTTP error enum. The request was authenticated (the caller's identity is known) but that identity is not permitted to perform the requested action on the resource — e.g. read/write permission missing, or the action isn't allowed on that database/token. The inner message names the denied resource/action.

Solutions

1. Inspect the inner ResourceAuthorizationError to see which action/resource was denied.
2. Create or update the token with the required permissions (e.g. write access to the target database) and update the client's `Authorization: Bearer` header.
3. Confirm the request targets the database/resource the token is scoped to.
4. If multi-tenant, verify you are using a token issued for the correct account/tenant.

Example fix

// before
// curl -H "Authorization: Bearer <read-only-token>" .../api/v3/write?db=metrics
// after: mint a token with write access to db 'metrics' and use it

// Verify token permissions before the call
const auth = await api.me(token);
const canWrite = auth.permissions.some(p => p.action === 'write' && p.resource.db === 'metrics');
if (!canWrite) throw new Error(`token lacks write permission on db 'metrics'`);

try {
  await api.write(db, points);
} catch (e) {
  if (/Authorization error:/.test(e.message)) {
    throw new PermissionError(`Token not allowed to write ${db}: ${e.message}`);
  }
  throw e;
}

When it happens

Trigger: Any HTTP API call whose token lacks the required permission: querying a database the token cannot read, writing to a restricted database, using an admin-only endpoint (e.g. processing-engine configuration) with a read-only token, or a token from another resource/tenant.

Common situations: Using a token created with too-narrow permissions; pointing a client at the wrong database; rotating tokens and shipping an old scope; calling admin endpoints with an operator-vs-read token mix-up.

Understand the failure class

Background: Permission denied / not authorized / 403 Forbidden: access-control rejections when the caller lacks the required role, grant, or ownership — this error's family across 18 libraries.

Related errors

• authorization failure
• Authentication error
• cannot parse token permission
• requestor is forbidden from requested resource
• resource type should be parseable

AI-assisted analysis of influxdata/influxdb@06200ef96b (2026-09-19). Data as JSON: /api/errors/589ea2cc8ac8288c. Report an issue: GitHub.

Appendix: source

Thrown at influxdb3_server/src/http.rs:367

    #[error("heap dump failed: {0}")]
    HeapPprof(#[from] jemalloc_pprof_http::Error),

    #[error(transparent)]
    Catalog(#[from] CatalogError),

    #[error("Python plugins not enabled on this server")]
    PythonPluginsNotEnabled,

    #[error("Plugin error: {0}")]
    Plugin(#[from] influxdb3_processing_engine::plugins::PluginError),

    #[error("Processing engine error: {0}")]
    ProcessingEngine(#[from] influxdb3_processing_engine::manager::ProcessingEngineError),

    #[error(transparent)]
    Influxdb3TypesHttp(#[from] influxdb3_types::http::Error),

    #[error("Authorization error: {0}")]
    ResourceAuthorization(#[from] ResourceAuthorizationError),

    #[error("Authentication error: {0}")]
    Authentication(#[from] AuthenticatorError),

    #[error("The following Database does not exist: {0}")]
    MissingDb(String),

    #[error("The following Database Table does not exist: {0}")]
    MissingTable(String),

    #[error("Cannot parse the given human time: {0}")]
    ParsingHumanTime(#[source] humantime::DurationError),

    #[error("Cannot parse the timestamp: {0}")]
    ParsingTimestamp(#[from] chrono::ParseError),

    #[error("Timestamp is out of range")]

View on GitHub (pinned to 06200ef96b)