Manage users and authentication
User authentication is off by default
Multi-user authentication and role-based access control (RBAC) are
generally available in InfluxDB 3 Enterprise 3.12, but remain opt-in.
Start the server with --user-auth-type to turn it on. Existing apiv3_
token workflows are unaffected.
Multi-user authentication lets users log in to InfluxDB 3 Enterprise with
individual credentials that issue JSON Web Tokens (JWTs).
Access is governed by
role-based access control (RBAC).
Multi-user authentication complements, but doesn’t replace, apiv3_
token authentication.
Enable user authentication
User authentication is off by default (--user-auth-type none).
To enable it, start the server with --user-auth-type set to one or both
authentication methods:
# Username and password sign-in
influxdb3 serve --user-auth-type basic
# OAuth/OIDC sign-in
influxdb3 serve --user-auth-type oauth
# Both
influxdb3 serve --user-auth-type basic,oauthnone disables user authentication and can’t be combined with other values.
--user-auth-type has no effect when the server starts with --without-auth.
For the complete list of authentication serve flags, see the
influxdb3 serve CLI
reference and
configuration options.
Configure JWT signing keys
basic sign-in requires an RSA key pair to sign JWTs.
Provide the key ID and private key with --jwt-key-id and
--jwt-private-key. The private key must be in PKCS#1 format.
Generate a compatible key with the -traditional flag:
openssl genrsa -traditional -out jwt-private-key.pem 2048influxdb3 serve \
--user-auth-type basic \
--jwt-key-id JWT_KEY_ID \
--jwt-private-key "$(cat jwt-private-key.pem)"Replace the following:
JWT_KEY_ID: an identifier for the key (used in the JWTkidheader; any string you choose)
Use PKCS#1 keys, not PKCS#8
A PKCS#8 key (the default openssl genrsa output without -traditional)
is rejected at startup: the server logs a warning and disables password
sign-in. Always generate the key with openssl genrsa -traditional.
If only one of --jwt-key-id and --jwt-private-key is set, or the key is
invalid, the server logs a warning, starts anyway, and disables password
sign-in. If neither is set, it starts with password sign-in disabled and
logs nothing at the default log level. oauth sign-in and apiv3_ token
authentication are unaffected.
JWTs expire one hour after they’re issued.
Bootstrap the initial admin
On a new deployment with no users and no operator token, create the initial
admin user and operator token with influxdb3 manage init-admin:
influxdb3 manage init-admininit-admin only works while the cluster has no users and no operator
token. On a deployment that already has an operator token (for example, one
that used token authentication before you enabled user authentication), it
returns 409 operator token already configured. Create the first admin user
with the operator token instead:
influxdb3 create user --username USERNAME --role Admin --token OPERATOR_TOKENIf you enabled only oauth sign-in (no --jwt-key-id and
--jwt-private-key), pass the subject (sub) claim your identity provider
issues for that person instead of a username and password:
influxdb3 manage init-admin --oauth-id OAUTH_SUBJECTReplace OAUTH_SUBJECT
with the sub claim your identity provider issues for that person.
init-admin prints the operator token once. Store it securely: there’s no way
to retrieve it again.
For complete syntax, see the
influxdb3 manage CLI
reference.
Log in and out
Users authenticate with influxdb3 auth login and end their session with
influxdb3 auth logout:
influxdb3 auth loginCredentials are stored at ~/.influxdb3/credentials.json and refreshed
automatically.
influxdb3 auth logout removes the local credentials but does not revoke
the issued JWT server-side. The token remains valid until it expires, one
hour after it was issued.
Upgrading to 3.12: sign in again if a token is rejected
3.12 requires each JWT’s aud (audience) claim to match the cluster’s catalog
UUID. Access tokens issued to basic sign-in users before upgrading to
3.12 don’t have a matching claim and are rejected after the upgrade.
Clients that call POST /api/v3/authorize/refresh with a stored refresh
token get a valid access token. The influxdb3 CLI refreshes only when its
stored token is within 30 minutes of expiry, so if a command is rejected after
the upgrade, sign in again with influxdb3 auth login.
apiv3_ API tokens are unaffected by this change.
Optional: Authenticate with OAuth/OIDC
To delegate authentication to an OAuth/OIDC identity provider, start the
server with --user-auth-type oauth (or basic,oauth) and set
--oauth-issuer, --oauth-audience, and --oauth-client-id:
influxdb3 serve \
--user-auth-type oauth \
--oauth-issuer OAUTH_ISSUER_URL \
--oauth-audience OAUTH_AUDIENCE \
--oauth-client-id OAUTH_CLIENT_IDReplace the following:
OAUTH_ISSUER_URL: the identity provider’s issuer URLOAUTH_AUDIENCE: the audience to validate incoming OAuth tokens againstOAUTH_CLIENT_ID: the OAuth client ID registered with the identity provider
--oauth-client-id is also required for influxdb3 auth login --oauth and
for browser sign-in to the
integrated Explorer UI.
For browser-based SSO through the integrated Explorer UI, also set
--webui-public-uri. See
Use the integrated Explorer UI.
Roles
InfluxDB 3 Enterprise includes three built-in roles–Admin, Auditor, and Member. Assign roles to users to control what they can do. For details on each role and the permissions model, see Role-based access control (RBAC).
Was this page helpful?
Thank you for your feedback!
Support and feedback
Thank you for being part of our community! We welcome and encourage your feedback and bug reports for InfluxDB 3 Enterprise and this documentation. To find support, use the following resources:
Customers with an annual or support contract can contact InfluxData Support. Customers using a trial license can email trial@influxdata.com for assistance.