Feature Request: OAuth / SSO authentication support (GitHub, Azure AD, SAML)

[lucasoares]

Summary

The MCP server currently only supports token-based authentication via the SONARQUBE_TOKEN environment variable. Many SonarQube Community and Enterprise deployments rely on SSO providers (GitHub OAuth, Azure AD, SAML, etc.) as their primary — and sometimes only — authentication mechanism. In those setups, users may not be able to generate personal tokens at all, or doing so is an extra friction step that breaks the seamless experience the MCP is supposed to provide.

Problem

When a SonarQube instance is configured to use an external identity provider (e.g. GitHub OAuth, Azure AD OIDC, SAML), the login flow is browser-based. Users authenticate through the IdP and get a session cookie; they don't necessarily have or want to create a SonarQube user token just to use the MCP server.

This creates two pain points:

1. Blocked users – Admins may disable local authentication entirely, making token generation impossible without a separate admin action.
2. Friction for everyone else – Even when token generation is allowed, requiring users to generate and manage a token is a poor experience compared to "just log in with GitHub/Azure like you already do."

Proposed Solution

Support an OAuth / SSO-based authentication flow in the MCP server so that users don't need to generate tokens manually. Possible approaches:

Option A – Device Authorization Grant (RFC 8628)

Many IdPs (GitHub, Azure AD) support the OAuth 2.0 Device Flow. The MCP server could:

1. Initiate a device-code request to the configured IdP.
2. Display the user code + verification URL in the MCP client.
3. Poll for the access token once the user approves in the browser.
4. Exchange the IdP token for a SonarQube session or use it directly if SonarQube supports token exchange.

Option B – Browser-based Authorization Code Flow (PKCE)

For clients that can open a browser, the standard PKCE flow could be used:

1. MCP server starts a local redirect listener.
2. User is redirected to the IdP login page.
3. After consent, the IdP redirects back with an authorization code.
4. MCP server exchanges it for tokens.

Option C – Delegated token via SonarQube's own OAuth endpoints

SonarQube's web API already handles the OAuth callback (/oauth2/callback/*). If the MCP server can redirect to SonarQube's login URL and intercept the resulting session, it could derive a short-lived user token automatically without user involvement.

Minimum Viable Change

At minimum, exposing a configuration option such as:

SONARQUBE_AUTH_METHOD=oauth   # or "token" (current default)
SONARQUBE_OAUTH_PROVIDER=github  # github | azure | saml | ...

…and guiding users through an interactive browser login on first use would significantly reduce friction.

Context / Environment

• Affected deployment type: SonarQube Community Edition (self-hosted) with GitHub / Azure AD SSO enabled
• Current workaround: Manually generate a SonarQube user token after logging in via SSO, paste it into the MCP config — works but defeats the purpose of SSO.
• Related MCP capability: The MCP authorization spec describes an OAuth 2.1-based auth flow for MCP servers that could be implemented here.

References

• MCP Authorization Specification (2025-03-26)
• SonarQube Web API – Authentication
• OAuth 2.0 Device Authorization Grant – RFC 8628

[jonesbusy]

I hope it gets some traction within Sonar. I guess one blocking point is the lack of OIDC integration in SonarQube Server and the validation of JWT Bearer token. I don't know about cloud edition of SonarQube.

[farah-bouassida]

Hi @lucasoares , thank you for the feature request and for providing context around your use case.

I can confirm this is under consideration by our team, starting first with SonarQube Cloud. However, we don't have a timeline to share at this point.

We'll update this thread whenever the status changes. Thanks for your patience!