New Gitlab Auth uses `api` scope instead of `read_users` scope

As the title says the new Gitlab Auth requires the api scope unlike the community plugin which only needed read_users and worked fine proving there is no need for the api scope to use Gitlab as an authentication provider.

Whats the need for api scope in SonarQube 8.0? Are there additional calls SonarQube is making which require the api scope and why?

This is a bad security practice overall.

Hi, welcome to the community forum!

You are right, the community plugin let you choose what scope SonarQube should request to GitLab.

The read_user scope is enough for authentication indeed. We require the api scope for group synchronisation (just like the community plugin did) to fetch the /api/v4/groups endpoint.

I agree that this is a bad practice to require a too high level of permission. As an improvement, we could make SonarQube request api scope only if group synchronisation is enable, and read_user otherwise. WDYT ?

@pierreguillot yes that would be wonderful binding api scope usage to sonar.auth.gitlab.groupsSync key.

Any idea when this will be pushed?

I tracked down this to a jira ticket that you can watch. I hope it will make it to the 8.1, which should be released next week if everything is ready.

merged to master, so this will be on the “soon to be released” 8.1. Thanks for your feedback :slight_smile:

Thats great and kudos on the fast resolution. Hope 8.1. will be released soon.

Just a quick update : SonarQube 8.1 released