Skip to content
Latchkey

SonarScanner "Not authorized. Please check the properties sonar.login" in CI

The scanner sent no valid credential to the server. The SONAR_TOKEN secret was never injected into the step, or the property points at an empty value, so the server rejects the analysis as unauthenticated.

What this error means

Analysis fails early with "Not authorized. Please check the properties sonar.login, sonar.password or sonar.token" (or the newer wording referencing SONAR_TOKEN).

sonar-scanner
ERROR: Not authorized. Please check the properties sonar.login, sonar.password
or sonar.token.
ERROR: Error during SonarScanner execution

Common causes

SONAR_TOKEN is not exposed to the step

The token lives in secrets but the workflow never maps it into the environment, so the scanner sends nothing.

The secret name is misspelled or empty

A typo in ${{ secrets.SONAR_TOKEN }} or a fork run with no secrets leaves the variable blank.

How to fix it

Map the token into the scanner step

  1. Store the analysis token as a repository or organization secret named SONAR_TOKEN.
  2. Expose it in the step env so the scanner reads it.
  3. Re-run and confirm the analysis authenticates.
.github/workflows/ci.yml
- uses: SonarSource/sonarqube-scan-action@v4
  env:
    SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
    SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}

Verify the secret is populated

Secrets are not available to workflows triggered from forks by default. Run analysis on a trusted trigger, and confirm the secret value is not empty.

How to prevent it

  • Keep the token in CI secrets and inject it via env, never hardcoded.
  • Use a consistent secret name (SONAR_TOKEN) across workflows.
  • Avoid running gated analysis on untrusted fork pull requests.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →