---
title: Authentication
description: Configure how users sign in to Telegraf Controller. Choose between local username and password authentication, LDAP, and OIDC identity providers, or run multiple providers side by side.
url: https://docs.influxdata.com/telegraf/controller/authentication/
estimated_tokens: 2238
publisher: InfluxData
canonical: https://docs.influxdata.com/telegraf/controller/authentication/
date: '2026-06-24T05:47:49-07:00'
lastmod: '2026-06-24T05:47:49-07:00'
---

This section describes how users sign in to Telegraf Controller.
To authenticate API requests and Telegraf agent connections, see[Manage API tokens](/telegraf/controller/tokens/).

Telegraf Controller supports three authentication providers that you can run
individually or together:

|Provider |                Availability                |                 How users sign in                  |
|---------|--------------------------------------------|----------------------------------------------------|
|**Local**|                    Free                    |Username and password stored in Telegraf Controller |
|**LDAP** |[Telegraf Enterprise](/telegraf/enterprise/)|  Bind against an LDAP or Active Directory server   |
|**OIDC** |[Telegraf Enterprise](/telegraf/enterprise/)|Authorization code + PKCE flow with an OIDC provider|

Each provider is enabled and configured independently. You can run all three
at once and let users choose at the sign-in screen, or restrict sign-in to a
single provider.

## Choose an authentication provider

* **Use local authentication** when you don’t have a central identity
  provider, or when you need a non-enterprise deployment.
* **Use LDAP** to authenticate against an existing LDAP directory or
  Active Directory and provision users from directory groups.
* **Use OIDC** to authenticate against a modern identity provider
  (Okta, Auth0, Keycloak, Microsoft Entra ID, Google Workspace, and others)
  using authorization code flow with PKCE.

#### Local authentication can be disabled

If your security policy prohibits storing passwords in Telegraf Controller,
you can disable local authentication after configuring LDAP or OIDC and
bootstrapping an owner against that provider.
For details, see[Configure local authentication](/telegraf/controller/authentication/local/#disable-local-authentication).

## Multi-factor authentication and single sign-on

Telegraf Controller does not implement multi-factor authentication (MFA)
or single sign-on (SSO) directly. Both are delegated to the configured
identity provider:

* **Local authentication** does not support MFA or SSO. Use LDAP or OIDC
  if either is required.
* **LDAP authentication** enforces whatever MFA policy your LDAP or
  Active Directory server applies during the bind step.
* **OIDC authentication** enforces whatever MFA and SSO policies your
  OpenID Connect provider applies during the authorization step. Users
  already signed into the provider get single sign-on automatically.

To require MFA for Telegraf Controller, configure it in your identity
provider and disable local authentication so users sign in through that
provider only.

## Configuration model

Transport-level authentication settings such as URLs, bind credentials, client
secrets, and claim or attribute names are read from environment variables (or
command-line flags) at startup and are immutable until you restart
Telegraf Controller.

Provisioning and identity-mapping settings (provisioning strategy, default
role, allowed email domains, group-to-role mappings) are stored in the
database and editable at runtime from the **Settings** page by an owner or
administrator. The table below summarizes the split.

|                    Setting category                     |   Configured by    |Editable at runtime|
|---------------------------------------------------------|--------------------|-------------------|
|              Enable or disable a provider               |Environment variable|        No         |
|LDAP server URL, bind credentials, TLS, attribute mapping|Environment variable|        No         |
|OIDC issuer, client credentials, scopes, claims, callback|Environment variable|        No         |
|         Provisioning strategy and default role          |   Settings page    |        Yes        |
|                  Allowed email domains                  |   Settings page    |        Yes        |
|               Auto-link by verified email               |   Settings page    |        Yes        |
|                 Group-to-role mappings                  |   Settings page    |        Yes        |

## Provisioning strategies

When an LDAP or OIDC user signs in for the first time,
Telegraf Controller applies the provider’s **provisioning strategy** to
decide whether to create a Telegraf Controller account for them.

|     Strategy      |                                    Behavior on first sign-in                                    |
|-------------------|-------------------------------------------------------------------------------------------------|
|   `invite_only`   |   Only users with a pending invite for the matching email and provider are admitted. Default.   |
|`domain_restricted`|     A pending invite admits the user; otherwise, the email must end with an allowed domain.     |
|   `auto_create`   |A pending invite admits the user; otherwise, any user the provider authenticates is auto-created.|

Each external provider has its own provisioning strategy. For example, you can run LDAP
in `invite_only` while OIDC is in `auto_create`.

## Group-to-role mapping

For LDAP and OIDC, Telegraf Controller reads a list of groups from the
identity provider and maps them to Telegraf Controller roles. You define
mappings on the **Settings** page as rows of `(provider, group name, role)`.

* If a user belongs to multiple mapped groups, the highest role wins.
* If a user matches no mapping, the provider’s **default role** is assigned
  or sign-in is rejected, depending on the provider’s**On no group match** setting.
* The **Owner** role is never assigned through a mapping. You can [Transfer ownership](/telegraf/controller/users/transfer-ownership/) instead.

## Owner account behavior

The owner is the only account that can change LDAP and OIDC settings and is
treated specially across providers:

* The owner always retains a local password hash, even if LDAP or OIDC is the
  account’s primary provider. This guarantees a recovery path if your
  identity provider becomes unreachable.
* The owner’s role cannot be downgraded by LDAP or OIDC group mappings.
* An external identity provider cannot auto-link to the owner account.
  Account-takeover protection prevents an external login from claiming the
  existing owner record.

You can bootstrap an owner against LDAP or OIDC on first startup using the[`OWNER_AUTH_PROVIDER`](/telegraf/controller/reference/config-options/#owner-auth-provider)and[`OWNER_EXTERNAL_ID`](/telegraf/controller/reference/config-options/#owner-external-id)environment variables. This is required if you intend to disable local
authentication.

## [Local authentication](/telegraf/controller/authentication/local/)

Bootstrap the owner account, tune login security, and optionally disable local username and password authentication in Telegraf Controller.

## [LDAP authentication](/telegraf/controller/authentication/ldap/)

Authenticate Telegraf Controller users against an LDAP or Active Directory server, provision accounts from directory data, and map LDAP groups to Telegraf Controller roles.

## [OIDC authentication](/telegraf/controller/authentication/oidc/)

Authenticate Telegraf Controller users against an OpenID Connect identity provider with authorization code flow and PKCE, provision accounts from claims, and map provider groups to Telegraf Controller roles.

#### Related

* [Authentication and authorization](/telegraf/controller/reference/authentication-authorization/)
* [Manage users](/telegraf/controller/users/)
* [Manage settings](/telegraf/controller/settings/)
| Provider | Availability | How users sign in |
| --- | --- | --- |
| Provider | Availability | How users sign in |
| Local | Free | Username and password stored in Telegraf Controller |
| LDAP | Telegraf Enterprise | Bind against an LDAP or Active Directory server |
| OIDC | Telegraf Enterprise | Authorization code + PKCE flow with an OIDC provider |

| Setting category | Configured by | Editable at runtime |
| --- | --- | --- |
| Setting category | Configured by | Editable at runtime |
| Enable or disable a provider | Environment variable | No |
| LDAP server URL, bind credentials, TLS, attribute mapping | Environment variable | No |
| OIDC issuer, client credentials, scopes, claims, callback | Environment variable | No |
| Provisioning strategy and default role | Settings page | Yes |
| Allowed email domains | Settings page | Yes |
| Auto-link by verified email | Settings page | Yes |
| Group-to-role mappings | Settings page | Yes |

| Strategy | Behavior on first sign-in |
| --- | --- |
| Strategy | Behavior on first sign-in |
| invite_only | Only users with a pending invite for the matching email and provider are admitted. Default. |
| domain_restricted | A pending invite admits the user; otherwise, the email must end with an allowed domain. |
| auto_create | A pending invite admits the user; otherwise, any user the provider authenticates is auto-created. |