Skip to content

Salesforce query runner: migrate from SOAP login() to OAuth before Summer '27 deprecation #7709

Description

@mhayashi

Issue Summary

The Salesforce query runner (redash/query_runner/salesforce.py) authenticates with username + password + security token. Under the hood, simple-salesforce resolves this credential combination via the SOAP API login() call (/services/Soap/u/<version>).

Salesforce has announced that SOAP API login() for API versions 31.0–64.0 will be deprecated in the Summer '27 release, and is already unavailable in API version 65.0+. After deprecation, any component still relying on SOAP login() will fail to authenticate, and all subsequent API calls will fail.

Reference: Salesforce Release Update — "Deprecation of SOAP API login() Call for SOAP API Versions 31.0 through 64.0".

Current Implementation

redash/query_runner/salesforce.py (_get_sf):

sf = SimpleSalesforce(
    username=self.configuration["username"],
    password=self.configuration["password"],
    security_token=self.configuration["token"],
    sandbox=self.configuration.get("sandbox", False),
    version=self.configuration.get("api_version", DEFAULT_API_VERSION),
    client_id="Redash",
)

The configuration schema only accepts username, password, token, sandbox, and api_version. There is no OAuth path.

Additional concerns:

  • pyproject.toml pins simple-salesforce = "0.74.3", which is from 2019. The current release (1.12.x) natively supports OAuth flows that do not use SOAP login().
  • Summer '26 will introduce a new Use API Auth user permission gating SOAP login(), so even before the full removal, existing connections may start failing unless admins explicitly grant the permission.
  • Salesforce orgs created from now on already have SOAP login() disabled by default, so new Redash users effectively cannot connect to a newly created Salesforce org with the current implementation unless an admin re-enables SOAP login().

No upstream changes required in simple-salesforce

simple-salesforce 1.12.x already implements the OAuth flows Salesforce recommends as replacements for SOAP login(). From simple_salesforce/login.py:

Flow Endpoint Uses SOAP login()
Security token (current Redash) /services/Soap/u/ yes (deprecated)
IP filtering (organizationId) /services/Soap/u/ yes (deprecated)
OAuth Password Grant /services/oauth2/token no
JWT Bearer /services/oauth2/token no
Client Credentials /services/oauth2/token no

The migration can therefore be done entirely on the Redash side: upgrade the pin and expose the new flows through the data source configuration.

Proposed Changes

  1. Upgrade simple-salesforce from 0.74.3 to the latest 1.12.x release.
  2. Extend the configuration schema with an explicit auth_method selector and the corresponding fields:
    • password (existing flow, to be marked deprecated)
    • oauth_client_credentialsconsumer_key + consumer_secret (recommended replacement for service-account style usage)
    • oauth_jwtconsumer_key + private key + username (for setups that cannot share a secret)
  3. Update _get_sf() to pass only the arguments relevant to the selected method.
  4. Keep the username/password path working until Summer '27, but surface a deprecation notice in the UI.
  5. Update the Salesforce data source documentation with the steps to create an External Client App / Connected App and obtain the required credentials.

Timeline (from Salesforce)

  • Summer '26: New Use API Auth permission gates SOAP login().
  • API v65.0+: SOAP login() already unavailable.
  • Summer '27: SOAP login() for API v31.0–64.0 is removed.

Acceptance Criteria

  • Salesforce data source can be configured and used with at least one OAuth flow that does not depend on SOAP login() (Client Credentials at minimum, ideally JWT Bearer as well).
  • Existing username/password configurations continue to work until SOAP login() is removed, with a deprecation notice visible in the data source settings UI.
  • simple-salesforce is upgraded to a version that supports the OAuth flows used.
  • Documentation updated with the new OAuth setup steps.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions