Keycloak and Grafana SSO integration: what it does and which method to use
The supported method for signing in to self-hosted Grafana with Keycloak is generic OAuth2 over OpenID Connect, with Keycloak as the identity provider. This method works on the open-source edition of Grafana, and Grafana's authentication documentation lists generic OAuth as available in every edition. If your team already runs Grafana and Keycloak and wants one login and one place to assign access, this is the path to plan for. Keycloak is licensed under Apache 2.0, so both components can run under open-source terms in infrastructure you control.
The integration covers four areas. The first is sign-in, where Grafana redirects users to a Keycloak client and receives identity from the returned token. The second is role assignment through the role_attribute_path setting, which evaluates an expression against token claims to set a user's Grafana role. That expression only works if Keycloak emits the claim it reads, so your team must design a client scope and protocol mapper in Keycloak before Grafana can assign roles. The third is logout, which covers what happens in Grafana and Keycloak when a user signs out. The fourth is token lifetime, which determines how often a session must be renewed. Confirm the exact expression syntax, logout options and refresh behavior against the documentation for the Grafana release you will run, because these settings change between releases.
The integration does not cover team sync without an enterprise license. Grafana's authentication documentation states that team sync, along with SAML, active sync and SCIM provisioning, is available only in Grafana Enterprise and Grafana Cloud. If your requirement is that Keycloak groups populate Grafana teams automatically, you need to choose between one of those paid editions and a manual or scripted team model in the open-source edition. Ask Grafana Labs to confirm current licensing terms and pricing for the edition you choose, since a quote should follow from a written scope rather than from assumptions about what a tier includes.
Decide the method and the team model before the build starts. The questions to settle are whether role mapping from Keycloak claims meets your access requirements, whether team membership can stay manual for now, and which Grafana release line you will standardize on. Grafana's upgrade guidance says each minor release is supported for 9 months, so the upgrade plan should be part of the design, not an afterthought. Also confirm that your Grafana database and hosting model support the Keycloak redirect URLs and HTTPS endpoints you plan to use.
What you need in place before configuring Grafana and Keycloak
Grafana and Keycloak each need a working baseline before any SSO settings are changed. The cards below cover the servers, databases, realm content, DNS and admin access that the integration depends on, so that problems later in the configuration can be traced to the integration itself.
A Keycloak server on a supported release
Run a Keycloak release that is still receiving updates. The current release noted for this page is 26.8.1, published October 13, 2026, so confirm your installed version against the Keycloak release list before you start. Serve all Keycloak traffic over TLS, because OpenID Connect token exchange and the Grafana redirect flow both depend on HTTPS endpoints. Check that your production database is one Keycloak supports, not the default development file database.
A Grafana server on a supported version
Install a Grafana version that is still within its support window. Grafana publishes a release cadence and support periods, so the Grafana team should confirm the current version against the Grafana release list and upgrade guidance before configuration begins. Plan for a production database, which means MySQL 8.0 or later or PostgreSQL 12 or later. SQLite is the default but is not suitable for production, and the same database choice matters if you later run Grafana in high availability.
A production database for Grafana
Grafana stores users, sessions and configuration in its database, so the external database must exist before the OAuth settings are saved. Create a dedicated database and account for Grafana, confirm backup coverage, and test a restore. Teams that already run a managed MySQL or PostgreSQL service should confirm that the engine version meets the minimums above and that the service is reachable from the Grafana host.
A Keycloak realm with test users and groups
Create a dedicated realm for Grafana rather than testing in the master realm. Add a small set of test users that represent each Grafana role you plan to assign, along with the groups or client roles that will drive role mapping. Confirm that these users can sign in to the Keycloak account console. Keeping test identities separate from production accounts makes it easier to verify role mapping without changing real access.
A DNS name and certificate for Grafana
Choose the public URL that users will open for Grafana, such as a dedicated hostname, and publish a DNS record for it. Issue a certificate that matches that exact hostname. The redirect URI registered in the Keycloak client must match the Grafana root URL character for character, including scheme, host, port and path, or the authorization response will fail. Decide this name before you configure either side, because changing it later means updating both the Grafana root URL and the Keycloak client.
Administrator access to both consoles
Confirm that the people doing the work hold administrator rights in both the Keycloak admin console and the Grafana server. The Keycloak work requires creating a client, mappers and roles in the target realm. The Grafana work requires editing the server configuration file or environment variables and restarting the service. Also confirm who will approve changes to production realms and who can read the client secret after it is created, since the secret must be stored outside the configuration in a managed way.
How Grafana uses generic OAuth to trust Keycloak logins
Grafana does not check passwords for Keycloak users. It hands the sign-in to Keycloak and accepts the result, which means the trust relationship is built on the OpenID Connect authorization code flow. In plain terms, the browser sends the user to Keycloak, the user authenticates there with whatever methods the realm allows, and Keycloak sends the browser back to Grafana with a one-time authorization code. Grafana then calls the Keycloak token endpoint directly from the server over the back channel, so tokens never pass through the browser. From the returned ID token, or from the user info endpoint, Grafana reads the identity claims it needs, including the user's name, email and the claim that carries roles.
Grafana keeps its own user record and its own session after that exchange. The user row in Grafana's database, the role assigned to it and the session cookie all belong to Grafana. This is why a change made in Keycloak, such as disabling an account, removing a realm role or moving a user to another group, does not take effect in Grafana the moment it happens. Grafana picks up the change when the user next logs in, when the access token is refreshed if refresh is in use, or when the session expires. Teams planning an offboarding procedure should treat Keycloak as the source of truth and Grafana as a consumer that catches up on its own schedule, then confirm the session lifetime they configure in both products.
The generic OAuth provider in Grafana covers this entire path. According to the Grafana authentication documentation, generic OAuth is among the methods supported in every Grafana edition, so the login flow described here does not require Grafana Enterprise or Grafana Cloud. Enterprise and Cloud matter for other features, such as syncing Keycloak groups into Grafana teams, which is covered elsewhere on this page. Before go-live, confirm with your own Grafana version that the generic OAuth options you plan to use, including the authorization, token and user info URLs and the scopes requested, match the Keycloak client you have registered.
Decisions to make early are the client type, the scopes, and where the identity claims are read. A confidential client with a client secret stored in Grafana's configuration is the usual pattern for a server-side application like Grafana. Your team should also decide whether to read identity from the ID token or the user info endpoint, and confirm that the claims Grafana depends on are present in whichever source you pick. Checking this during a test login with a user who holds the expected realm roles avoids discovering a missing claim after users have been onboarded.
Setting up Keycloak and Grafana SSO step by step
This sequence connects Grafana to a Keycloak realm using generic OAuth2 and maps Keycloak roles to Grafana's Admin, Editor and Viewer roles. The result is a tested sign-in where each test user lands in Grafana with the role their Keycloak assignment should give them.
Create a confidential OpenID Connect client
In the target realm of your Keycloak instance, create an OpenID Connect client with client authentication turned on, so it is confidential and has a client secret. Set the valid redirect URI to your Grafana host followed by the generic OAuth callback path, and set web origins to the same Grafana origin. Confirm the client shows the standard authorization code flow enabled and that the secret is stored in your secrets manager, not in a shared document. Done correctly, the client's settings page lists the callback as the only redirect URI, and the Keycloak well-known endpoint for the realm lists the authorization, token and userinfo URLs you will paste into Grafana.
Add mappers for identity and role claims
Add protocol mappers to the client so the tokens carry the claims Grafana reads. Map the email, given name, family name and username attributes, and add a realm role mapper that writes roles into a top-level claim such as roles. Turn on the option to add the claim to the userinfo endpoint as well as the ID token, because Grafana's generic OAuth integration reads user details from the userinfo response by default. Check the result by signing in once with a test account in a browser, then calling the userinfo endpoint with the access token. The response should contain the email and the roles array. If the roles claim is missing, the mapper is probably scoped to the wrong client or only added to the ID token.
Create test users with intended roles
Create at least three test users in the same realm, one for each Grafana role you plan to use. Assign each user a distinct realm role that matches your access model, for example a Grafana administrator role, an editor role and a viewer role, and keep the names identical to what your mapping expression will test. Include one user with no Grafana role assigned so you can see how the default behavior works. Document each user's expected Grafana role in a short table before you test. The check for this step is that the userinfo response for each test user shows exactly the role names you assigned, and nothing from another user's account appears in the output.
Configure Grafana's generic OAuth section
In Grafana's configuration file, enable the generic OAuth provider and set its name, client ID and client secret from the Keycloak client. Point the authorization, token and API URLs at the endpoints of your realm, which follow Keycloak's standard OpenID Connect path layout. Set the scopes to include openid, profile and email, plus any scope that carries your roles claim if you added one as a client scope. Restart Grafana after editing the file, then open the login page and confirm the Keycloak sign-in button appears. Grafana's configuration documentation covers the full list of keys and whether your version reads them from the environment as well. Success is a button that starts the Keycloak login and returns you to Grafana without an error page.
Map claims to roles with role_attribute_path
Set role_attribute_path in the generic OAuth section to a JMESPath expression that reads the roles claim and returns Admin, Editor or Viewer. An illustrative expression tests whether the roles array contains your administrator role name first, then the editor role name, and falls back to Viewer otherwise. Keep the role names in the expression identical to the Keycloak realm roles from the earlier step, and check the expression against a sample token in a JMESPath tester before you deploy it. Also decide whether an unmatched user should be denied or given Viewer, and set allow sign up according to your onboarding policy. You know the mapping works when the decoded sample payload produces the role string you expect for each test user.
Test login and confirm each role
Sign in to Grafana once with each test user in a private browser session, starting from the Keycloak login page. After each login, open the organization's user list as an administrator and compare the role shown for that account with the one you documented in the test table. Repeat the test after changing a user's Keycloak role, because the role in Grafana should update at the next login. Check that the user without a mapped role is handled according to the policy you chose. Record the results, including any mismatch, and keep the expression and client settings under version control so later changes can be tested the same way. The step is complete when every test user's Grafana role matches its expected value.
Keycloak claims, Grafana roles and what each setting controls
This table traces each data item from its source in Keycloak to its target in Grafana, and shows who sets it and what to verify. Read it top to bottom as the order in which a login token is produced, mapped and applied. The main takeaway is that the role_attribute_path expression is only as reliable as the claim it reads, so confirm the exact claim names with real tokens before relying on any default role.
| Data item | Source and target | Who sets it | What to verify |
|---|---|---|---|
| Login identifier | Keycloak email or username claim to the Grafana login and user record | Both: Keycloak client mapper defines the claim, Grafana configuration selects it | Confirm the claim name in a decoded ID token and that it stays unique per user |
| Display name | Keycloak name claim to the Grafana display name | Both: Keycloak mapper supplies the claim, Grafana name attribute setting maps it | Confirm first and last name populate for test users created by hand and through federation |
| Realm roles | Keycloak realm role list in the token to the role_attribute_path expression | Keycloak mapper controls what is emitted, Grafana configuration controls the JMESPath expression | Test the expression against a token for each role and check the result is Admin, Editor or Viewer |
| Client roles | Keycloak client role list in the token to the role_attribute_path expression | Both: Keycloak client scope and mapper decide the path, Grafana expression reads it | Confirm the nested path matches the token structure and that roles from other clients are ignored |
| Role resolution order | Grafana evaluates the expression and applies the first matching role | Grafana configuration, with role precedence set by the expression | Check that a user holding several roles receives the highest intended role, not the first one listed |
| Default role | Role applied when no claim matches the expression | Grafana configuration (role_attribute_strict and default settings) | Confirm behavior when no role is present and whether strict mode blocks login instead |
| Organization assignment | Grafana org to which the user is added at login | Grafana configuration, with optional org mapping in the expression | Verify the user lands in the intended org and that existing memberships are not removed unexpectedly |
| Team membership | Keycloak groups to Grafana teams | Grafana Enterprise or Cloud team sync only | Confirm the edition supports team sync before designing any group based mapping |
Why team sync from Keycloak groups needs Grafana Enterprise or Grafana Cloud
Team sync is the part of a Keycloak and Grafana design that depends on the Grafana edition you run, not on Keycloak. Grafana's authentication documentation lists generic OAuth among the methods available in every edition, so signing users in through Keycloak and mapping roles with role_attribute_path works on the open-source edition. The team sync feature, which places users into Grafana teams based on group membership in the identity provider, is listed as available only in Grafana Enterprise and Grafana Cloud. The same page places SAML, active sync and SCIM provisioning in that paid group, so a plan that assumes any of them on open source needs revisiting before build starts.
In practice, the open-source edition gives you one mechanism for authorization from Keycloak claims: role_attribute_path, which reads a JMESPath expression against the token or user info response and returns Viewer, Editor or Admin. Keycloak groups can feed that expression if the groups claim is present in the token, so role assignment can follow group membership. What open source does not give you is automatic creation of Grafana teams from those groups, so folder permissions and team-scoped dashboards must be managed by hand or through another process. Teams that expected group-driven team membership will need to decide whether to accept manual team administration, buy an edition that supports it, or narrow their access model to roles only.
Confirm current edition entitlements with Grafana Labs before you finalize the design. The authentication documentation and the licensing page describe the feature split at the time of publication, and Grafana's edition packaging can change between releases, so ask for written confirmation that team sync is included in the specific Enterprise or Cloud tier you are considering. Ask also whether the feature depends on any particular Grafana version, because the group mapping behavior you test in one release may not match another.
Cost planning needs two separate lines. The Grafana pricing page lists an Enterprise tier on Grafana Cloud with a minimum commitment of 25,000 US dollars per year, in addition to a Pro tier that starts with a 19 US dollar monthly platform fee plus usage. A self-managed Grafana Enterprise license is a separate purchase from a Cloud subscription, so buying Enterprise for a server you run does not give you Cloud Enterprise terms, and the reverse is also true. Ask Grafana Labs for the quote that matches your hosting model and confirm whether the license is priced per user, per instance or by another measure. DeployOpen can plan and implement the Keycloak client, claim mapping and Grafana configuration, but the license decision and its cost sit with your organization and Grafana Labs.
Plan for the decision to be revisited. If your team sync requirement is firm, establish the edition question at the start of the project so the Keycloak group model, the role mapping and the team structure are designed against the feature you will actually run. If the requirement is soft, build the role mapping first, which works on any edition, and document the manual team steps so an upgrade in edition later does not force a redesign of the group structure in Keycloak.
Security settings for Keycloak-backed Grafana logins
The settings below protect the Grafana login path from the browser to the token exchange, and from the token to the Grafana role. Each card names one control, what it guards against, and what to check in the Keycloak client, the realm and the Grafana configuration. Option names change between releases, so confirm each one against the current Keycloak and Grafana documentation for the versions you run.
TLS and Grafana hardening settings
Serve Grafana and Keycloak only over TLS, including the browser redirect path, the token endpoint and the metrics endpoint. Keycloak's production guide expects TLS on all communication. Then apply the Grafana security hardening settings: secure and SameSite cookies, a Content Security Policy, hidden version details on unauthenticated pages, and authentication on the metrics endpoint. Confirm each option name against the current Grafana docs for your version before you write the configuration.
Strict redirect URI list
Register each Grafana callback URL in the Keycloak client as an exact value, including scheme, host, port and path. Wildcards in valid redirect URIs or web origins can let an attacker receive authorization codes, so leave them out. Keep one entry for each Grafana hostname your team uses, and remove test or retired hostnames when environments change. The Grafana root URL setting must match the registered callback exactly, so check both sides after any DNS, proxy or load balancer change.
Client secret outside configuration
Grafana connects to Keycloak as a confidential client, so its client secret must stay out of grafana.ini, Helm values files and Git repositories. Store it in the secrets manager your platform already runs, and inject it into the Grafana process at startup, for example through environment variables sourced from that store. Rotate the secret in Keycloak and the secrets store together. Confirm that Grafana logs do not print the secret during startup or error handling, and confirm the option name against the current docs.
Access token lifetimes and refresh
Set access token lifetimes in the Keycloak realm to a short period your security policy accepts. Then confirm whether the realm issues refresh tokens to the Grafana client, how long idle and maximum SSO sessions last, and whether refresh token rotation is enabled. Long-lived tokens widen the window for a stolen token, while very short lifetimes add refresh traffic and can interrupt long dashboard sessions. Test a session that stays open across an access token expiry to confirm the behavior you configured.
Single logout when required
Logging out of Grafana does not end the Keycloak session unless you configure it to. If your team requires that closing Grafana also ends the Keycloak session, set the logout behavior in Grafana's OAuth settings and the matching logout URL and logout options on the Keycloak client. Test with two browsers to confirm that logout in one ends the other. Confirm each option name against the current Grafana and Keycloak docs, because browser cookie restrictions can affect the result.
Role claims limited to Admin
Grafana's generic OAuth role mapping reads a role_attribute_path expression against the token claims. Build the role claim in Keycloak from groups that should reach the Admin role, and map only those groups to Admin, with Editor and Viewer mapped separately. Avoid mapping broad groups such as all employees to Admin. Confirm the default role for users without a matching claim in the current docs. Check the claim in a test token before rollout, and note that team sync from Keycloak groups requires Grafana Enterprise or Grafana Cloud.
Common Grafana and Keycloak SSO failures and how to fix them
This table lists the sign-in and role failures teams most often hit when Grafana uses Keycloak through generic OAuth2, with the likely cause, the check to run and the fix for each. Work through the checks in order, starting with the token and Grafana logs, because most failures show a clear message in one of those two places. Most of them trace back to a mismatch between what Keycloak issues and what Grafana expects.
| Failure | Likely cause and check | Fix |
|---|---|---|
| Redirect URI mismatch | Keycloak rejects the login with an invalid redirect URI error. The Valid redirect URIs entry in the Keycloak client does not exactly match the callback Grafana sends, which is built from root_url and the /login/generic_oauth path. Check the Keycloak event log for the rejected request. | Set Valid redirect URIs to the exact callback URL, including scheme, host, port and path. Keep it identical to the URL Grafana builds from its root URL setting. |
| Root URL does not match the public hostname | Grafana redirects to an internal address or the browser lands on a port or scheme that does not match the public hostname behind a reverse proxy. Check the Grafana server settings and the Location header of the redirect in the browser network trace. | Set root_url in the Grafana server section to the public HTTPS address users see. Make the reverse proxy forward the original host and protocol headers so Grafana builds the same URL. |
| Client secret mismatch | The token exchange fails and the Grafana log shows an error from the token endpoint, often a 401 response. The client_secret in Grafana does not match the credential stored in the Keycloak client, or the secret was rotated in Keycloak only. Check the Grafana log line for the token request. | Copy the current secret from the Keycloak client credentials tab into the Grafana configuration, then restart Grafana. Store the value in a secret source, not in plain configuration files. |
| Missing or misnamed claim, all users in default role | Every user lands in the default role because the claim named in role_attribute_path or in the attribute lookup is absent from the ID or access token. Decode a token from a test login and confirm the claim name and its exact case. The Keycloak client needs a mapper that adds the claim to the token Grafana reads. | Add a client mapper that places the role or group attribute in the token and enable it for the ID token or userinfo as Grafana uses it. Match the claim name exactly in the Grafana configuration. |
| role_attribute_path returns no match | The JMESPath expression evaluates to nothing, so Grafana either denies access or assigns a lower role than intended. Grafana logs usually show the evaluated role as empty. Test the expression against a decoded token before changing Grafana. | Correct the expression to match the token structure, then confirm that the Keycloak role names match the values the expression returns. Decide deliberately whether unmatched users should be denied or given the minimum role, and set the strict option to reflect that choice. |
| Clock skew and token expiry cause logouts | Users are logged out early or sign-in fails with a token validity error. The Grafana host and the Keycloak server clocks differ, so tokens look expired or not yet valid. Compare the iat, nbf and exp values in a decoded token with the server time on both hosts. | Synchronize both servers with a time service such as NTP and monitor drift. Check that the Grafana session lifetime and the Keycloak token lifespans are set on purpose and that refresh tokens are issued where the design expects them. |
| TLS trust error reaching the token endpoint | Grafana cannot reach or verify the Keycloak token endpoint, and the log shows a certificate or x509 error during the token exchange. The internal certificate authority is not in the trust store used by the Grafana process. Check the Grafana log and test the endpoint from the Grafana host with the same trust store. | Install the internal CA certificate in the operating system trust store used by Grafana, or configure the Grafana TLS CA setting for the token endpoint. Do not disable certificate verification to get past the error. |
| Old roles persist after Keycloak changes | A user keeps a role removed in Keycloak until their next login because Grafana stores the role from the last sign-in. Confirm by comparing the user's current Keycloak role membership with the role shown in Grafana after a fresh login. | Expect the update on the next login, or end the user's Grafana sessions after a role change. Build the change process around that delay, and confirm with your team how quickly access must be reduced for sensitive roles. |
Questions teams ask before setting up Keycloak and Grafana SSO
How much effort does a Keycloak and Grafana SSO integration take?
The effort depends on how many roles you map, how cleanly the token claims are designed, how the reverse proxy and TLS are set up, and whether you need team sync. One Grafana instance with a few roles from a single Keycloak client is a contained change. Each added role, a second environment, or a claim built from group membership adds design and test work. Reverse proxy and TLS problems often take longer than the Grafana settings, because redirect URIs, root URL and certificate chains must match exactly. Team sync adds its own licensing question and mapping work. When you compare quotes, ask for the work to be broken into role design, Keycloak client setup, Grafana configuration, testing and the change window.
Can our team set up Keycloak and Grafana SSO from the docs alone?
Yes, for a single Grafana instance with a small, clearly defined role set, if someone on your team is comfortable with Keycloak clients, mappers and TLS. The work gets harder with multiple environments, several Grafana organizations, a role model that is still being debated, or strict audit requirements that ask who changed which mapping and when. In those cases the main risk is drift after go-live. A mapper edited in Keycloak can silently remove access, or a staging client can carry production redirect URIs. Test each role with a dedicated account, record every configuration change, and name the person who owns the mappers after launch. The documentation explains the settings but does not assign that ownership.
What must we provide before Keycloak and Grafana SSO work starts?
You need administrator access to the Keycloak realm and to the Grafana server or its administrator account. Provide one test account for each role you plan to map, so access can be checked for every level. A named role model is essential: the people who own each Grafana role should agree on which Keycloak groups or claim values grant it. Confirm the public hostnames for Keycloak and Grafana, the reverse proxy configuration and the TLS certificates in use. Finally, schedule a change window for the Grafana restart, since configuration changes take effect only after the service restarts. Agree on who approves the window and who is on call if the first login test fails.
Which Keycloak and Grafana SSO tasks are one-time and which recur?
Initial setup is one-time work: creating the Keycloak client, designing the claim and mappers, configuring Grafana's generic OAuth settings, and testing every role. The recurring work begins after go-live. Keycloak publishes four minor releases a year and a major release every two to three years, so the client and mapper configuration needs checking at each upgrade. Grafana's upgrade guidance describes minor releases every other month, patch releases at least monthly, and support for each minor release for 9 months, so Grafana upgrades need a regular schedule. Mapper reviews are also recurring whenever roles or groups change. Ask any partner whether these are included in the quote or covered by a separate retainer, since DeployOpen offers ongoing support as retainers.
Does Grafana charge a license fee for Keycloak generic OAuth login?
Generic OAuth is supported in all Grafana editions, according to the Grafana authentication documentation, so signing in through Keycloak with that path does not require Enterprise or Cloud. Team sync from Keycloak groups does require Grafana Enterprise or Grafana Cloud. Grafana Cloud pricing on the Grafana pricing page lists a Pro tier with a 19 US dollar monthly platform fee plus usage, and an Enterprise tier with a minimum commitment of 25,000 US dollars per year. Those figures can change, so confirm current pricing with Grafana before you budget. Separately, the implementation work is quoted from your written scope and is not included in any Grafana license price.
Do we need Grafana team sync to map Keycloak groups?
Not for basic role assignment. Grafana can set a user's organization role (such as Viewer, Editor or Admin) from a value in the token through the role_attribute_path setting, and that works with the generic OAuth path. Team sync is a different feature: it places users into Grafana teams based on their identity provider groups, and that requires Grafana Enterprise or Grafana Cloud. Decide early whether your access model depends on Grafana teams, for example for dashboard or folder permissions. If it does, the licensing and the sync design both belong in the scope before the build starts. If role mapping covers your needs, the integration stays within the generic OAuth path.
What usually breaks in a Keycloak and Grafana SSO setup?
Most failures fall into a few groups. Redirect URIs or the Grafana root URL do not match the public hostname, often because the reverse proxy forwards a different host or scheme. The token claim path is wrong, or the mapper outputs role names Grafana does not expect, so users land in the default role without warning. The certificate chain is not trusted by Grafana or the proxy. Logout ends the Grafana session but leaves the Keycloak session active, or the reverse. Refresh token lifetimes cause sessions to end earlier than users expect. After each change, sign in with a test account for every role, check the claim contents in the token, and confirm logout from both sides. Keep a record of the working configuration so a rollback is quick.
How DeployOpen scopes and delivers a Keycloak and Grafana SSO integration
DeployOpen plans and delivers Keycloak and Grafana SSO integration as a fixed-scope engagement inside your own infrastructure, with the Keycloak client, Grafana configuration and role mapping agreed in writing before work starts. Each stage ends with a tested login path and documentation your team can run without us.
How we scope
- Confirm your Keycloak version, deployment model and whether Grafana runs as Enterprise, Cloud or open source edition.
- Agree which Keycloak groups or roles map to Grafana roles, and which access must be granted by hand.
- Record in the written scope whether team sync is in or out, since it depends on Grafana Enterprise or Grafana Cloud.
- Set out the test users, browsers and logout behavior that count as acceptance for the integration.
How we build
- Configure the Keycloak client for Grafana using generic OAuth2 with the redirect URI and client settings matched to your Grafana URL.
- Build the role_attribute_path expression from your agreed claims and check it against sample accounts before rollout.
- Wire single logout and refresh token behavior into Grafana and Keycloak, then test session expiry in each direction.
- Keep configuration as code where your environment allows, so changes move through your normal review process.
How we hand over
- Deliver written documentation covering the Keycloak client, claim mappings, Grafana settings and the test results.
- Walk your administrators through how to add a user to a group, change a role and rotate the client secret.
- Provide a list of open items, including any team sync or group features that depend on a Grafana license tier you do not hold.
- Confirm acceptance against the scope criteria before the engagement closes.
How we support
- Offer ongoing support, upgrades and testing as a retainer after handover, if your team wants it.
- Plan re-testing when Keycloak or Grafana releases change authentication behavior, since both projects ship on their own schedules.
- Review role mapping and client settings when your identity structure or Grafana deployment changes.
- Ask for a separate quote for any support scope beyond the agreed integration, since retainers are priced from the written scope.
