Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
One of the ways you can authenticate to GitLab via GitLab CLI is through Web. (OAuth) vs. Token (which leaves a Personal Access Token on disk which can be dangerous, esp. when you have agents running around willy-nilly :P)
Right now, however, this doesn't work:
glab auth login --hostname git.drupalcode.org
# Choose "Web" as the authentication mechanism
because it will ask you for a "client_id" first. Like most things in GitLab, glab assumed gitlab.com by default. :P
The instructions under https://docs.gitlab.com/integration/oauth_provider/#create-a-user-owned-... will work, but I don't think we want to instruct 30,000 contributors to do this on their own. :P
Proposed resolution
Set up an instance-wide application instead.
Note: OAuth requires expanded token scopes beyond read-only, so in deference to #3379836: Allow full access to Gitlab API (subject to user permission limits)) this is probably postponed.
Comments
Comment #2
webchickComment #3
webchickAh, https://gitlab.com/gitlab-org/cli/-/work_items/8334#note_3403591861 turns out the bug I found wasn't a bug; OAuth / web login requires the token scopes
openid,profile,read_user,write_repository, andapi, as per https://gitlab.com/gitlab-org/cli#oauth-gitlab-self-managed-gitlab-dedic...So this is postponed instead on #3379836: Allow full access to Gitlab API (subject to user permission limits).
Comment #4
webchickComment #5
webchickComment #6
webchickHm. Actually, after discussing this more with Claude, it sounds like since PATs already allow
api, supporting the OAuth flow would be a meaningful step up in security, because:- OAuth tokens are auto-generated (users can't accidentally give them api scope + no-expiry out of laziness)
- They can be revoked centrally by the OAuth app owner, not just per-user
- The scope is determined by the OAuth app registration, not individual choice