Problem
The MCP server authenticates to InfluxDB with a single static token read from the environment at startup. Whatever that token can do, every agent session can do. There is no user identity, no per-session permission boundary, and no way to attribute actions to a person. On a shared server, one leaked or over-privileged token exposes everyone.
InfluxDB 3 Enterprise supports user authentication: a client exchanges a username and password for a short-lived access token plus a refresh token (POST /api/v3/authorize, POST /api/v3/authorize/refresh). The MCP server cannot use this today, because it treats the token as immutable configuration.
Goals
- The server can authenticate as an Enterprise user with
INFLUX_DB_USERNAME and INFLUX_DB_PASSWORD, and all operations run with that user's permissions.
- Token lifecycle (login, proactive refresh before expiry, re-login when the refresh token is rejected) is handled inside the server. The agent never sees or handles token material.
- Static-token configuration keeps working unchanged for all product types.
- Ambiguous configuration (both a token and credentials set) fails at startup with a clear error instead of silently picking an identity.
- Credentials and tokens stay in memory, are never written to disk, and never appear in logs or error messages.
Scope
- New env vars
INFLUX_DB_USERNAME / INFLUX_DB_PASSWORD, with validation rules for Enterprise (exactly one auth method) and an error when credentials are set for other product types.
- A new auth service owning login, refresh, and re-login, with coalescing so concurrent tool calls share one refresh.
- HTTP client resolves the token per request; one retry after a forced refresh on 401.
- The SDK query/write client is rebuilt when the token rotates.
- The existing status resource reports auth mode (
token or user) and username — no secrets.
- No new MCP tools.
Out of scope
- User and role management tools (user CRUD, role assignment)
- OAuth device-code login
- Initial-user bootstrap and password-reset endpoints
- InfluxDB 3 Core (the gate is per product type; Core can be added when it supports these endpoints)
Problem
The MCP server authenticates to InfluxDB with a single static token read from the environment at startup. Whatever that token can do, every agent session can do. There is no user identity, no per-session permission boundary, and no way to attribute actions to a person. On a shared server, one leaked or over-privileged token exposes everyone.
InfluxDB 3 Enterprise supports user authentication: a client exchanges a username and password for a short-lived access token plus a refresh token (
POST /api/v3/authorize,POST /api/v3/authorize/refresh). The MCP server cannot use this today, because it treats the token as immutable configuration.Goals
INFLUX_DB_USERNAMEandINFLUX_DB_PASSWORD, and all operations run with that user's permissions.Scope
INFLUX_DB_USERNAME/INFLUX_DB_PASSWORD, with validation rules for Enterprise (exactly one auth method) and an error when credentials are set for other product types.tokenoruser) and username — no secrets.Out of scope