SonarQube Authentication: Methods, Setup & Security (2026)

Authentication overview

SonarQube provides several authentication mechanisms to manage user access and secure interactions with its API. These methods allow administrators to integrate SonarQube into existing identity management systems or to manage users directly within the platform. The choice of authentication method often depends on an organization's security policies, existing infrastructure, and scalability requirements. Proper configuration of authentication is critical for maintaining the integrity and confidentiality of code analysis data and project reports.

For programmatic access, SonarQube utilizes user-generated API tokens. These tokens are an alternative to username/password combinations for automated tasks, such as triggering analyses from CI/CD pipelines or fetching analysis results. Each token is associated with a specific user's permissions and can be revoked independently without affecting the user's interactive login capabilities. SonarQube's official documentation provides comprehensive guides for configuring each authentication method and managing user access policies SonarQube authentication documentation.

Supported authentication methods

SonarQube supports a variety of authentication methods, catering to different deployment scenarios and organizational requirements. These methods range from internal user management to integration with enterprise-level identity providers.

Internal Users

By default, SonarQube comes with an internal user directory. This method is suitable for smaller deployments or initial setups. Users can be created, managed, and assigned roles directly within the SonarQube web interface. The initial administrator account (admin/admin) is an internal user and should be updated immediately after installation to enhance security.

LDAP

Lightweight Directory Access Protocol (LDAP) integration allows SonarQube to authenticate users against an external directory server, such as Microsoft Active Directory or OpenLDAP. This centralizes user management and leverages existing directory services for authentication and group synchronization. When configured, SonarQube queries the LDAP server for user credentials and group memberships, which are then used to assign permissions within SonarQube. Configuration involves specifying the LDAP server URL, base DNs, user and group search filters, and authentication details for SonarQube to bind to the LDAP server SonarQube LDAP integration guide.

SAML

Security Assertion Markup Language (SAML) enables Single Sign-On (SSO) for SonarQube, allowing users to authenticate through an external Identity Provider (IdP) like Okta, Azure AD, or OneLogin. SAML integration streamlines the login process and enhances security by centralizing authentication management with the IdP. SonarQube acts as a Service Provider (SP), exchanging authentication assertions with the configured IdP. This method typically requires configuration of both SonarQube and the IdP with metadata, certificates, and assertion consumer service URLs SonarQube SAML configuration.

OAuth 2.0 Integrations

SonarQube supports integration with several OAuth 2.0 providers, enabling users to log in using their existing accounts from these platforms. This simplifies user onboarding and leverages the security mechanisms of these well-established services. Supported integrations include:

• GitHub: Allows users to log in using their GitHub accounts. This is particularly useful for teams that use GitHub for source code management.
• Azure Active Directory: Integrates with Microsoft Azure AD, providing SSO for organizations using Azure services.
• GitLab: Enables authentication via GitLab accounts, facilitating integration with GitLab CI/CD pipelines.
• OpenID Connect: A generic OAuth 2.0-based protocol for authentication, allowing integration with any compliant OpenID Connect provider.

Each OAuth 2.0 integration requires setting up an application within the respective provider's console to obtain client IDs and secrets, which are then configured in SonarQube. The OAuth 2.0 framework is widely used for delegated authorization, allowing users to grant limited access to applications without sharing their credentials directly OAuth 2.0 specification.

Authentication Methods Table

Getting your credentials

The process for obtaining credentials in SonarQube varies depending on the authentication method in use.

For Internal Users

If SonarQube is configured to use its internal user directory, administrators can create new user accounts directly through the SonarQube web interface. Users are typically assigned a username and an initial password. It is recommended that users change their initial password upon first login. The default administrator account is admin with the password admin, which must be changed immediately after installation for security reasons SonarQube user management documentation.

For External Identity Providers (LDAP, SAML, OAuth)

When SonarQube is integrated with an external identity provider, user credentials are managed by that provider. Users will log in to SonarQube using their existing credentials for LDAP, SAML, GitHub, Azure AD, GitLab, or OpenID Connect. SonarQube does not store these external passwords directly but relies on the IdP to verify user identity. The setup process involves configuring SonarQube to communicate with the external provider, which typically requires:

• LDAP: A service account or binding user with read access to the directory, and the LDAP server's hostname/IP and port.
• SAML: Identity Provider (IdP) metadata, certificates, and potentially a client ID/secret if using a specific IdP's API.
• OAuth providers (GitHub, Azure AD, GitLab, OpenID Connect): A client ID and client secret obtained by registering SonarQube as an application within the respective OAuth provider's developer console.

API Tokens for Programmatic Access

For automated tasks and API interactions, SonarQube uses API tokens. These tokens are generated by individual users through their SonarQube profile page. To generate an API token:

1. Log in to SonarQube with your user account.
2. Navigate to your user profile (usually by clicking on your avatar or username in the top right corner).
3. Go to the 'Security' tab.
4. In the 'Generate Tokens' section, provide a name for the token (e.g., CI_Pipeline_Token) and click 'Generate'.
5. The token will be displayed once. Copy it immediately, as it cannot be retrieved again.

API tokens inherit the permissions of the user who generated them. It is best practice to generate specific tokens for specific purposes and revoke them when no longer needed SonarQube API token management.

Authenticated request example

API tokens are commonly used for authenticating requests to the SonarQube Web API. The token should be included in the Authorization header of HTTP requests using Basic authentication, with the token as the username and an empty string as the password. Alternatively, some tools allow specifying the token directly without basic auth encoding.

Example using curl with an API token

This example demonstrates how to fetch a list of projects using a SonarQube API token. Replace YOUR_SONARQUBE_URL with your SonarQube instance URL and YOUR_API_TOKEN with a valid API token.

curl -u "YOUR_API_TOKEN:" "https://YOUR_SONARQUBE_URL/api/projects/search"

In this curl command:

• -u "YOUR_API_TOKEN:" specifies Basic authentication. The API token is provided as the username, and the password field is left empty (represented by the colon).
• https://YOUR_SONARQUBE_URL/api/projects/search is the endpoint for searching projects.

Example in a CI/CD pipeline (e.g., Jenkins, GitLab CI)

When integrating SonarQube analysis into a CI/CD pipeline, the API token is typically passed as a build parameter or environment variable to the SonarScanner. For example, in a Maven project, the token can be provided via the sonar.login property:

<plugin>
  <groupId>org.sonarsource.scanner.maven</groupId>
  <artifactId>sonar-maven-plugin</artifactId>
  <version>3.9.1.2184</version> <!-- Use the latest version -->
  <configuration>
    <sonar.host.url>https://YOUR_SONARQUBE_URL</sonar.host.url>
    <sonar.login>${env.SONAR_TOKEN}</sonar.login> <!-- Token from environment variable -->
  </configuration>
</plugin>

The ${env.SONAR_TOKEN} placeholder assumes that an environment variable named SONAR_TOKEN holds the API token. It is a security best practice to manage such sensitive credentials as secrets in the CI/CD system rather than hardcoding them Google Cloud API key best practices.

Security best practices

Implementing robust security practices for SonarQube authentication is essential to protect code quality data and prevent unauthorized access. These practices apply to both user accounts and API tokens.

Change Default Credentials Immediately

The default admin/admin credentials for the SonarQube administrator account must be changed immediately after installation. This prevents unauthorized access to the SonarQube instance with well-known default credentials.

Use Strong Password Policies

For internal SonarQube users, configure and enforce strong password policies. This includes requirements for password length, complexity (mixture of uppercase, lowercase, numbers, and special characters), and periodic rotation. If using an external identity provider, ensure that the IdP itself enforces strong password policies.

Integrate with Enterprise Identity Providers

Whenever possible, integrate SonarQube with an existing enterprise identity provider (IdP) such as LDAP, SAML, or OAuth 2.0 providers (GitHub, Azure AD, GitLab, OpenID Connect). This centralizes user management, leverages existing security controls, and often enables Single Sign-On (SSO) and multi-factor authentication (MFA) provided by the IdP.

Principle of Least Privilege

Grant users and API tokens only the minimum necessary permissions required to perform their tasks. Avoid assigning administrative privileges unnecessarily. Regularly review user roles and permissions to ensure they remain appropriate.

Manage API Tokens Securely

• Generate dedicated tokens: Create separate API tokens for each application or service that needs to interact with SonarQube. Avoid sharing tokens between different tools or pipelines.
• Short-lived tokens: While SonarQube API tokens do not have an inherent expiration date, it is a good practice to regenerate and rotate them periodically, especially for critical integrations.
• Store securely: Never hardcode API tokens directly into source code. Store them in secure credential management systems, environment variables, or CI/CD secret stores (e.g., HashiCorp Vault, Kubernetes Secrets, GitHub Secrets, GitLab CI/CD variables).
• Revoke unused tokens: Regularly review and revoke any API tokens that are no longer in use or have been compromised.

Enable HTTPS/TLS

Always configure SonarQube to use HTTPS (TLS/SSL) to encrypt all communication between clients (web browsers, SonarScanners, API clients) and the SonarQube server. This protects credentials, API tokens, and sensitive analysis data from eavesdropping during transit.

Regular Security Audits

Periodically audit SonarQube's authentication settings, user accounts, and API token usage. Ensure that configurations align with organizational security policies and best practices. Monitor access logs for unusual activity or failed login attempts.

Implement Multi-Factor Authentication (MFA)

While SonarQube's internal authentication doesn't natively support MFA, integrating with an external IdP that enforces MFA (e.g., Azure AD, Okta via SAML) effectively extends MFA protection to SonarQube logins. This adds an extra layer of security by requiring users to provide more than one form of verification.

Keep SonarQube Updated

Regularly update your SonarQube instance to the latest stable version. Updates often include security patches and enhancements that address newly discovered vulnerabilities in authentication mechanisms or other components.