---
title: "Integrate with OAuth | Grafana Enterprise Metrics documentation"
description: "Integrate with OAuth Grafana Enterprise Metrics supports the OpenID Connect (OIDC) core standard to validate tokens. This allows you to integrate GEM with an existing OAuth token provider at your organization."
---

# Integrate with OAuth

Grafana Enterprise Metrics supports the [**OpenID Connect (OIDC)**](https://openid.net/specs/openid-connect-core-1_0.html) core standard to validate tokens. This allows you to integrate GEM with an existing OAuth token provider at your organization.

To support OIDC, provide the URL of the OIDC provider (issuer) in the `auth.admin.oidc.issuer-url` setting. The provider is required to have the OIDC Discovery endpoint (also known as “well known endpoint”) at `<issuer-url>/.well-known/openid-configuration`, as described [in the openid standard](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig).

A JWT is included as the password in HTTP basic authentication or as part of a bearer token in bearer authentication. The bearer token should have two parts separated by a `:`. The first part is the tenant ID. The second part is the JWT.

The JWT is validated against the OIDC provider specified above. If it is valid then an access policy name is extracted. The regular expression in `auth.admin.oidc.access_policy_regex` is run against each value in the the JWT claim field specified in `auth.admin.oidc.access_policy_claim`, which can either be a single string or a list of strings.

A sub-match has to be present to extract the access policy. If the value in the JWT claim field is a string, then only the first sub-match is used. If it is a list of strings, then the first submatch for each entry is used. You can use the regular expression `(.*)` for the whole claim field.

The regular expression syntax is [RE2](https://github.com/google/re2/wiki/Syntax).

## Configuration

To use OIDC, specify the `auth.type` as `enterprise`. Here is an example authentication section:

YAML ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy

```yaml
auth:
  type: enterprise
  admin:
    oidc:
      issuer_url: https://accounts.authprovider.com/realms/example
      access_policy_claim: "sub"
      access_policy_regex: "pref-([0-9]+)-.*"
```

Here is an example payload section of a valid JWT:

JSON ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy

```json
{
  "sub": "pref-1234567890-abc",
  "name": "John Doe",
  "admin": true
}
```

The extracted access policy is `1234567890`.

> **Note:** OpenID Connect (OIDC) converts the encoded access policies to lowercase (`downcase`). For example, if your OpenID system has an access policy called `Team1`, then you need to create an access policy in GEM called `team1` so the integration works.

## Multiple access policies

It is possible to provide an array of strings in the JWT claim field. If this array only includes one item, then the behavior is the same as when providing a string in this field. In the case where multiple access policies are provided as a list in the JWT claim field, they will be aggregated into a “virtual” access policy. This “virtual” access policy will provide metric read access to the union of all tenants contained in the original access policies. For example, given the following JWT and config above:

JSON ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy

```json
{
  "sub": ["pref-1234567890-abc", "pref-9876543210-xyz"],
  "name": "John Doe",
  "admin": true
}
```

The resulting access policy would be an aggregate of `1234567890` and `9876543210`. If `1234567890` provided read and write access to `tenant-1`, and `9876543210` provided read and write access to `tenant-2` and `tenant-3`, the resulting virtual access policy would provide read-only access to `tenant-1`, `tenant-2`, and `tenant-3`. This generated access policy is cached for the period specified in `auth.cache.ttl.duration`, which defaults to `10m`.