Scope permissions for GitLab group sync

  • SonarQube Community Build v24.12.0.100206
  • Deployed via Docker
  • Attempting to set up GitLab authentication with group sync
  • Successfully configured GitLab authentication with group sync by following the official documentation

My question concerns the scope of the Application in GitLab. According to the documentation and the SonarQube UI, the api scope is required to enable group sync with GitLab.

However, I achieved the same result using only the read_api scope in the Application.
On the SonarQube login page, after clicking “Log in with GitLab”, a request is made with a URL containing scope=api. As expected, this results in the error:

The requested scope is invalid, unknown, or malformed.

But if I manually change the scope parameter from scope=api to scope=read_api, the authentication proceeds exactly as if the api scope were defined in the Application. It then displays:

Read Api
Grants read access to the API, including all groups and projects, the container registry, and the package registry.

If I authorize, SonarQube successfully creates the user and, if the groups were previously defined in SonarQube with the same names as in GitLab, it correctly assigns the user to the corresponding groups.

Why are write permissions required to sync groups?

I couldn’t find any post, either here or elsewhere, that specifically explains why SonarQube requires write permissions to sync groups. The only related information I found concerns a bug with scope permissions, but that applies to cases without group syncing.

Is api scope really necessary?

I can only assume that the api scope parameter is hard-coded but not actually necessary to achieve the same result.

Hey @joaopaixao

As I understand it, we wanted to remove the api permission requirement with SONAR-21589, but that introduced backward compatibility issues with existing setups that we weren’t prepared to address. I’m not entirely sure why we didn’t make the change and leave an upgrade note… but that’s where we landed!

Why is it this way in the first place? If my memory serves me correctly, the read_api permission didn’t exist when we first developed group synchronization for Gitlab, only api.

Hello Colin,

Thanks for the quick reply.

So, there are no plans to address this situation for group syncing with the api scope, correct?
And due to backward compatibility, it is unlikely that this will ever change?

As I said in my initial post, I was able to achieve the same behavior using read_api instead of api by manually modifying the request.
Could this be the only viable solution for now to avoid granting unnecessary write permissions?