Using a single PAT-based service connection to avoid SonarCloud token expiration

SonarQube Cloud
1

ALM used

Azure DevOps

CI system used

Azure DevOps Pipelines

Scanner used

SonarCloud Azure DevOps extension (SonarCloudPrepare@3, CLI mode)

Languages

Multiple (varies per repository)

SonarCloud project

Private (not public)

Problem statement

We are not encountering an error, but would like to validate whether the following configuration is a supported and recommended approach.

By default, SonarCloud API tokens expire after 60 days of inactivity, which causes analysis pipelines to fail for repositories that are not built frequently. This has led to recurring outages and manual token regeneration across multiple Azure DevOps service connections.

Configuration / Steps taken

To mitigate this, we consolidated our setup as follows:

  • Created a single Personal Access Token (PAT) from a dedicated account.

  • Stored the PAT in one Azure DevOps service connection.

  • Added the account as a SonarCloud member with Owner permissions to allow authorization during scanning.

  • Updated pipelines to reference this service connection via a shared pipeline template.

Example configuration used in the template:

- task: SonarCloudPrepare@3
  inputs:
    SonarCloud: 'ServiceConnection'
    organization: 'our_organization'
    scannerMode: 'CLI'
    configMode: 'manual'
    cliProjectKey: 'our_organization_${{ parameters.repository }}'
    cliProjectName: ${{ parameters.repository }}
    cliProjectVersion: '1.0'
    cliSources: '.'

Result

The setup has been tested across multiple existing pipelines and is working as expected.

Questions

  1. Is this approach supported and recommended by SonarCloud?

  2. Are there any limitations or risks when using a single PAT-based service connection across multiple repositories?

  3. Are there best practices regarding permissions, token scope, or periodic rotation?

2

Hi,

How stable is your set of projects under analysis? Because I believe the official answer I’m supposed to give you is to use a Scoped Organization Token. However, SOTs have projects explicitly assigned to them, so if you’re adding projects frequently, this would be a pain in the neck. Otherwise, what you’ve laid out makes perfect sense to me assuming the user you’re issuing your token from is a robot & not likely to leave the company for greener pastures.

 
HTH,
Ann

1 Like
6

Hello @Ele ,
Thank you for sharing your use case!
The only thing that I would add to @ganncamp’s answer is that Scoped Organization Tokens (SOT) will soon support more permissions to allow reading any endpoint which will facilitate automations like yours.
Those tokens can be applied on the whole organization and - if their scope is set to All projects - will cover newly added projects to your org without any intervention from your end.
So overall:

  • Your current approach makes sense
  • SOTs will be the right thing to use once they support browse permissions (planned in Q2)
  • They can be applied on all current and future projects within your org - reducing the need to intervene
  • They can have a custom expiration date
  • We plan to support SOT rotation in Q2

I hope that helps and feel free to reach out again if you’d like to share more

1 Like
8

Hi Ann, hi Nour,

Thank you both for the clarifications.

Our set of projects is relatively dynamic, which is why we opted for the current PAT-based setup using a dedicated service account. It’s good to hear that this approach is reasonable in the interim.

The upcoming enhancements to Scoped Organization Tokens sound like exactly what we’re looking for, especially org-wide coverage for current and future projects, browse permissions, and rotation support. We’ll definitely plan to revisit our setup once those capabilities are available.

Thanks again for the guidance and for sharing the roadmap, much appreciated.

Best regards,
El

1 Like
10

@Ele Great to hear that the planned SOT improvements align with your needs.
Just a small clarification: contrary to what @ganncamp mentioned in her message, SOT already support all current and future projects.

image
image988×452 60.2 KB

1 Like