Important: This documentation is about an older version. It's relevant only to the release noted, many of the features and functions have been updated or replaced. Please view the current version.

DocumentationGrafana Enterprise Metrics DocumentationOAuth Integration

OAuth Integration

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.

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.

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.

Config

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

yaml Copy

auth:
  type: enterprise
  admin:
    oidc:
      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

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

The extracted access policy is 1234567890.

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 instances contained in the original access policies. For example, given the following JWT and config above:

json Copy

{
  "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 instance-1, and 9876543210 provided read and write access to instance-2 and instance-3, the resulting virtual access policy would provide read-only access to instance-1, instance-2, and instance-3. This generated access policy is cached for the period specified in auth.cache.ttl.duration, which defaults to 10m.