Single sign-on across GitLab, Grafana, and internal admin tools means one identity provider (IdP) authenticates humans once, then each application trusts short-lived OIDC tokens instead of separate password databases. Done well, onboarding is faster and offboarding revokes access everywhere. Done poorly, you inherit redirect-URI mismatches, Grafana orgs that grant Editor to everyone, and GitLab groups that drift from HR.
DarDev runs GitLab for CI, Grafana for metrics, and custom admin surfaces for CRM and sync workers. We federate human login through Workspace on the Authorize step of our platform pipeline. This guide documents the OIDC patterns we use and the checklist for teams rolling out SSO.
Why one IdP beats three password stores
Pain shows up when a new hire needs GitLab Developer, Grafana Viewer, and internal console access—each with separate invites. Security pain shows up when someone leaves and a shared Grafana admin still works. A central IdP with group claims mapped into each app closes both gaps.
- One subject ID per person across GitLab, Grafana, and custom apps
- Group membership from IdP sync—not manual Grafana edits
- Logout and session revocation tested on every relying party
- CI tokens and service accounts kept separate from human SSO
SSO answers who authenticated; apps still enforce authorization. GitLab checks project membership; Grafana scopes org roles. Our zero-trust IAM for internal SaaS guide covers service-to-service trust inside the cluster.
Reference architecture
We standardize on OpenID Connect. Workspace hosts the authorization server, client registrations, and groups. Each app is an OAuth relying party with its own client ID, secret, and whitelisted redirect URIs per environment.
- Register OIDC clients per app and environment
Production GitLab, staging GitLab, Grafana, and each custom app get distinct redirect URIs. Never reuse production secrets in staging.
- Map IdP groups to GitLab and Grafana roles
platform-engineers → GitLab Maintainer group; all-engineers → Developer; default Grafana Viewer, Editor only where needed. Avoid making every engineer GitLab Owner.
- Wire custom apps through the same issuer
Middleware validates JWT signature, audience, expiry, and group claims before handlers run. Same JWKS URL as GitLab and Grafana.
- Test the logout chain
Confirm killing an IdP session ends GitLab and Grafana browser sessions users expect—front-channel logout or short TTL plus refresh rotation.
GitLab and Grafana specifics
GitLab OmniAuth OIDC needs issuer, client ID, discovery URL, and scopes openid profile email in gitlab.rb or Helm values. External URL, callback URL, and trusted redirect URIs must match what browsers see after TLS termination—mismatch causes redirect_uri errors after IdP login succeeds. Keep a wiki table of every hostname and callback path. Pipelines use project or group access tokens, not cloned SSO sessions.
Grafana generic OAuth needs allow_sign_up controlled: auto-provision Viewers for small teams; restrict sign-up and sync named orgs at scale. Pair with session security patterns for admin tools—shorter idle timeouts, step-up auth before destructive changes, and no shared admin passwords. Viewer role does not hide production datasources; network policy and datasource credentials should assume Grafana compromise is possible.
Custom internal applications
Admin services validate JWTs via IdP JWKS, check aud and iss, and reject tokens missing required groups. Do not share session cookies across unrelated apex domains. Multi-tenant apps need tenant context in claims or a server lookup after auth—see identity for multi-tenant product platforms. Workspace in the DarDev pipeline (Authorize step) centralizes client registrations so new tools register once instead of inventing basic auth per service.
Rollout checklist
- Inventory every human-facing URL and current auth mechanism
- Create OIDC clients with per-environment redirect URIs in a runbook
- Pilot with Grafana Viewers before Maintainer mappings
- Disable local passwords after one sprint of parallel login
- Verify offboarding: disable IdP user and confirm all apps deny access
Common mistakes
- Granting Grafana Admin or GitLab Owner via a broad IdP group
- Reusing OAuth secrets across staging and production
- Letting CI jobs use a human admin SSO token
- Launching SSO before logout is tested
- Treating SSO as authorization—skipping project-level GitLab permissions
How Workspace helps
Workspace provides zero-trust IAM and SSO as DarDev's Authorize layer—central OIDC, group sync into GitLab and Grafana, and patterns we reuse as we add products. Visit dardev.net/products for positioning, and subscribe at mail.dardev.net/subscribe/workspace-marketing.html if you are federating GitLab, Grafana, and custom apps.
Should GitLab or Grafana be the identity provider?
Use a dedicated IdP—Workspace, Keycloak, or Azure AD—and register GitLab and Grafana as OAuth clients. GitLab-as-IdP couples identity to your code host; a neutral IdP simplifies offboarding.
What redirect URIs do we need?
GitLab OmniAuth callback, Grafana login/generic_oauth, and each custom app's /auth/callback—multiplied by every public hostname (prod, staging). Document them before opening security tickets.
How do we handle CI and automation?
Project access tokens, deploy tokens, or workload identity—not SSO sessions. Rotate tokens on the same schedule as group membership reviews.
Can one person belong to multiple Grafana orgs via SSO?
Yes, via group-to-org mapping or org invites after first login. Decide whether IdP groups encode org membership or platform admins assign roles post-provisioning.
What should we implement first this sprint?
Register staging OIDC clients for GitLab and Grafana, map one IdP group to Viewer and Developer, and test logout. That pilot surfaces redirect and group-sync issues before production Maintainer roles.
