## Problem to solve Web-based OAuth login for `glab` against a self-managed / Dedicated instance is currently a two-step, two-command dance, split across an error message and separate docs: ``` $ glab auth login --hostname self.hosted.gitlab.com ERROR Set 'client_id' first with `glab config set client_id <client_id> -g --host self.hosted.gitlab.com`. ``` To get past this, a user has to: 1. Know (from docs, not from the CLI) that an OAuth application needs to exist on the target instance first, with a specific redirect URI, specific scopes, and `Confidential` unchecked. 2. Ask an admin/group owner to create it via `/admin/applications/new` (or group/user Applications), then hand over the Application ID out of band. 3. Run `glab config set client_id <ID> --host <hostname>`. 4. Re-run `glab auth login --hostname <hostname>`. This is confirmed as the intended flow for the foreseeable future — see the discussion on [`gitlab-org/gitlab#413809`](https://gitlab.com/gitlab-org/gitlab/-/work_items/413809#note_3770421889) and [`cli#1338`](https://gitlab.com/gitlab-org/cli/-/issues/1338): GitLab's OAuth Dynamic Client Registration endpoint (`/oauth/register`, RFC 7591) only ever mints applications scoped to `mcp` ([`gitlab-org/gitlab#599020`](https://gitlab.com/gitlab-org/gitlab/-/work_items/599020)), so it can't be used to obtain a client_id with `api`/`write_repository`/etc. There's no server-side shortcut available today, and no near-term plan to add one. The manual admin-registration step is a hard requirement we can't remove from `glab`'s side. What we *can* remove is the friction around it. Right now the failure is a dead end: a bare error, then a context switch to docs, a separate `config set` command, and a second `auth login` invocation. Real user reports on `cli#1338` describe waiting weeks for an OAuth callback that would never arrive because they didn't know a client_id was even required. ## Proposal When `glab auth login --hostname <host>` hits a self-managed host with no `client_id` configured, and stdin is a TTY, replace the immediate error with a single guided prompt instead of a dead end: ``` No OAuth application is configured for self.hosted.gitlab.com yet. Ask an instance or group admin to create one (Admin Area > Applications, or Group > Settings > Applications): Redirect URI: http://localhost:7171/auth/redirect Scopes: openid profile read_user write_repository api Confidential: off (glab is a public client and cannot hold a secret) Paste the Application ID here: _ ``` On input, persist it exactly the way `glab config set client_id <ID> --host <hostname>` does today, then continue straight into the login — no separate command, no re-run, no doc lookup mid-flow. In a non-interactive context (CI, scripts, piped stdin), fall back to exactly today's behavior: the existing error message pointing at `glab config set client_id`. Nothing changes for scripted use. ### Where this lives in the code Everything funnels through one choke point already: [`oauthClientID()` in `internal/oauth2/config.go`](https://gitlab.com/gitlab-org/cli/-/blob/main/internal/oauth2/config.go#L18-27), called by both the Web flow (`StartFlow` in `oauth2.go`) and the Device flow (`StartDeviceFlow` in `device.go`): ```go func oauthClientID(cfg config.Config, hostname string) (string, error) { if glinstance.IsSelfHosted(hostname) { clientID, err := cfg.Get(hostname, "client_id") if err != nil { return "", err } if clientID == "" { return "", fmt.Errorf("set 'client_id' first with `glab config set client_id <client_id> -g --host %s`", hostname) } return clientID, nil } return glinstance.DefaultClientID, nil } ``` The prompt text can reuse the `redirectURL` and `scopes` values already defined in that same file, so the instructions can never drift out of sync with what the flow actually sends. ### Why this is worth doing despite not removing the admin step - It's entirely within `glab`'s own codebase — no GitLab server-side change or feature flag needed, so it's not blocked on `gitlab-org/gitlab#413809` or anything else outside this project. - It collapses today's "error → docs → separate command → re-run" loop into one continuous flow. - It surfaces the exact required values (redirect URI, scopes, confidential=off) at the point of failure instead of requiring a trip to the README's OAuth section. - It doesn't change behavior for anyone already using `glab config set client_id` directly, or for non-interactive/CI usage. ### Out of scope - Anything that would let `glab` obtain a client_id without an admin-created application — not possible today (see the DCR scope restriction above). - Auto-detecting or auto-creating the OAuth application via API — GitLab has no endpoint for that today; `Oauth::ApplicationsController#new`/`#create` only accept the standard web form params, not a scriptable create-and-return-id call. ## Links / references - [`gitlab-org/cli#1338`](https://gitlab.com/gitlab-org/cli/-/issues/1338) — original "make client_id configurable" issue (closed, narrower scope) - [`gitlab-org/gitlab#413809`](https://gitlab.com/gitlab-org/gitlab/-/work_items/413809) — the platform-level "public OAuth clients across installations" ask (open, Backlog, blocked on GitLab distribution work) - [`gitlab-org/gitlab#599020`](https://gitlab.com/gitlab-org/gitlab/-/work_items/599020) — confirms DCR is `mcp`-scope-only and states the admin-distributes-client_id flow is the current intended pattern for CLI/IDE clients - [`internal/oauth2/config.go`](https://gitlab.com/gitlab-org/cli/-/blob/main/internal/oauth2/config.go)