Fix Grafana "OAuth Not Enabled" Login Configuration Errors (2026)

The Grafana authentication service failed to connect to the configured OAuth provider because it couldn’t validate the provider’s identity.

Common Causes and Fixes:

Incorrect client_id or client_secret: The most frequent culprit. Grafana uses these credentials to identify itself to the OAuth provider. If they don’t match exactly what’s registered with the provider, the handshake fails.
- Diagnosis: Check your Grafana grafana.ini file (or environment variables) for the client_id and client_secret under the [auth.google] or [auth.github] section (or whichever OAuth provider you’re using). Compare these character-for-character with the credentials provided by your OAuth provider (e.g., Google Cloud Console, GitHub Developer applications).
- Fix: Ensure the client_id and client_secret in grafana.ini are identical to those from the OAuth provider. For example, if your grafana.ini has:
```
[auth.google]
enabled = true
client_id = YOUR_GRAFANA_CLIENT_ID_HERE
client_secret = YOUR_GRAFANA_CLIENT_SECRET_HERE
```
  And your Google Cloud Console shows: Client ID: 1234567890-abcdefghijklmnopqrstuvwxyz.apps.googleusercontent.com Client secret: ABCDEFGHIJKLMNOPQRSTUVWXYZ Update your grafana.ini accordingly.
- Why it works: These are cryptographic credentials. A mismatch means Grafana is presenting an unknown identity, and the OAuth provider will reject it.
Invalid redirect_uri (Callback URL): The OAuth provider needs to know where to send the user back after successful authentication. If this URL is wrong, the provider won’t redirect back to Grafana, or Grafana won’t recognize the incoming callback.
- Diagnosis: In grafana.ini, verify the redirect_uri (often implied or set in the OAuth provider’s settings, but sometimes explicitly configured in Grafana). Check the OAuth application settings on your provider’s side for the registered redirect URIs.
- Fix: Ensure the redirect_uri registered with the OAuth provider exactly matches the URL Grafana expects. For a typical Grafana instance at https://grafana.example.com, the redirect URI is usually https://grafana.example.com/login/google (for Google OAuth) or https://grafana.example.com/login/github (for GitHub OAuth). If you’re using a custom port, it would be https://grafana.example.com:3000/login/google.
- Why it works: The OAuth flow relies on a secure callback. The provider sends the authentication token to this specific URL. If it’s unregistered or incorrect, the provider will refuse to send the token, or Grafana will reject the callback as unauthorized.
OAuth Provider Misconfiguration (Scopes/Permissions): The OAuth provider might not have granted Grafana the necessary permissions (scopes) to access user information.
- Diagnosis: Review the scopes configured for your OAuth application on the provider’s platform. Common scopes include email, profile, openid (for OpenID Connect).
- Fix: Add or ensure the required scopes are enabled for your Grafana OAuth application. For Google, you might need https://www.googleapis.com/auth/userinfo.email and https://www.googleapis.com/auth/userinfo.profile. For GitHub, read:user and user:email are typical. Consult your OAuth provider’s documentation for specific scope names.
- Why it works: Scopes define what data Grafana can request from the OAuth provider. Without the necessary scopes, Grafana cannot retrieve the user’s identity details required for login.
Network Issues/Firewall Blocking: Grafana needs to communicate with the OAuth provider’s endpoints (e.g., authorization endpoint, token endpoint). Firewalls or network configurations can prevent this.
- Diagnosis: From the Grafana server, try to curl the OAuth provider’s token endpoint. For example, for Google: curl -v https://oauth2.googleapis.com/token. Check firewall logs on the Grafana server and any intermediate network devices.
- Fix: Ensure outbound connections from your Grafana server to the OAuth provider’s API endpoints are allowed on the relevant ports (usually 443 for HTTPS).
- Why it works: A lack of network connectivity means Grafana cannot complete the token exchange process with the OAuth provider, leading to authentication failure.
Incorrect scopes Configuration in grafana.ini: Similar to #3, but specifically about how Grafana requests scopes.
- Diagnosis: Check the scopes setting in your grafana.ini under the relevant [auth.provider] section.
- Fix: Ensure the scopes listed in grafana.ini are space-separated strings that match the scopes your OAuth provider expects and has granted to your application. For example:
```
[auth.google]
scopes = email profile openid
```
  If the provider expects different names, adjust accordingly.
- Why it works: Grafana constructs the authorization request URL with these scopes. If they don’t match what the provider recognizes or has approved, the request will be denied.
Time Synchronization Issues: If the Grafana server’s clock is significantly out of sync with the OAuth provider’s servers, token validation can fail due to perceived expiry or issuance time discrepancies.
- Diagnosis: Check the system time on your Grafana server: date. Compare it to an accurate time source.
- Fix: Synchronize your Grafana server’s clock using NTP. On Linux: sudo timedatectl set-ntp true or ensure ntpd or chronyd is running and configured.
- Why it works: Authentication tokens often have timestamps. If the clocks are drifted, a token issued moments ago might appear to be from the future or too old, causing validation to fail.

After resolving these, you’ll likely encounter a "User not found" error if the user’s email from the OAuth provider isn’t yet associated with a Grafana account or role.