cube-js/cube · error

authorization was denied in the browser

Error message

authorization was denied in the browser

What it means

During the device-code login flow, the CLI polls the token endpoint per RFC 8628 §3.5. When the authorization server responds with error code `access_denied`, it means the user actively rejected the authorization request in the browser (clicked deny/cancel). The CLI treats this as a terminal outcome and aborts with this message.

Source

Thrown at rust/cube-cli/src/oauth.rs:163

            Err(_) => continue,
        };
        let status = res.status();
        let text = res.text().await.unwrap_or_default();

        if status.is_success() {
            return serde_json::from_str(&text)
                .map_err(|e| api_error(format!("could not parse token response: {e}\n{text}")));
        }

        // RFC 8628 §3.5: pending/slow_down keep polling; anything else is fatal.
        match serde_json::from_str::<TokenError>(&text) {
            Ok(err) => match err.error.as_str() {
                "authorization_pending" => continue,
                "slow_down" => {
                    interval += 5;
                    continue;
                }
                "access_denied" => bail!("authorization was denied in the browser"),
                "expired_token" => {
                    bail!("device code expired before it was authorized; run `cube login` again")
                }
                other => bail!(
                    "authorization failed: {other}{}",
                    err.error_description
                        .map(|d| format!(" ({d})"))
                        .unwrap_or_default()
                ),
            },
            Err(_) => api_bail!(
                "token poll failed ({status}) at {endpoint}: {}",
                text.trim()
            ),
        }
    }
}

View on GitHub (pinned to 7d981676b3)

Solutions

  1. Run `cube login` again and click Allow/Approve on the consent screen
  2. Verify you are signed into the correct Cube Cloud account in the browser before approving
  3. If the deny was not user-initiated, check your identity provider / org policies for rules blocking device authorization grants
Defensive patterns

Strategy: try-catch

Try / catch

// match on the bail message / error chain
if err.to_string().contains("authorization was denied in the browser") {
    // prompt user to re-run `cube login` and click Allow
}

Prevention

When it happens

Trigger: Raised in poll_for_token when the token endpoint returns a TokenError whose `error` field equals "access_denied" — i.e. the user (or an admin policy) denied the device authorization consent prompt.

Common situations: User clicked 'Deny' or 'Cancel' on the consent screen; user pasted the wrong device code into someone else's session; SSO/IDP policy auto-denies the request (e.g. device flow disabled, conditional access rules).

Related errors


AI-assisted analysis of cube-js/cube@7d981676b3 (2026-09-02). Data as JSON: /api/errors/73f668454edb2a2b. Report an issue: GitHub.