Iâm excited to announce the public availability of Scoped Organization Tokens (SOT), a powerful new feature that redefines how you manage automation in your organization.
This release is a direct response to a critical challenge many of you have shared: relying on Personal Access Tokens (PATs) for automated processes like CI/CD pipelines. PATs, while useful, are tied to individual users, which creates significant security and management headaches.
How SOT Improves your workflow
SOT is designed to eliminate these pain points by offering a more secure, scalable, and manageable way to handle authentication.
SOT is not tied to a specific user, so your integrations wonât break when someone leaves your organization. This also allows you to apply the principle of least privilege by creating separate tokens for different automations, each with a specific scope.
With SOT, thereâs no need to manually update tokens every time a team memberâs role changes. This simplifies user lifecycle management and reduces operational overhead.
Organization admins have full control over all tokens, including the ability to set expiration dates and revoke them at any time.
This feature is now available to all organization admins on Team and Enterprise plans.
We hope SOT significantly reduces friction and enhances security compared to PATs. Please give it a try and share your feedbackâyour insights are crucial.
For more details on how to get started, please refer to our documentation.
Hi Nour,
the SOTs are bound to specific projects. As we understand it, whenever a new project is created, a new token needs to be created as well.
It would be great if the SOTs would follow the âPermission Templateâ approach, i.e. if it would be possible to specify a âProject Key Patternâ, so that newly added projects could make use of the existing SOT if the match the regexp.
Weâve been waiting for SOT eagerly, however, in a current implementation, SOTs are useless to us, and we have to use dedicated service-user for that. The only reason for that is that SOTs are mandatory to be limited to specific projects.
We use shared token to analyze projects from GitLab pipelines (defined via global CI variable). If weâre to use SOT limited to specific projects, weâll have to regenerate SOT every time a new project is created and then update it in our global CI variable. With service-user we do not need to do that.
SOTs which are project-limited are no better for us than having personal tokens generated for each project - the approach we did before, but switched to service-user instead to save efforts and simplify CI implementation for teams.
Once thereâs an option to have an organization-wide SOT (i.e., without mandatory limit by projects), then weâll switch to SOTs immediately. Our desire is to have a SOT which can analyze all projects, when projects are constantly being added or removed, and so that we do not need to regenerate SOT.
Trying to use the SOT for a connection in Azure Pipelines SonarCloudPrepare@3 task.
Clearly this is an integration problem and not a âbugâ with the SonarCloud SOT feature as such. I wanted to put this here for othersâ benefit and in case there is a known issue Iâve not found yet!
When configuring the Service Connection, there are errors around (presumably) searching for the name of the SonarCloud organisation. This makes sense since the SOT is scoped to scan a single project of course! However, it does imply that simply dropping in the SOT as a replacement for the PAT canât work for Azure Pipelines yet. The Azure Service Connections simply wonât present you with a list of organisations, so it wonât âVerifyâ and even if you attempt to save without verification, doesnât seem to work in the pipeline for the same reason.
Thank you for your input! Iâm sorry SOT isnât currently meeting your needs, and Iâve noted your request for Org. wide tokens.
Creating tokens that never expire (which is possible), especially when organization-wide, is generally considered less secure. Iâm curious: Do you foresee any security concerns or management challenges with using these kinds of tokens?
Also, would supporting this feature in combination with automatically rotating tokens meet your needs, or is that capability not mandatory?
If you or anyone else reading this has input, please let us know.
We ran into the same issue. We have hundreds of projects in our organization and want to execute SonarQube cloud scans from our Jenkins pipelines.
Selecting this many projects results in an HTTP 500 error so we arenât even able to create a SOT for all of the current projects, nor can we change the attributed projects at a later time. So yes, having an organization-wide token for projects (or at least a Select All option) would be preferable.
Also we have more projects that arenât scanned by Sonar at this time - previously we checked the presence of a projects by doing a search first. This doesnât seem to be supported by the SOT at this time, is that correct?
Hi Sietzejan, ah, having non-expiring token is not what we need, sorry for the confusion. Weâre OK setting â1 yearâ expiration, for example. My point about ânever expireâ was about âwhen we add new projects to Sonar, we do not want to regenerate SOT, we want to use the SOT which weâve created before, and that it must automatically be able to scan all new projects (and old ones, of course)â.
Hello Nour, thanks for the answer and for the efforts!
Iâd like to clarify this point:
Support selecting all projects
Just selecting all projects (even if we have ability to update SOT afterwards) is not enough. Our desire is to make sure that all new projects are automatically covered by SOT which weâll create for âall projectsâ. If weâll have to update SOT every time when we create new project (so that SOT covers newly created project as well) - this will do no good for us, and weâll rather use service user, for which we do not need to do anything when new project gets created.
@dmitrii.lobanov That makes a lot of sense â thanks for the clarification!
I can confirm that Select All Projects includes both existing projects and any that are created in the future.
@notverygeordie Thank you for the feedback!
Scoped Organization Tokens only allow project scans for the moment, are you trying to use an SOT for another purpose? Happy to hear more about it.
If only! No. I am stuck in a situation that I suspect is not yet supported, but is blocking me from using the tokens for project scans.
Iâm using Azure Pipelines. The integration steps are described in your documentation here:
In the overview there, there are 5 steps described. Step 3 is the project scan. I havenât actually got to Step 1.
I am here:
That is the step in my original post - something about the SonarQube Cloud connection type simply wonât accept my SOT. That despite it being described in the documentation link there!
I have just created a fresh SOT and tried again - following the instructions explicitly. âSave and Verifyâ fails at the verify stage with this error:
Haha! I have obstinately hit âSave without verificationâ, edited the pipeline yaml without attempting to use the wizard and run the build regardless⊠and it processed âSonarCloudPrepareâ ok! Will update at the end of the run.
EDIT: it worked. So the workaround is to ignore all of the errors and hand-code the SonarCloudPrepare@3âinputsâ SonarCloud: âMySonarConnectionâ property of your task.
Errors appear when Verifying the configured SonarCloud connection, and when attempting to choose and use the values for SonarCloud/organization/projectName/projectKey in your SonarCloudPrepare@3 pipeline task. However, if edited in spite of this, the task itself works.
FURTHER EDIT since new users are limited to three consecutive posts in a thread apparently!
âJust one more thingâ (as short, trench-coated, cigarâtoting detectives from the 70âs are wont to say):
It would be excellent to update the documentation to explain this briefly. A note to suggest (for example) that we either donât verify and âcode it blindâ in the yaml; or set up a connection with a PAT to check it works, then switch to a SOT without verifying and re-test the pipeline. This would be simple enough to explain as there is no âBrowseâ permission (or whatever is tripping us up) support provided by SOTs as yet.
Additionally, to select the maximum available expiration time that is not forever (which is a 1 year exactly), you have to pick the Custom option and enter the exact date at the moment. It would be much faster if â1 yearâ was a selectable option for expiry. Please consider that, thanks!
Moreover, when setting up CI-based analysis, SonarCloud still creates a Personal Access Token (PAT) for use with tools such as GitHub Actions. Ideally, we should have the option to create or reuse a Scoped Organization Token (SOT) instead. This approach only works well if the token is bound to all projects, without explicitly referencing their names.
Introducing Scoped Organization Tokens (SOT)
How SOT Improves your workflow
