Adding personal access token in Gitlab : What are the different token scope use cases?

Question

I am connecting my GitLab account to PyCharm and while creating the token access in GitLab, I was uncertain what are the practical uses.
I am very new to this so if someone can dumb this down, that would be appreciated.

Answer 1

The idea is to:

• limit the actions you can do with one PAT
• have several PAT for several usage
• easily revoke one PAT if compromised/not needed, without invalidating the others

As illustrated here, if you intend to use a PAT as your GitLab password, you would need the "api" scope.
If not, "read_repository" or (if you don't need to clone) "read_user" is enough.
"read_registry" is only needed if your GitLab host docker images as a docker registry.

What I don't understand is it allows me to select all at once

That is because each scope matches a distinct use case, possibly covered by another scope.
By selecting them all, you cover all the use cases:

• api covers everything (which is too much, as illustrated by issue 20440. GitLab 12.10, Apr. 2020, should fix that with merge request 28944 and a read_api scope)
• write (since GitLab 1.11, May 2019): "Repository read-write scope for personal access tokens".
  Many personal access tokens rely on api level scoping for programmatic changes, but full API access may be too permissive for some users or organizations.
  Thanks to a community contribution, personal access tokens can now be scoped to only read and write to project repositories – preventing deeper API access to sensitive areas of GitLab like settings and membership.
• read_users and registry each address a distinct scenario

As mentioned in gitlab-ce/merge_request 5951:

I would want us to (eventually) have separate scopes for read_user and write_user, for example.

I've looked at the OpenID Connect Core spec - it defines the profile, email, address, and phone scopes, which need to be accompanied by the openid scope.

Since we can have multiple allowable scopes for a given resource, my preference would be to leave the read_user scope here, and add in the openid and profile scopes whenever we're implementing OpenID compliance.
The presence of other scopes (like read_user and write_user) shouldn't affect the OpenID flow.