Grafana Forward OAuth Identity
You enable grafana forward oauth identity by turning on token pass-through in your data source settings. This sends the logged-in user's token straight to the backend database. Teams often use a single shared database account for all dashboard users instead. Shared accounts make it hard to see which person ran an expensive query. They also give every viewer the same broad data permissions as the shared role. How grafana forward oauth identity works in practice Standard data sources use one st
Identity and Access Management (IAM) + OAuth 2.0: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You enable grafana forward oauth identity by turning on token pass-through in your data source settings. This sends the logged-in user's token straight to the backend database. Teams often use a single shared database account for all dashboard users instead. Shared accounts make it hard to see which person ran an expensive query. They also give every viewer the same broad data permissions as the shared role.
How grafana forward oauth identity works in practice
Standard data sources use one static user key stored inside the dashboard app. Every chart request uses that same saved key to read backend data. When you turn on grafana forward oauth identity, the flow changes for each user. First, a team member logs into the dashboard app with their identity provider. The identity provider gives the dashboard app a token for that specific person.
When that person opens a chart, the app reads their active user token. It attaches that token to the request header sent to the backend data source. The backend database checks the token with the identity provider before running the query. If the token is valid, the database runs the query under that user's role. This means two people looking at the same chart can see different data rows.
To make this work, both tools must trust the same identity provider. You must set up single sign-on in the dashboard app first. Then you must set up the backend database to accept tokens from that provider. You also need to ask for the right token scopes during the login step. If the scopes do not match, the backend will reject the forwarded request.
What token forwarding solves and what it misses
Passing the user token solves the shared account problem in backend audit logs. Database admins can finally see which person triggered a slow dashboard load. You can also match database row rules to your company groups and roles. A viewer from the sales team will only pull rows allowed for sales.
Still, token pass-through only checks who logs in at the start of a request. It does not inspect or limit the actual queries running in flight. Once the backend accepts the token, the user gets full query power for their role. If a role can read a table, the user can pull every sensitive column. Raw emails, phone numbers, and card numbers flow straight into the browser screen. Data masking that rewrites matched fields in results does not happen through token forwarding alone.
Identity and Access Management (IAM) + OAuth 2.0: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Token forwarding also fails when background tasks need to run without a live user. Scheduled alerts and report jobs do not have a browser session or user token. When an alert fires at night, there is no active token to pass forward. Teams often fall back to a broad static key just to keep alerts working. You also cannot ask a manager to approve a single risky query in real time.
Managing shared dashboards and background queries
Teams hit another wall when they mix public charts with private data sources. A dashboard might pull metrics from five different backend stores at the same time. Not every backend store can check tokens from your main identity provider. Older SQL databases often expect a normal username and password during the login step. They cannot read a web token sent inside an HTTP header.
Because of this gap, admins end up mixing forwarded tokens and saved passwords. Half of the data sources check the user identity while the rest use static keys. Auditing becomes messy because identity logs split across different systems and formats. Security teams have to stitch together login logs and database logs by hand. You need a consistent way to check every query and mask sensitive fields in flight.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Why do my dashboard alerts fail after turning on token forwarding?
Background alerts run on a timer when no user is logged into the browser. Since no user session exists, the app has no token to send to the backend. You must use a separate service account for data sources that power background alerts.
Does every data source support forwarding the user token?
No, only specific built-in plugins and HTTP-based backends can read the forwarded header. Many traditional SQL databases do not accept web tokens over standard database ports. Check your specific plugin settings to see if the pass-through toggle is present.
How do we handle token expiration during long dashboard sessions?
The dashboard app needs a refresh token from your identity provider to get new tokens. If the identity provider does not send a refresh token, charts will break after an hour. Make sure your login scopes include offline access so the app can refresh tokens.