cube-js/cube · error

authorization failed: {other}{}

Error message

authorization failed: {other}{}

What it means

Catch-all for any token-endpoint error code the device-flow polling loop does not specifically recognize. Per RFC 8628 §3.5 only `authorization_pending` and `slow_down` are transient; `access_denied` and `expired_token` get dedicated messages, and every other `error` value is fatal. The server's optional `error_description` is appended for context.

Source

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

        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()
            ),
        }
    }
}

/// Exchange a refresh token for a new access/refresh token pair
/// (OAuth 2.0 refresh_token grant). Used transparently by the API client
/// when an access token has expired.
pub async fn refresh(

View on GitHub (pinned to 7d981676b3)

Solutions

  1. Read the appended error_description and the raw error code for the server's exact reason
  2. Verify the OAuth client_id/client_secret configured for the CLI match a valid client on the auth server
  3. Confirm the auth server supports the device authorization grant (urn:ietf:params:oauth:grant-type:device_code)
  4. Run `cube login` again after fixing configuration; if it persists, check the provider's status or CLI version vs. API changes

Example fix

// before: stale/mismatched client credentials
client_id: "old-client"

// after: update CLI config / re-authenticate
cube login  // with a client_id registered for device flow
Defensive patterns

Strategy: try-catch

Try / catch

match err.to_string() {
    m if m.starts_with("authorization failed: ") => {
        let code = m.trim_start_matches("authorization failed: ");
        // inspect code/description, fix OAuth client config, retry login
    }
    _ => {}
}

Prevention

When it happens

Trigger: Raised in poll_for_token when the token endpoint returns a TokenError whose `error` string matches none of authorization_pending/slow_down/access_denied/expired_token — e.g. `invalid_grant`, `invalid_client`, `unauthorized_client`, or `invalid_request`.

Common situations: Misconfigured OAuth client_id/client_secret in the CLI's OAuthConfig; the provider revoked or disabled the client; provider returns a non-standard error code; server-side policy rejects the device grant entirely.

Related errors


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