Security concern on user tokens


Today we’re using the couple Azure DevOps / SonarQube for most of our developments. Both are linked to our Azure AD.
For each project in Azure DevOps, we automatically create an endpoint to SonarQube, using the token of a SonarQube local account (not an Azure AD account) whose only permission is ‘Execute analyze’ and it works pretty well.

We decided to give a try to SonarCloud, and while trying to set up my usual endpoint, I realized that it’s not possible anymore to create local accounts. So I’m stuck with my personal account, who is organization owner, with all its permissions.

I smiled. Our security guys didn’t… So straightaway, for us, it’s already a big no go.
Any thoughts on this? Anything in your backlog to secure tokens in addition of users (just like in Azure DevOps)?

PS: Just in case… No service accounts in Azure AD. Only ‘real’ users are synchronized, that’s a group / company policy.


Hi Dominique,

Since you cannot have service accounts in Azure AD, the only other way to solve your situation is that you grant the “Execute Analysis” permission (at org level) to one of your team members who is not owner of the org on SonarCloud. This way, if the token gets stolen or compromised, it won’t grant admin permissions on the org.

We already talked in the past about having org tokens (instead of user tokens) for this matter - but this never really became a priority since we’ve had no traction on this feature. Maybe we should think again about this sometime soon.

I have a similar issue with regard to AD integration. My organisation does allow service accounts to be created in AD, however they are designated as non-interactive so we cannot login to using the Azure DevOps identity provider.

Did the idea of organisation tokens gain any traction? We cannot have tokens associated with an individual as when they leave and are deactivated in AD then our pipelines will have to be reconfigured. This will cause a disruption to delivery teams, a burden on our support team and possibly a disruption to operations if we cannot build and deploy a new release.

You can watch and vote for, which is exactly about that topic.

Thanks @Fabrice_Bellingard, I’ve cast my vote :slight_smile: