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
- Run `cube login` again and click Allow/Approve on the consent screen
- Verify you are signed into the correct Cube Cloud account in the browser before approving
- 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
- Click Allow/Approve on the consent screen
- Sign into the correct account in the browser before authorizing
- Verify your identity provider does not auto-deny device authorization grants
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
- device code expired before it was authorized; run `cube logi
- authorization failed: {other}{}
- Provided token isn't for ${dotCubeCloud.url}
- Failed to get access token: ${res.statusText}
- context `{name}` not found in config (run `cube login --cont
AI-assisted analysis of cube-js/cube@7d981676b3 (2026-09-02).
Data as JSON: /api/errors/73f668454edb2a2b.
Report an issue: GitHub.