Allow `gws auth login` to work with OAuth clients that don't register `userinfo.profile`

[KimYannn]

Environment

• gws version: 0.22.5 (built from main at commit a3768d0)
• OS: macOS 25.4.0 (also reproduces on Linux)
• gcloud SDK installed and authenticated

What I'm trying to do

Use the gcloud SDK's well-known public Desktop OAuth client (32555940559.apps.googleusercontent.com) as gws's OAuth client, so I don't have to create a separate GCP project + OAuth client just to try gws.

export GOOGLE_WORKSPACE_CLI_CLIENT_ID=32555940559.apps.googleusercontent.com
export GOOGLE_WORKSPACE_CLI_CLIENT_SECRET=ZmssLNjJy2998hD4CTg2ejr2  # public, ships in gcloud SDK
gws auth login --readonly -s drive

What happens

OAuth flow fails with:

error: restricted_client
error_description: The OAuth client was disabled.

Login never completes; no credentials are saved.

Why

handle_login_inner at crates/google-workspace-cli/src/auth_commands.rs (around line 600) unconditionally appends three identity scopes to every login request:

let identity_scopes = [
    "openid",
    "https://www.googleapis.com/auth/userinfo.email",
    "https://www.googleapis.com/auth/userinfo.profile",
];

https://www.googleapis.com/auth/userinfo.profile is not registered on gcloud's public Desktop OAuth client (verified by inspecting ~/.config/gcloud/credentials.db — the scope list there does not include userinfo.profile). Google's OAuth endpoint rejects the whole request with restricted_client.

The same applies to gcloud's ADC client (764086051850-6qr4p6gpi6hn506pt8ejuq83di341hur.apps.googleusercontent.com).

Expected behaviour

One of:

• (a) gws detects that the requested OAuth client cannot grant userinfo.profile and gracefully drops it (with a warning), letting login succeed.
• (b) Login is attempted; on restricted_client, gws retries without the offending identity scope and warns the user.
• (c) Documentation explicitly says "you must register your own OAuth client; gcloud's public client is unsupported."

Today the failure mode is opaque — no hint that userinfo.profile is the offending scope, no suggested workaround.

Workaround I'm using locally

Removed userinfo.profile from the forced identity-scope list. Login succeeds; fetch_userinfo_email still works (only userinfo.email is needed for the email lookup); only the People-API display-name fallback path in Gmail send-as is affected.

Possible fixes (in order of robustness)

1. Try-then-fallback — request profile by default; on restricted_client retry without it. No hardcoded client_id list. Self-healing if Google ever changes which scopes a client supports.
2. Auto-detect known restricted clients — keep a small list of gcloud's public client_ids and skip userinfo.profile for them. Brittle if Google rotates client_ids, but simple.
3. Document only — recommend gws auth setup for a dedicated client; document why gcloud's public client doesn't work.

Happy to send a PR for whichever direction you'd like. I have a working local patch implementing option 2 with auto-detect; option 1 would take a bit more work but is cleaner long-term.

Related

• The userinfo.profile scope was added to identity scopes as a fallback for People API display-name lookup in Gmail send-as. Dropping it doesn't break the primary login flow, only that secondary feature when the user has a Workspace account without a configured display name.