Authentication on Grafana Labs

Overview

Sat, 04 Apr 2026 12:26:57 +0000

User Authentication Overview

Grafana provides many ways to authenticate users. Some authentication integrations also enable syncing user permissions and org memberships.

Here is a table showing all supported authentication providers and the features available for them. Team sync and active sync are only available in Grafana Enterprise.

Provider	Support	Role mapping	Team sync (Enterprise only)	Active sync (Enterprise only)
Auth Proxy	v2.1+	-	v6.3+	-
Azure AD OAuth	v6.7+	v6.7+	v6.7+	-
Generic OAuth	v4.0+	v6.5+	-	-
GitHub OAuth	v2.0+	-	v6.3+	-
GitLab OAuth	v5.3+	-	v6.4+	-
Google OAuth	v2.0+	-	-	-
JWT	v8.0+	-	-	-
LDAP	v2.1+	v2.1+	v5.3+	v6.3+
Okta OAuth	v7.0+	v7.0+	v7.0+	-
SAML (Enterprise only)	v6.3+	v7.0+	v7.0+	-

Grafana Auth

Grafana of course has a built in user authentication system with password authentication enabled by default. You can disable authentication by enabling anonymous access. You can also hide login form and only allow login through an auth provider (listed above). There are also options for allowing self sign up.

The following applies when using Grafana’s built in user authentication, LDAP (without Auth proxy) or OAuth integration.

Grafana are using short-lived tokens as a mechanism for verifying authenticated users. These short-lived tokens are rotated each token_rotation_interval_minutes for an active authenticated user.

An active authenticated user that gets it token rotated will extend the login_maximum_inactive_lifetime_duration time from “now” that Grafana will remember the user. This means that a user can close its browser and come back before now + login_maximum_inactive_lifetime_duration and still being authenticated. This is true as long as the time since user login is less than login_maximum_lifetime_duration.

Remote logout

You can logout from other devices by removing login sessions from the bottom of your profile page. If you are a Grafana admin user you can also do the same for any user from the Server Admin / Edit User view.

Settings

Example:

[auth]

# Login cookie name
login_cookie_name = grafana_session


# The maximum lifetime (duration) an authenticated user can be inactive before being required to login at next visit. Default is 7 days (7d). This setting should be expressed as a duration, e.g. 5m (minutes), 6h (hours), 10d (days), 2w (weeks), 1M (month). The lifetime resets at each successful token rotation (token_rotation_interval_minutes).
login_maximum_inactive_lifetime_duration =


# The maximum lifetime (duration) an authenticated user can be logged in since login time before being required to login. Default is 30 days (30d). This setting should be expressed as a duration, e.g. 5m (minutes), 6h (hours), 10d (days), 2w (weeks), 1M (month).
login_maximum_lifetime_duration =

# How often should auth tokens be rotated for authenticated users when being active. The default is each 10 minutes.
token_rotation_interval_minutes = 10

# The maximum lifetime (seconds) an API key can be used. If it is set all the API keys should have limited lifetime that is lower than this value.
api_key_max_seconds_to_live = -1

Anonymous authentication

You can make Grafana accessible without any login required by enabling anonymous access in the configuration file.

Example:

[auth.anonymous]
enabled = true

# Organization name that should be used for unauthenticated users
org_name = Main Org.

# Role for unauthenticated users, other valid values are `Editor` and `Admin`
org_role = Viewer

If you change your organization name in the Grafana UI this setting needs to be updated to match the new name.

Basic authentication

Basic auth is enabled by default and works with the built in Grafana user password authentication system and LDAP authentication integration.

To disable basic auth:

[auth.basic]
enabled = false

You can hide the Grafana login form using the below configuration settings.

[auth]
disable_login_form = true

Set to true to attempt login with OAuth automatically, skipping the login screen. This setting is ignored if multiple OAuth providers are configured. Defaults to false.

[auth]
oauth_auto_login = true

To sign in with a username and password and avoid automatic OAuth login, add the disableAutoLogin parameter to your login URL. For example: grafana.example.com/login?disableAutoLogin or grafana.example.com/login?disableAutoLogin=true

Set the option detailed below to true to hide sign-out menu link. Useful if you use an auth proxy or JWT authentication.

[auth]
disable_signout_menu = true

URL redirect after signing out

URL to redirect the user to after signing out from Grafana. This can for example be used to enable signout from OAuth provider.

[auth]
signout_redirect_url =

Grafana Authentication

Sat, 04 Apr 2026 12:26:57 +0000

Grafana Auth

The following applies when using Grafana’s built in user authentication, LDAP (without Auth proxy) or OAuth integration.

Grafana are using short-lived tokens as a mechanism for verifying authenticated users. These short-lived tokens are rotated each token_rotation_interval_minutes for an active authenticated user.

Remote logout

Settings

Example:

[auth]

# Login cookie name
login_cookie_name = grafana_session

# The lifetime (days) an authenticated user can be inactive before being required to login at next visit. Default is 7 days.
login_maximum_inactive_lifetime_duration = 7d

# The maximum lifetime (days) an authenticated user can be logged in since login time before being required to login. Default is 30 days.
login_maximum_lifetime_duration = 30d

# How often should auth tokens be rotated for authenticated users when being active. The default is each 10 minutes.
token_rotation_interval_minutes = 10

# The maximum lifetime (seconds) an api key can be used. If it is set all the api keys should have limited lifetime that is lower than this value.
api_key_max_seconds_to_live = -1

Anonymous authentication

You can make Grafana accessible without any login required by enabling anonymous access in the configuration file. For more information, refer to Implications of allowing anonymous access to dashboards.

Example:

[auth.anonymous]
enabled = true

# Organization name that should be used for unauthenticated users
org_name = Main Org.

# Role for unauthenticated users, other valid values are `Editor` and `Admin`
org_role = Viewer

# Hide the Grafana version text from the footer and help tooltip for unauthenticated users (default: false)
hide_version = true

If you change your organization name in the Grafana UI this setting needs to be updated to match the new name.

Basic authentication

Basic auth is enabled by default and works with the built in Grafana user password authentication system and LDAP authentication integration.

To disable basic auth:

[auth.basic]
enabled = false

You can hide the Grafana login form using the below configuration settings.

[auth]
disable_login_form = true

Set to true to attempt login with OAuth automatically, skipping the login screen. This setting is ignored if multiple OAuth providers are configured. Defaults to false.

[auth]
oauth_auto_login = true

Set the option detailed below to true to hide sign-out menu link. Useful if you use an auth proxy or JWT authentication.

[auth]
disable_signout_menu = true

URL redirect after signing out

URL to redirect the user to after signing out from Grafana. This can for example be used to enable signout from oauth provider.

[auth]
signout_redirect_url =

Auth Proxy

Sat, 04 Apr 2026 12:26:57 +0000

Auth Proxy Authentication

You can configure Grafana to let a HTTP reverse proxy handle authentication. Popular web servers have a very extensive list of pluggable authentication modules, and any of them can be used with the AuthProxy feature. Below we detail the configuration options for auth proxy.

[auth.proxy]
# Defaults to false, but set to true to enable this feature
enabled = true
# HTTP Header name that will contain the username or email
header_name = X-WEBAUTH-USER
# HTTP Header property, defaults to `username` but can also be `email`
header_property = username
# Set to `true` to enable auto sign up of users who do not exist in Grafana DB. Defaults to `true`.
auto_sign_up = true
# Define cache time to live in minutes
# If combined with Grafana LDAP integration it is also the sync interval
sync_ttl = 60
# Limit where auth proxy requests come from by configuring a list of IP addresses.
# This can be used to prevent users spoofing the X-WEBAUTH-USER header.
# Example `whitelist = 192.168.1.1, 192.168.1.0/24, 2001::23, 2001::0/120`
whitelist =
# Optionally define more headers to sync other user attributes
# Example `headers = Name:X-WEBAUTH-NAME Role:X-WEBAUTH-ROLE Email:X-WEBAUTH-EMAIL Groups:X-WEBAUTH-GROUPS`
headers =
# Non-ASCII strings in header values are encoded using quoted-printable encoding
;headers_encoded = false
# Check out docs on this for more details on the below setting
enable_login_token = false

Interacting with Grafana’s AuthProxy via curl

curl -H "X-WEBAUTH-USER: admin"  http://localhost:3000/api/users
[
    {
        "id":1,
        "name":"",
        "login":"admin",
        "email":"admin@localhost",
        "isAdmin":true
    }
]

We can then send a second request to the /api/user method which will return the details of the logged in user. We will use this request to show how Grafana automatically adds the new user we specify to the system. Here we create a new user called “anthony”.

curl -H "X-WEBAUTH-USER: anthony" http://localhost:3000/api/user
{
    "email":"anthony",
    "name":"",
    "login":"anthony",
    "theme":"",
    "orgId":1,
    "isGrafanaAdmin":false
}

Making Apache’s auth work together with Grafana’s AuthProxy

I’ll demonstrate how to use Apache for authenticating users. In this example we use BasicAuth with Apache’s text file based authentication handler, i.e. htpasswd files. However, any available Apache authentication capabilities could be used.

Apache BasicAuth

In this example we use Apache as a reverse proxy in front of Grafana. Apache handles the Authentication of users before forwarding requests to the Grafana backend service.

Apache configuration

    <VirtualHost *:80>
        ServerAdmin webmaster@authproxy
        ServerName authproxy
        ErrorLog "logs/authproxy-error_log"
        CustomLog "logs/authproxy-access_log" common

        <Proxy *>
            AuthType Basic
            AuthName GrafanaAuthProxy
            AuthBasicProvider file
            AuthUserFile /etc/apache2/grafana_htpasswd
            Require valid-user

            RewriteEngine On
            RewriteRule .* - [E=PROXY_USER:%{LA-U:REMOTE_USER},NS]
            RequestHeader set X-WEBAUTH-USER "%{PROXY_USER}e"
        </Proxy>

        RequestHeader unset Authorization

        ProxyRequests Off
        ProxyPass / http://localhost:3000/
        ProxyPassReverse / http://localhost:3000/
    </VirtualHost>

The first four lines of the virtualhost configuration are standard, so we won’t go into detail on what they do.
We use a <proxy> configuration block for applying our authentication rules to every proxied request. These rules include requiring basic authentication where user:password credentials are stored in the /etc/apache2/grafana_htpasswd file. This file can be created with the htpasswd command.
- The next part of the configuration is the tricky part. We use Apache’s rewrite engine to create our X-WEBAUTH-USER header, populated with the authenticated user.
  - RewriteRule .* - [E=PROXY_USER:%{LA-U:REMOTE_USER}, NS]: This line is a little bit of magic. What it does, is for every request use the rewriteEngines look-ahead (LA-U) feature to determine what the REMOTE_USER variable would be set to after processing the request. Then assign the result to the variable PROXY_USER. This is necessary as the REMOTE_USER variable is not available to the RequestHeader function.
  - RequestHeader set X-WEBAUTH-USER “%{PROXY_USER}e”: With the authenticated username now stored in the PROXY_USER variable, we create a new HTTP request header that will be sent to our backend Grafana containing the username.
The RequestHeader unset Authorization removes the Authorization header from the HTTP request before it is forwarded to Grafana. This ensures that Grafana does not try to authenticate the user using these credentials (BasicAuth is a supported authentication handler in Grafana).
The last 3 lines are then just standard reverse proxy configuration to direct all authenticated requests to our Grafana server running on port 3000.

Full walkthrough using Docker.

For this example, we use the official Grafana Docker image available at Docker Hub.

Create a file grafana.ini with the following contents

[users]
allow_sign_up = false
auto_assign_org = true
auto_assign_org_role = Editor

[auth.proxy]
enabled = true
header_name = X-WEBAUTH-USER
header_property = username
auto_sign_up = true

Launch the Grafana container, using our custom grafana.ini to replace /etc/grafana/grafana.ini. We don’t expose any ports for this container as it will only be connected to by our Apache container.

docker run -i -v $(pwd)/grafana.ini:/etc/grafana/grafana.ini --name grafana grafana/grafana

Apache Container

For this example we use the official Apache docker image available at Docker Hub

Create a file httpd.conf with the following contents

ServerRoot "/usr/local/apache2"
Listen 80
LoadModule mpm_event_module modules/mod_mpm_event.so
LoadModule authn_file_module modules/mod_authn_file.so
LoadModule authn_core_module modules/mod_authn_core.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule authz_core_module modules/mod_authz_core.so
LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule env_module modules/mod_env.so
LoadModule headers_module modules/mod_headers.so
LoadModule unixd_module modules/mod_unixd.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
<IfModule unixd_module>
User daemon
Group daemon
</IfModule>
ServerAdmin you@example.com
<Directory />
    AllowOverride none
    Require all denied
</Directory>
DocumentRoot "/usr/local/apache2/htdocs"
ErrorLog /proc/self/fd/2
LogLevel error
<IfModule log_config_module>
    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
    LogFormat "%h %l %u %t \"%r\" %>s %b" common
    <IfModule logio_module>
    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio
    </IfModule>
    CustomLog /proc/self/fd/1 common
</IfModule>
<Proxy *>
    AuthType Basic
    AuthName GrafanaAuthProxy
    AuthBasicProvider file
    AuthUserFile /tmp/htpasswd
    Require valid-user
    RewriteEngine On
    RewriteRule .* - [E=PROXY_USER:%{LA-U:REMOTE_USER},NS]
    RequestHeader set X-WEBAUTH-USER "%{PROXY_USER}e"
</Proxy>
RequestHeader unset Authorization
ProxyRequests Off
ProxyPass / http://grafana:3000/
ProxyPassReverse / http://grafana:3000/

Create a htpasswd file. We create a new user anthony with the password password
Bash
```
htpasswd -bc htpasswd anthony password
```
Launch the httpd container using our custom httpd.conf and our htpasswd file. The container will listen on port 80, and we create a link to the grafana container so that this container can resolve the hostname grafana to the Grafana container’s IP address.
Bash
```
docker run -i -p 80:80 --link grafana:grafana -v $(pwd)/httpd.conf:/usr/local/apache2/conf/httpd.conf -v $(pwd)/htpasswd:/tmp/htpasswd httpd:2.4
```

Use grafana.

With our Grafana and Apache containers running, you can now connect to http://localhost/ and log in using the username/password we created in the htpasswd file.

Team Sync (Enterprise only)

Only available in Grafana Enterprise v6.3+

With Team Sync, it’s possible to set up synchronization between teams in your authentication provider and Grafana. You can send Grafana values as part of an HTTP header and have Grafana map them to your team structure. This allows you to put users into specific teams automatically.

To support the feature, auth proxy allows optional headers to map additional user attributes. The specific attribute to support team sync is Groups.

# Optionally define more headers to sync other user attributes
headers = "Groups:X-WEBAUTH-GROUPS"

You use the X-WEBAUTH-GROUPS header to send the team information for each user. Specifically, the set of Grafana’s group IDs that the user belongs to.

First, we need to set up the mapping between your authentication provider and Grafana. Follow these instructions to add groups to a team within Grafana.

Once that’s done. You can verify your mappings by querying the API.

# First, inspect your teams and obtain the corresponding ID of the team we want to inspect the groups for.
curl -H "X-WEBAUTH-USER: admin" http://localhost:3000/api/teams/search
{
  "totalCount": 2,
  "teams": [
    {
      "id": 1,
      "orgId": 1,
      "name": "Core",
      "email": "core@grafana.com",
      "avatarUrl": "/avatar/327a5353552d2dc3966e2e646908f540",
      "memberCount": 1,
      "permission": 0
    },
    {
      "id": 2,
      "orgId": 1,
      "name": "Loki",
      "email": "loki@grafana.com",
      "avatarUrl": "/avatar/102f937d5344d33fdb37b65d430f36ef",
      "memberCount": 0,
      "permission": 0
    }
  ],
  "page": 1,
  "perPage": 1000
}

# Then, query the groups for that particular team. In our case, the Loki team which has an ID of "2".
curl -H "X-WEBAUTH-USER: admin" http://localhost:3000/api/teams/2/groups
[
  {
    "orgId": 1,
    "teamId": 2,
    "groupId": "lokiTeamOnExternalSystem"
  }
]

Finally, whenever Grafana receives a request with a header of X-WEBAUTH-GROUPS: lokiTeamOnExternalSystem, the user under authentication will be placed into the specified team. Placement in multiple teams is supported by using comma-separated values e.g. lokiTeamOnExternalSystem,CoreTeamOnExternalSystem.

curl -H "X-WEBAUTH-USER: leonard" -H "X-WEBAUTH-GROUPS: lokiteamOnExternalSystem" http://localhost:3000/dashboards/home
{
  "meta": {
    "isHome": true,
    "canSave": false,
    ...
}

With this, the user leonard will be automatically placed into the Loki team as part of Grafana authentication.

Learn more about Team Sync

With enable_login_token set to true Grafana will, after successful auth proxy header validation, assign the user a login token and cookie. You only have to configure your auth proxy to provide headers for the /login route. Requests via other routes will be authenticated using the cookie.

Use settings login_maximum_inactive_lifetime_days and login_maximum_lifetime_days under [auth] to control session lifetime. Read more about login tokens

JWT Authentication

Sat, 04 Apr 2026 12:26:57 +0000

JWT authentication

You can configure Grafana to accept a JWT token provided in the HTTP header. The token is verified using any of the following:

PEM-encoded key file
JSON Web Key Set (JWKS) in a local file
JWKS provided by the configured JWKS endpoint

Enable JWT

To use JWT authentication:

Enable JWT in the main config file.
Specify the header name that contains a token.

[auth.jwt]
# By default, auth.jwt is disabled.
enabled = true

# HTTP header to look into to get a JWT token.
header_name = X-JWT-Assertion

To identify the user, some of the claims needs to be selected as a login info. You could specify a claim that contains either a username or an email of the Grafana user.

Typically, the subject claim called "sub" would be used as a login but it might also be set to some application specific claim.

# [auth.jwt]
# ...

# Specify a claim to use as a username to sign in.
username_claim = sub

# Specify a claim to use as an email to sign in.
email_claim = sub

# auto-create users if they are not already matched
# auto_sign_up = true

If auto_sign_up is enabled, then the sub claim is used as the “external Auth ID”. The name claim is used as the user’s full name if it is present.

Signature verification

JSON web token integrity needs to be verified so cryptographic signature is used for this purpose. So we expect that every token must be signed with some known cryptographic key.

You have a variety of options on how to specify where the keys are located.

Verify token using a JSON Web Key Set loaded from https endpoint

For more information on JWKS endpoints, refer to Auth0 docs.

# [auth.jwt]
# ...

jwk_set_url = https://your-auth-provider.example.com/.well-known/jwks.json

# Cache TTL for data loaded from http endpoint.
cache_ttl = 60m

Verify token using a JSON Web Key Set loaded from JSON file

Key set in the same format as in JWKS endpoint but located on disk.

jwk_set_file = /path/to/jwks.json

Verify token using a single key loaded from PEM-encoded file

PEM-encoded key file in PKIX, PKCS #1, PKCS #8 or SEC 1 format.

key_file = /path/to/key.pem

Validate claims

By default, only "exp", "nbf" and "iat" claims are validated.

You might also want to validate that other claims are really what you expect them to be.

# This can be seen as a required "subset" of a JWT Claims Set.
expect_claims = {"iss": "https://your-token-issuer", "your-custom-claim": "foo"}

LDAP Authentication

Sat, 04 Apr 2026 12:26:57 +0000

LDAP Authentication

The LDAP integration in Grafana allows your Grafana users to login with their LDAP credentials. You can also specify mappings between LDAP group memberships and Grafana Organization user roles.

Enhanced LDAP authentication is available in Grafana Cloud Advanced and in Grafana Enterprise.

Refer to Fine-grained access control in Grafana Enterprise to understand how you can control access with fine-grained permissions.

Supported LDAP Servers

Grafana uses a third-party LDAP library under the hood that supports basic LDAP v3 functionality. This means that you should be able to configure LDAP integration using any compliant LDAPv3 server, for example OpenLDAP or Active Directory among others.

Enable LDAP

In order to use LDAP integration you’ll first need to enable LDAP in the main config file as well as specify the path to the LDAP specific configuration file (default: /etc/grafana/ldap.toml).

[auth.ldap]
# Set to `true` to enable LDAP integration (default: `false`)
enabled = true

# Path to the LDAP specific configuration file (default: `/etc/grafana/ldap.toml`)
config_file = /etc/grafana/ldap.toml

# Allow sign up should almost always be true (default) to allow new Grafana users to be created (if LDAP authentication is ok). If set to
# false only pre-existing Grafana users will be able to login (if LDAP authentication is ok).
allow_sign_up = true

Grafana LDAP Configuration

Depending on which LDAP server you’re using and how that’s configured your Grafana LDAP configuration may vary. See configuration examples for more information.

LDAP specific configuration file (ldap.toml) example:

[[servers]]
# Ldap server host (specify multiple hosts space separated)
host = "127.0.0.1"
# Default port is 389 or 636 if use_ssl = true
port = 389
# Set to true if LDAP server should use an encrypted TLS connection (either with STARTTLS or LDAPS)
use_ssl = false
# If set to true, use LDAP with STARTTLS instead of LDAPS
start_tls = false
# set to true if you want to skip SSL cert validation
ssl_skip_verify = false
# set to the path to your root CA certificate or leave unset to use system defaults
# root_ca_cert = "/path/to/certificate.crt"
# Authentication against LDAP servers requiring client certificates
# client_cert = "/path/to/client.crt"
# client_key = "/path/to/client.key"

# Search user bind dn
bind_dn = "cn=admin,dc=grafana,dc=org"
# Search user bind password
# If the password contains # or ; you have to wrap it with triple quotes. Ex """#password;"""
bind_password = "grafana"

# User search filter, for example "(cn=%s)" or "(sAMAccountName=%s)" or "(uid=%s)"
# Allow login from email or username, example "(|(sAMAccountName=%s)(userPrincipalName=%s))"
search_filter = "(cn=%s)"

# An array of base dns to search through
search_base_dns = ["dc=grafana,dc=org"]

# group_search_filter = "(&(objectClass=posixGroup)(memberUid=%s))"
# group_search_filter_user_attribute = "distinguishedName"
# group_search_base_dns = ["ou=groups,dc=grafana,dc=org"]

# Specify names of the LDAP attributes your LDAP uses
[servers.attributes]
member_of = "memberOf"
email =  "email"

Using environment variables

You can interpolate variables in the TOML configuration from environment variables. For instance, you could externalize your bind_password that way:

bind_password = "${LDAP_ADMIN_PASSWORD}"

LDAP Debug View

Only available in Grafana v6.4+

Grafana has an LDAP debug view built-in which allows you to test your LDAP configuration directly within Grafana. At the moment of writing, only Grafana admins can use the LDAP debug view.

Within this view, you’ll be able to see which LDAP servers are currently reachable and test your current configuration.

To use the debug view:

Type the username of a user that exists within any of your LDAP server(s)
Then, press “Run”
If the user is found within any of your LDAP instances, the mapping information is displayed

Bind

Bind and Bind Password

By default the configuration expects you to specify a bind DN and bind password. This should be a read only user that can perform LDAP searches. When the user DN is found a second bind is performed with the user provided username and password (in the normal Grafana login form).

bind_dn = "cn=admin,dc=grafana,dc=org"
bind_password = "grafana"

Single Bind Example

If you can provide a single bind expression that matches all possible users, you can skip the second bind and bind against the user DN directly. This allows you to not specify a bind_password in the configuration file.

bind_dn = "cn=%s,o=users,dc=grafana,dc=org"

In this case you skip providing a bind_password and instead provide a bind_dn value with a %s somewhere. This will be replaced with the username entered in on the Grafana login page. The search filter and search bases settings are still needed to perform the LDAP search to retrieve the other LDAP information (like LDAP groups and email).

POSIX schema

If your LDAP server does not support the memberOf attribute add these options:

## Group search filter, to retrieve the groups of which the user is a member (only set if memberOf attribute is not available)
group_search_filter = "(&(objectClass=posixGroup)(memberUid=%s))"
## An array of the base DNs to search through for groups. Typically uses ou=groups
group_search_base_dns = ["ou=groups,dc=grafana,dc=org"]
## the %s in the search filter will be replaced with the attribute defined below
group_search_filter_user_attribute = "uid"

Group Mappings

In [[servers.group_mappings]] you can map an LDAP group to a Grafana organization and role. These will be synced every time the user logs in, with LDAP being the authoritative source. So, if you change a user’s role in the Grafana Org. Users page, this change will be reset the next time the user logs in. If you change the LDAP groups of a user, the change will take effect the next time the user logs in.

The first group mapping that an LDAP user is matched to will be used for the sync. If you have LDAP users that fit multiple mappings, the topmost mapping in the TOML configuration will be used.

LDAP specific configuration file (ldap.toml) example:

[[servers]]
# other settings omitted for clarity

[[servers.group_mappings]]
group_dn = "cn=superadmins,dc=grafana,dc=org"
org_role = "Admin"
grafana_admin = true # Available in Grafana v5.3 and above

[[servers.group_mappings]]
group_dn = "cn=admins,dc=grafana,dc=org"
org_role = "Admin"

[[servers.group_mappings]]
group_dn = "cn=users,dc=grafana,dc=org"
org_role = "Editor"

[[servers.group_mappings]]
group_dn = "*"
org_role = "Viewer"

Setting	Required	Description	Default
`group_dn`	Yes	LDAP distinguished name (DN) of LDAP group. If you want to match all (or no LDAP groups) then you can use wildcard (`"*"`)
`org_role`	Yes	Assign users of `group_dn` the organization role `"Admin"`, `"Editor"` or `"Viewer"`
`org_id`	No	The Grafana organization database id. Setting this allows for multiple group_dn’s to be assigned to the same `org_role` provided the `org_id` differs	`1` (default org id)
`grafana_admin`	No	When `true` makes user of `group_dn` Grafana server admin. A Grafana server admin has admin access over all organizations and users. Available in Grafana v5.3 and above	`false`

Nested/recursive group membership

Users with nested/recursive group membership must have an LDAP server that supports LDAP_MATCHING_RULE_IN_CHAIN and configure group_search_filter in a way that it returns the groups the submitted username is a member of.

To configure group_search_filter:

You can set group_search_base_dns to specify where the matching groups are defined.
If you do not use group_search_base_dns, then the previously defined search_base_dns is used.

Active Directory example:

Active Directory groups store the Distinguished Names (DNs) of members, so your filter will need to know the DN for the user based only on the submitted username. Multiple DN templates can be searched by combining filters with the LDAP OR-operator. Two examples:

group_search_filter = "(member:1.2.840.113556.1.4.1941:=%s)"
group_search_base_dns = ["DC=mycorp,DC=mytld"]
group_search_filter_user_attribute = "dn"

group_search_filter = "(member:1.2.840.113556.1.4.1941:=CN=%s,[user container/OU])"
group_search_filter = "(|(member:1.2.840.113556.1.4.1941:=CN=%s,[user container/OU])(member:1.2.840.113556.1.4.1941:=CN=%s,[another user container/OU]))"
group_search_filter_user_attribute = "cn"

For more information on AD searches see Microsoft’s Search Filter Syntax documentation.

For troubleshooting, by changing member_of in [servers.attributes] to “dn” it will show you more accurate group memberships when debug is enabled.

Configuration examples

OpenLDAP

OpenLDAP is an open source directory service.

LDAP specific configuration file (ldap.toml):

[[servers]]
host = "127.0.0.1"
port = 389
use_ssl = false
start_tls = false
ssl_skip_verify = false
bind_dn = "cn=admin,dc=grafana,dc=org"
bind_password = "grafana"
search_filter = "(cn=%s)"
search_base_dns = ["dc=grafana,dc=org"]

[servers.attributes]
member_of = "memberOf"
email =  "email"

# [[servers.group_mappings]] omitted for clarity

Multiple LDAP servers

Grafana does support receiving information from multiple LDAP servers.

LDAP specific configuration file (ldap.toml):

# --- First LDAP Server ---

[[servers]]
host = "10.0.0.1"
port = 389
use_ssl = false
start_tls = false
ssl_skip_verify = false
bind_dn = "cn=admin,dc=grafana,dc=org"
bind_password = "grafana"
search_filter = "(cn=%s)"
search_base_dns = ["ou=users,dc=grafana,dc=org"]

[servers.attributes]
member_of = "memberOf"
email =  "email"

[[servers.group_mappings]]
group_dn = "cn=admins,ou=groups,dc=grafana,dc=org"
org_role = "Admin"
grafana_admin = true

# --- Second LDAP Server ---

[[servers]]
host = "10.0.0.2"
port = 389
use_ssl = false
start_tls = false
ssl_skip_verify = false

bind_dn = "cn=admin,dc=grafana,dc=org"
bind_password = "grafana"
search_filter = "(cn=%s)"
search_base_dns = ["ou=users,dc=grafana,dc=org"]

[servers.attributes]
member_of = "memberOf"
email =  "email"

[[servers.group_mappings]]
group_dn = "cn=editors,ou=groups,dc=grafana,dc=org"
org_role = "Editor"

[[servers.group_mappings]]
group_dn = "*"
org_role = "Viewer"

Active Directory

Active Directory is a directory service which is commonly used in Windows environments.

Assuming the following Active Directory server setup:

IP address: 10.0.0.1
Domain: CORP
DNS name: corp.local

LDAP specific configuration file (ldap.toml):

[[servers]]
host = "10.0.0.1"
port = 3269
use_ssl = true
start_tls = false
ssl_skip_verify = true
bind_dn = "CORP\\%s"
search_filter = "(sAMAccountName=%s)"
search_base_dns = ["dc=corp,dc=local"]

[servers.attributes]
member_of = "memberOf"
email =  "mail"

# [[servers.group_mappings]] omitted for clarity

Port requirements

In above example SSL is enabled and an encrypted port have been configured. If your Active Directory don’t support SSL please change enable_ssl = false and port = 389. Please inspect your Active Directory configuration and documentation to find the correct settings. For more information about Active Directory and port requirements see link.

Troubleshooting

To troubleshoot and get more log info enable LDAP debug logging in the main config file.

[log]
filters = ldap:debug

Enhanced LDAP Integration

Sat, 04 Apr 2026 12:26:57 +0000

Enhanced LDAP integration

The enhanced LDAP integration adds additional functionality on top of the existing LDAP integration.

Enhanced LDAP integration is only available in Grafana Enterprise. For more information, refer to Enhanced LDAP integration in Grafana Enterprise.

OAuth authentication

Sat, 04 Apr 2026 12:26:57 +0000

Generic OAuth authentication

You can configure many different OAuth2 authentication services with Grafana using the generic OAuth2 feature. Examples:

Generic OAuth authentication

This callback URL must match the full HTTP address that you use in your browser to access Grafana, but with the suffixed path of /login/generic_oauth.

You may have to set the root_url option of [server] for the callback URL to be correct. For example in case you are serving Grafana behind a proxy.

Example config:

[auth.generic_oauth]
name = OAuth
icon = signin
enabled = true
client_id = YOUR_APP_CLIENT_ID
client_secret = YOUR_APP_CLIENT_SECRET
scopes =
empty_scopes = false
auth_url =
token_url =
api_url =
allowed_domains = mycompany.com mycompany.org
allow_sign_up = true
tls_skip_verify_insecure = false
tls_client_cert =
tls_client_key =
tls_client_ca =
use_pkce = true

Set api_url to the resource that returns OpenID UserInfo compatible information.

You can also specify the SSL/TLS configuration used by the client.

Set tls_client_cert to the path of the certificate.
Set tls_client_key to the path containing the key.
Set tls_client_ca to the path containing a trusted certificate authority list.

tls_skip_verify_insecure controls whether a client verifies the server’s certificate chain and host name. If it is true, then SSL/TLS accepts any certificate presented by the server and any host name in that certificate. You should only use this for testing, because this mode leaves SSL/TLS susceptible to man-in-the-middle attacks.

Set empty_scopes to true to use an empty scope during authentication. By default, Grafana uses user:email as scope.

Email address

Grafana determines a user’s email address by querying the OAuth provider until it finds an e-mail address:

Check for the presence of an e-mail address via the email field encoded in the OAuth id_token parameter.
Check for the presence of an e-mail address using the JMESPath specified via the email_attribute_path configuration option. The JSON used for the path lookup is the HTTP response obtained from querying the UserInfo endpoint specified via the api_url configuration option. Note: Only available in Grafana v6.4+.
Check for the presence of an e-mail address in the attributes map encoded in the OAuth id_token parameter. By default Grafana will perform a lookup into the attributes map using the email:primary key, however, this is configurable and can be adjusted by using the email_attribute_name configuration option.
Query the /emails endpoint of the OAuth provider’s API (configured with api_url), then check for the presence of an email address marked as a primary address.
If no email address is found in steps (1-4), then the email address of the user is set to an empty string.

Roles

Grafana checks for the presence of a role using the JMESPath specified via the role_attribute_path configuration option. The JMESPath is applied to the id_token first. If there is no match, then the UserInfo endpoint specified via the api_url configuration option is tried next. The result after evaluation of the role_attribute_path JMESPath expression should be a valid Grafana role, for example, Viewer, Editor or Admin.

For more information, refer to the JMESPath examples.

Groups / Teams

Similarly, group mappings are made using JMESPath with the groups_attribute_path configuration option. The id_token is attempted first, followed by the UserInfo from the api_url. The result of the JMESPath expression should be a string array of groups.

Furthermore, Grafana will check for the presence of at least one of the teams specified via the team_ids configuration option using the JMESPath specified via the team_ids_attribute_path configuration option. The JSON used for the path lookup is the HTTP response obtained from querying the Teams endpoint specified via the teams_url configuration option (using /teams as a fallback endpoint). The result should be a string array of Grafana Team IDs. Using this setting ensures that only certain teams is allowed to authenticate to Grafana using your OAuth provider.

Customize user login using login_attribute_path configuration option. Order of operations is as follows:

Grafana evaluates the login_attribute_path JMESPath expression against the ID token.
If Grafana finds no value, then Grafana evaluates expression against the JSON data obtained from UserInfo endpoint. The UserInfo endpoint URL is specified in the api_url configuration option.

You can customize the attribute name used to extract the ID token from the returned OAuth token with the id_token_attribute_name option.

You can set the user’s display name with JMESPath using the name_attribute_path configuration option. It operates the same way as the login_attribute_path option.

Note: name_attribute_path is available in Grafana 7.4+.

PKCE

Available in Grafana v8.3 and later versions.

IETF’s RFC 7636 introduces “proof key for code exchange” (PKCE) which introduces additional protection against some forms of authorization code interception attacks. PKCE will be required in OAuth 2.1.

You can enable PKCE in Grafana by setting use_pkce to true in the [auth.generic_oauth] section.

use_pkce = true

Grafana always uses the SHA256 based S256 challenge method and a 128 bytes (base64url encoded) code verifier.

Set up OAuth2 with Auth0

Create a new Client in Auth0
- Name: Grafana
- Type: Regular Web Application
Go to the Settings tab and set:
- Allowed Callback URLs: https://<grafana domain>/login/generic_oauth

Click Save Changes, then use the values at the top of the page to configure Grafana:

[auth.generic_oauth]
enabled = true
allow_sign_up = true
team_ids =
allowed_organizations =
name = Auth0
client_id = <client id>
client_secret = <client secret>
scopes = openid profile email
auth_url = https://<domain>/authorize
token_url = https://<domain>/oauth/token
api_url = https://<domain>/userinfo
use_pkce = true

Set up OAuth2 with Bitbucket

[auth.generic_oauth]
name = BitBucket
enabled = true
allow_sign_up = true
client_id = <client id>
client_secret = <client secret>
scopes = account email
auth_url = https://bitbucket.org/site/oauth2/authorize
token_url = https://bitbucket.org/site/oauth2/access_token
api_url = https://api.bitbucket.org/2.0/user
teams_url = https://api.bitbucket.org/2.0/user/permissions/workspaces
team_ids_attribute_path = values[*].workspace.slug
team_ids =
allowed_organizations =

Set up OAuth2 with Centrify

Create a new Custom OpenID Connect application configuration in the Centrify dashboard.
Create a memorable unique Application ID, e.g. “grafana”, “grafana_aws”, etc.
Put in other basic configuration (name, description, logo, category)
On the Trust tab, generate a long password and put it into the OpenID Connect Client Secret field.
Put the URL to the front page of your Grafana instance into the “Resource Application URL” field.
Add an authorized Redirect URI like https://your-grafana-server/login/generic_oauth
Set up permissions, policies, etc. just like any other Centrify app

Configure Grafana as follows:

[auth.generic_oauth]
name = Centrify
enabled = true
allow_sign_up = true
client_id = <OpenID Connect Client ID from Centrify>
client_secret = <your generated OpenID Connect Client Secret"
scopes = openid profile email
auth_url = https://<your domain>.my.centrify.com/OAuth2/Authorize/<Application ID>
token_url = https://<your domain>.my.centrify.com/OAuth2/Token/<Application ID>
api_url = https://<your domain>.my.centrify.com/OAuth2/UserInfo/<Application ID>

Set up OAuth2 with OneLogin

Create a new Custom Connector with the following settings:
- Name: Grafana
- Sign On Method: OpenID Connect
- Redirect URI: https://<grafana domain>/login/generic_oauth
- Signing Algorithm: RS256
- Login URL: https://<grafana domain>/login/generic_oauth
then:
Add an App to the Grafana Connector:
- Display Name: Grafana
then:

Under the SSO tab on the Grafana App details page you’ll find the Client ID and Client Secret.

Your OneLogin Domain will match the URL you use to access OneLogin.

Configure Grafana as follows:

[auth.generic_oauth]
name = OneLogin
enabled = true
allow_sign_up = true
client_id = <client id>
client_secret = <client secret>
scopes = openid email name
auth_url = https://<onelogin domain>.onelogin.com/oidc/2/auth
token_url = https://<onelogin domain>.onelogin.com/oidc/2/token
api_url = https://<onelogin domain>.onelogin.com/oidc/2/me
team_ids =
allowed_organizations =

JMESPath examples

To ease configuration of a proper JMESPath expression, you can test/evaluate expressions with custom payloads at http://jmespath.org/.

Role mapping

If therole_attribute_path property does not return a role, then the user is assigned the Viewer role by default. You can disable the role assignment by setting role_attribute_strict = true. It denies user access if no role or an invalid role is returned.

Basic example:

In the following example user will get Editor as role when authenticating. The value of the property role will be the resulting role if the role is a proper Grafana role, i.e. Viewer, Editor or Admin.

Payload:

{
    ...
    "role": "Editor",
    ...
}

Config:

role_attribute_path = role

Advanced example:

In the following example user will get Admin as role when authenticating since it has a role admin. If a user has a role editor it will get Editor as role, otherwise Viewer.

Payload:

{
    ...
    "info": {
        ...
        "roles": [
            "engineer",
            "admin",
        ],
        ...
    },
    ...
}

Config:

role_attribute_path = contains(info.roles[*], 'admin') && 'Admin' || contains(info.roles[*], 'editor') && 'Editor' || 'Viewer'

Groups mapping

Available in Grafana Enterprise v8.1 and later versions.

With Team Sync you can map your Generic OAuth groups to teams in Grafana so that the users are automatically added to the correct teams.

Generic OAuth groups can be referenced by group ID, like 8bab1c86-8fba-33e5-2089-1d1c80ec267d or myteam.

Learn more about Team Sync

Config:

groups_attribute_path = info.groups

Payload:

{
    ...
    "info": {
        ...
        "groups": [
            "engineers",
            "analysts",
        ],
        ...
    },
    ...
}

Google OAuth2 Authentication

Sat, 04 Apr 2026 12:26:57 +0000

Google OAuth2 Authentication

To enable Google OAuth2 you must register your application with Google. Google will generate a client ID and secret key for you to use.

Create Google OAuth keys

First, you need to create a Google OAuth Client:

Go to https://console.developers.google.com/apis/credentials.
Click Create Credentials, then click OAuth Client ID in the drop-down menu
Enter the following:
- Application Type: Web Application
- Name: Grafana
- Authorized JavaScript Origins: https://grafana.mycompany.com
- Authorized Redirect URLs: https://grafana.mycompany.com/login/google
- Replace https://grafana.mycompany.com with the URL of your Grafana instance.
Click Create
Copy the Client ID and Client Secret from the ‘OAuth Client’ modal

Enable Google OAuth in Grafana

Specify the Client ID and Secret in the Grafana configuration file. For example:

[auth.google]
enabled = true
client_id = CLIENT_ID
client_secret = CLIENT_SECRET
scopes = https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email
auth_url = https://accounts.google.com/o/oauth2/auth
token_url = https://accounts.google.com/o/oauth2/token
allowed_domains = mycompany.com mycompany.org
allow_sign_up = true

You may have to set the root_url option of [server] for the callback URL to be correct. For example in case you are serving Grafana behind a proxy.

Restart the Grafana back-end. You should now see a Google login button on the login page. You can now login or sign up with your Google accounts. The allowed_domains option is optional, and domains were separated by space.

You may allow users to sign-up via Google authentication by setting the allow_sign_up option to true. When this option is set to true, any user successfully authenticating via Google authentication will be automatically signed up.

You may specify a domain to be passed as hd query parameter accepted by Google’s OAuth 2.0 authentication API. Refer to Google’s OAuth documentation.

Azure AD OAuth2 authentication

Sat, 04 Apr 2026 12:26:57 +0000

Azure AD OAuth2 authentication

The Azure AD authentication allows you to use an Azure Active Directory tenant as an identity provider for Grafana. You can use Azure AD Application Roles to assign users and groups to Grafana roles from the Azure Portal. This topic has the following sections:

Create the Azure AD application

To enable the Azure AD OAuth2, register your application with Azure AD.

Log in to Azure Portal, then click Azure Active Directory in the side menu.
If you have access to more than one tenant, select your account in the upper right. Set your session to the Azure AD tenant you wish to use.
Under Manage in the side menu, click App Registrations > New Registration. Enter a descriptive name.
Under Redirect URI, select the app type Web.
Add the following redirect URLs https://<grafana domain>/login/azuread and https://<grafana domain> then click Register. The app’s Overview page opens.
Note the Application ID. This is the OAuth client ID.
Click Endpoints from the top menu.
- Note the OAuth 2.0 authorization endpoint (v2) URL. This is the authorization URL.
- Note the OAuth 2.0 token endpoint (v2). This is the token URL.
Click Certificates & secrets, then add a new entry under Client secrets with the following configuration.
- Description: Grafana OAuth
- Expires: Never
Click Add then copy the key value. This is the OAuth client secret.
Click Manifest, then define the required Application Role values for Grafana: Viewer, Editor, or Admin. If not defined, all users will have the Viewer role. Every role requires a unique ID which you can generate on Linux with uuidgen, and on Windows through Microsoft PowerShell with New-Guid.
Include the unique ID in the configuration file:

     "appRoles": [
     		{
     			"allowedMemberTypes": [
     				"User"
     			],
     			"description": "Grafana admin Users",
     			"displayName": "Grafana Admin",
     			"id": "SOME_UNIQUE_ID",
     			"isEnabled": true,
     			"lang": null,
     			"origin": "Application",
     			"value": "Admin"
     		},
     		{
     			"allowedMemberTypes": [
     				"User"
     			],
     			"description": "Grafana read only Users",
     			"displayName": "Grafana Viewer",
     			"id": "SOME_UNIQUE_ID",
     			"isEnabled": true,
     			"lang": null,
     			"origin": "Application",
     			"value": "Viewer"
     		},
     		{
     			"allowedMemberTypes": [
     				"User"
     			],
     			"description": "Grafana Editor Users",
     			"displayName": "Grafana Editor",
     			"id": "SOME_UNIQUE_ID",
     			"isEnabled": true,
     			"lang": null,
     			"origin": "Application",
     			"value": "Editor"
     		}
     	],

Go to Azure Active Directory and then to Enterprise Applications. Search for your application and click on it.
Click on Users and Groups and add Users/Groups to the Grafana roles by using Add User.

Enable Azure AD OAuth in Grafana

Add the following to the Grafana configuration file:

[auth.azuread]
name = Azure AD
enabled = true
allow_sign_up = true
client_id = APPLICATION_ID
client_secret = CLIENT_SECRET
scopes = openid email profile
auth_url = https://login.microsoftonline.com/TENANT_ID/oauth2/v2.0/authorize
token_url = https://login.microsoftonline.com/TENANT_ID/oauth2/v2.0/token
allowed_domains =
allowed_groups =

You can also use these environment variables to configure client_id and client_secret:

GF_AUTH_AZUREAD_CLIENT_ID
GF_AUTH_AZUREAD_CLIENT_SECRET

Note: Verify that the Grafana root_url is set in your Azure Application Redirect URLs.

Configure allowed groups

To limit access to authenticated users who are members of one or more groups, set allowed_groups to a comma- or space-separated list of group object IDs. You can find object IDs for a specific group on the Azure portal:

Go to Azure Active Directory -> Groups. If you want to only give access to members of the group example with an ID of 8bab1c86-8fba-33e5-2089-1d1c80ec267d, then set the following:
```
allowed_groups = 8bab1c86-8fba-33e5-2089-1d1c80ec267d
```
Verify that group attributes is enabled in your Azure AD Application Registration manifest file by navigating to Azure Portal > Azure Active Directory > Application Registrations > Select Application -> Manifest, and set the following:
```
"groupMembershipClaims": "ApplicationGroup, SecurityGroup"
```

Configure allowed domains

The allowed_domains option limits access to users who belong to specific domains. Separate domains with space or comma. For example,

allowed_domains = mycompany.com mycompany.org

Team Sync (Enterprise only)

With Team Sync you can map your Azure AD groups to teams in Grafana so that your users will automatically be added to the correct teams.

You can reference Azure AD groups by group object ID, like 8bab1c86-8fba-33e5-2089-1d1c80ec267d.

To learn more, refer to the Team Sync documentation.

GitHub OAuth2 Authentication

Sat, 04 Apr 2026 12:26:57 +0000

GitHub OAuth2 Authentication

To enable the GitHub OAuth2 you must register your application with GitHub. GitHub will generate a client ID and secret key for you to use.

Configure GitHub OAuth application

You need to create a GitHub OAuth application (you will find this under the GitHub settings page). When you create the application you will need to specify a callback URL. Specify this as callback:

http://<my_grafana_server_name_or_ip>:<grafana_server_port>/grafana/login/github

This callback URL must match the full HTTP address that you use in your browser to access Grafana, but with the suffix path of /login/github. When the GitHub OAuth application is created you will get a Client ID and a Client Secret. Specify these in the Grafana configuration file. For example:

Enable GitHub in Grafana

[auth.github]
enabled = true
allow_sign_up = true
client_id = YOUR_GITHUB_APP_CLIENT_ID
client_secret = YOUR_GITHUB_APP_CLIENT_SECRET
scopes = user:email,read:org
auth_url = https://github.com/login/oauth/authorize
token_url = https://github.com/login/oauth/access_token
api_url = https://api.github.com/user
team_ids =
allowed_organizations =

You may have to set the root_url option of [server] for the callback URL to be correct. For example in case you are serving Grafana behind a proxy.

Restart the Grafana back-end. You should now see a GitHub login button on the login page. You can now login or sign up with your GitHub accounts.

You may allow users to sign-up via GitHub authentication by setting the allow_sign_up option to true. When this option is set to true, any user successfully authenticating via GitHub authentication will be automatically signed up.

team_ids

Require an active team membership for at least one of the given teams on GitHub. If the authenticated user isn’t a member of at least one of the teams they will not be able to register or authenticate with your Grafana instance. For example:

[auth.github]
enabled = true
client_id = YOUR_GITHUB_APP_CLIENT_ID
client_secret = YOUR_GITHUB_APP_CLIENT_SECRET
scopes = user:email,read:org
team_ids = 150,300
auth_url = https://github.com/login/oauth/authorize
token_url = https://github.com/login/oauth/access_token
api_url = https://api.github.com/user
allow_sign_up = true

allowed_organizations

Require an active organization membership for at least one of the given organizations on GitHub. If the authenticated user isn’t a member of at least one of the organizations they will not be able to register or authenticate with your Grafana instance. For example

[auth.github]
enabled = true
client_id = YOUR_GITHUB_APP_CLIENT_ID
client_secret = YOUR_GITHUB_APP_CLIENT_SECRET
scopes = user:email,read:org
auth_url = https://github.com/login/oauth/authorize
token_url = https://github.com/login/oauth/access_token
api_url = https://api.github.com/user
allow_sign_up = true
# space-delimited organization names
allowed_organizations = github google

Team Sync (Enterprise only)

Only available in Grafana Enterprise v6.3+

With Team Sync you can map your GitHub org teams to teams in Grafana so that your users will automatically be added to the correct teams.

Your GitHub teams can be referenced in two ways:

https://github.com/orgs/<org>/teams/<slug>
@<org>/<slug>

Example: @grafana/developers

Learn more about Team Sync

GitLab OAuth2 Authentication

Sat, 04 Apr 2026 12:26:57 +0000

GitLab OAuth2 Authentication

To enable GitLab OAuth2 you must register the application in GitLab. GitLab will generate a client ID and secret key for you to use.

Create GitLab OAuth keys

You need to create a GitLab OAuth application. Choose a descriptive Name, and use the following Redirect URI:

https://grafana.example.com/login/gitlab

where https://grafana.example.com is the URL you use to connect to Grafana. Adjust it as needed if you don’t use HTTPS or if you use a different port; for instance, if you access Grafana at http://203.0.113.31:3000, you should use

http://203.0.113.31:3000/login/gitlab

Finally, select read_api_as the_Scope_and submit the form. Note that if you’re not going to use GitLab groups for authorization (i.e. not setting allowed_groups, see below), you can select_read_user instead of read_api_as the_Scope, thus giving a more restricted access to your GitLab API.

You’ll get an Application Id and a Secret in return; we’ll call them GITLAB_APPLICATION_ID and GITLAB_SECRET respectively for the rest of this section.

Enable GitLab in Grafana

Add the following to your Grafana configuration file to enable GitLab authentication:

[auth.gitlab]
enabled = true
allow_sign_up = false
client_id = GITLAB_APPLICATION_ID
client_secret = GITLAB_SECRET
scopes = read_api
auth_url = https://gitlab.com/oauth/authorize
token_url = https://gitlab.com/oauth/token
api_url = https://gitlab.com/api/v4
allowed_groups =

You may have to set the root_url option of [server] for the callback URL to be correct. For example in case you are serving Grafana behind a proxy.

Restart the Grafana backend for your changes to take effect.

If you use your own instance of GitLab instead of gitlab.com, adjust auth_url, token_url and api_url accordingly by replacing the gitlab.com hostname with your own.

With allow_sign_up set to false, only existing users will be able to login using their GitLab account, but with allow_sign_up set to true, any user who can authenticate on GitLab will be able to login on your Grafana instance; if you use the public gitlab.com, it means anyone in the world would be able to login on your Grafana instance.

You can limit access to only members of a given group or list of groups by setting the allowed_groups option.

allowed_groups

To limit access to authenticated users that are members of one or more GitLab groups, set allowed_groups to a comma- or space-separated list of groups. For instance, if you want to only give access to members of the example group, set

allowed_groups = example

If you want to also give access to members of the subgroup bar, which is in the group foo, set

allowed_groups = example, foo/bar

Note that in GitLab, the group or subgroup name doesn’t always match its display name, especially if the display name contains spaces or special characters. Make sure you always use the group or subgroup name as it appears in the URL of the group or subgroup.

Here’s a complete example with allow_sign_up enabled, with access limited to the example and foo/bar groups. The example also promotes all GitLab Admins to Grafana Admins:

[auth.gitlab]
enabled = true
allow_sign_up = true
client_id = GITLAB_APPLICATION_ID
client_secret = GITLAB_SECRET
scopes = read_api
auth_url = https://gitlab.com/oauth/authorize
token_url = https://gitlab.com/oauth/token
api_url = https://gitlab.com/api/v4
allowed_groups = example, foo/bar
role_attribute_path = is_admin && 'Admin' || 'Viewer'

Map roles

You can use GitLab OAuth to map roles. During mapping, Grafana checks for the presence of a role using the JMESPath specified via the role_attribute_path configuration option.

For the path lookup, Grafana uses JSON obtained from querying GitLab’s API /api/v4/user endpoint. The result of evaluating the role_attribute_path JMESPath expression must be a valid Grafana role, for example, Viewer, Editor or Admin. For more information about roles and permissions in Grafana, refer to Organization roles.

An example Query could look like the following:

role_attribute_path = is_admin && 'Admin' || 'Viewer'

This allows every GitLab Admin to be an Admin in Grafana.

Team Sync (Enterprise only)

Only available in Grafana Enterprise v6.4+

With Team Sync you can map your GitLab groups to teams in Grafana so that your users will automatically be added to the correct teams.

Your GitLab groups can be referenced in the same way as allowed_groups, like example or foo/bar.

Learn more about Team Sync

Okta OAuth2 authentication

Sat, 04 Apr 2026 12:26:57 +0000

Okta OAuth2 authentication

Only available in Grafana v7.0+

The Okta authentication allows your Grafana users to log in by using an external Okta authorization server.

Create an Okta application

Before you can sign a user in, you need to create an Okta application from the Okta Developer Console.

Log in to the Okta portal.
Go to Admin and then select Developer Console.
Select Applications, then Add Application.
Pick Web as the platform.
Enter a name for your application (or leave the default value).
Add the Base URI of your application, such as https://grafana.example.com.
Enter values for the Login redirect URI. Use Base URI and append it with /login/okta, for example: https://grafana.example.com/login/okta.
Click Done to finish creating the Okta application.

Enable Okta OAuth in Grafana

Add the following to the Grafana configuration file:

[auth.okta]
name = Okta
icon = okta
enabled = true
allow_sign_up = true
client_id = some_id
client_secret = some_secret
scopes = openid profile email groups
auth_url = https://<tenant-id>.okta.com/oauth2/v1/authorize
token_url = https://<tenant-id>.okta.com/oauth2/v1/token
api_url = https://<tenant-id>.okta.com/oauth2/v1/userinfo
allowed_domains =
allowed_groups =
role_attribute_path =

Configure allowed groups and domains

To limit access to authenticated users that are members of one or more groups, set allowed_groups to a comma- or space-separated list of Okta groups.

allowed_groups = Developers, Admins

The allowed_domains option limits access to the users belonging to the specific domains. Domains should be separated by space or comma.

allowed_domains = mycompany.com mycompany.org

Map roles

Grafana can attempt to do role mapping through Okta OAuth. In order to achieve this, Grafana checks for the presence of a role using the JMESPath specified via the role_attribute_path configuration option.

Grafana uses JSON obtained from querying the /userinfo endpoint for the path lookup. The result after evaluating the role_attribute_path JMESPath expression needs to be a valid Grafana role, i.e. Viewer, Editor or Admin. Refer to Organization roles for more information about roles and permissions in Grafana.

Read about how to add custom claims to the user info in Okta. Also, check Generic OAuth page for JMESPath examples.

Team Sync (Enterprise only)

Map your Okta groups to teams in Grafana so that your users will automatically be added to the correct teams.

Okta groups can be referenced by group name, like Admins.

Learn more about Team Sync

SAML Authentication

Sat, 04 Apr 2026 12:26:57 +0000

SAML authentication

The SAML authentication integration allows your Grafana users to log in by using an external SAML Identity Provider (IdP). To enable this, Grafana becomes a Service Provider (SP) in the authentication flow, interacting with the IdP to exchange user information.

SAML authentication integration is available in Grafana Cloud Pro and Advanced and in Grafana Enterprise. For more information, refer to SAML authentication in Grafana Enterprise.

Team Sync

Sat, 04 Apr 2026 12:26:57 +0000

Team sync

With Team Sync, you can set up synchronization between your auth provider’s teams and teams in Grafana. This enables LDAP or GitHub OAuth users which are members of certain teams/groups to automatically be added/removed as members to certain teams in Grafana. Currently the synchronization will only happen every time a user logs in, unless LDAP is used together with active background synchronization that was added in Grafana 6.3.

Grafana keeps track of all synchronized users in teams and you can see which users have been synchronized in the team members list, see LDAP label in screenshot. This mechanism allows Grafana to remove an existing synchronized user from a team when its LDAP group membership (for example) changes. This mechanism also enables you to manually add a user as member of a team and it will not be removed when the user signs in. This gives you flexibility to combine LDAP group memberships and Grafana team memberships.

Team Sync is available in both Grafana Enterprise and Grafana Cloud Advanced. For more information, refer to Team sync in Grafana Enterprise.

Authentication on Grafana Labs

Overview

User Authentication Overview

Grafana Auth

Login and short-lived tokens

Remote logout

Settings

Anonymous authentication

Basic authentication

Disable login form

Automatic OAuth login

Avoid automatic OAuth login

Hide sign-out menu

URL redirect after signing out

Grafana Authentication

Grafana Auth

Login and short-lived tokens

Remote logout

Settings

Anonymous authentication

Basic authentication

Disable login form

Automatic OAuth login

Hide sign-out menu

URL redirect after signing out

Auth Proxy

Auth Proxy Authentication

Interacting with Grafana’s AuthProxy via curl

Making Apache’s auth work together with Grafana’s AuthProxy

Apache BasicAuth

Apache configuration

Full walkthrough using Docker.

Apache Container

Use grafana.

Team Sync (Enterprise only)

Login token and session cookie

JWT Authentication

JWT authentication

Enable JWT

Configure login claim

Signature verification

Verify token using a JSON Web Key Set loaded from https endpoint

Verify token using a JSON Web Key Set loaded from JSON file

Verify token using a single key loaded from PEM-encoded file

Validate claims

LDAP Authentication

LDAP Authentication

Supported LDAP Servers

Enable LDAP

Grafana LDAP Configuration

Using environment variables

LDAP Debug View

Bind

Bind and Bind Password

Single Bind Example

POSIX schema

Group Mappings

Nested/recursive group membership

Configuration examples

OpenLDAP

Multiple LDAP servers

Active Directory

Port requirements

Troubleshooting

Enhanced LDAP Integration

Enhanced LDAP integration

OAuth authentication

Generic OAuth authentication

Email address

Roles

Groups / Teams

Login

PKCE

Set up OAuth2 with Auth0

Set up OAuth2 with Bitbucket

Set up OAuth2 with Centrify

Set up OAuth2 with OneLogin

JMESPath examples

Role mapping

Groups mapping