[PLUGIN-1953] Support for client credentials Grant type by vikasrathee-cs · Pull Request #353 · data-integrations/salesforce

vikasrathee-cs · 2026-03-19T16:27:24Z

Support for client credentials Grant type

Jira : PLUGIN-1953

Summary

Adds support for the Client Credentials OAuth grant type to all Salesforce plugins (source, sink, streaming, connector).

Files updated

Widgets (UI)

Expose the OAuth Grant Type radio group and add a filter that hides username / password / securityToken when client_credentials is selected.

widgets/Salesforce-connector.json
widgets/Salesforce-batchsink.json
widgets/Salesforce-batchsource.json
widgets/Salesforce-streamingsource.json
widgets/SalesforceMultiObjects-batchsource.json

Docs

Document the new Grant Type field, clarify which fields are required per grant type, and note that client_credentials requires an instance-specific login URL.

docs/Salesforce-connector.md
docs/Salesforce-batchsink.md
docs/Salesforce-batchsource.md
docs/Salesforce-streamingsource.md
docs/SalesforceMultiObjects-batchsource.md

What's new

New config property authenticationGrantType backed by the pre-existing AuthenticatorCredentials.GrantType enum (password / client_credentials). Null is treated as password so upgraded pipelines that were saved before this change keep working without manual edits.

Validation

New validateAuthenticationFields(FailureCollector) on SalesforceConnectorBaseConfig:

Always required: consumerKey, consumerSecret, loginUrl.
Only required for password: username, password, securityToken.
Macro-aware skips any field whose value is a macro, and skips entirely if the grant type itself is a macro.
Each missing field reports its own failure tied to its withConfigProperty(...), so the UI highlights the exact field.

UI changes

New OAuth Grant Type radio group (inline layout, defaults to password) added to all five widget JSONs.
A GrantTypePassword filter hides username / password / securityToken when client_credentials is selected, so users only see the fields they need to fill in.

Screenshots

Radio [Password]

Radio [Client Credentials]

Missing value validation

Tests added

New file: SalesforceConnectorBaseConfigTest.java (250 lines) covering validateAuthenticationFields():

Password grant happy path + one test per missing field (consumerKey, consumerSecret, loginUrl, username, password, securityToken), including empty-string handling, plus an all-missing test that asserts exactly 6 failures on the right fields.
Client Credentials grant happy path, missing consumerKey / consumerSecret / loginUrl, explicit assertion that username / password / securityToken are not flagged, and an all-missing test that asserts exactly 3 failures.
Default behavior null authenticationGrantType falls back to PASSWORD validation rules.

Additional notes for reviewer

Backward compatibility: existing pipelines persisted without authenticationGrantType will deserialize with a null value, which getAuthenticationGrantType() maps to PASSWORD.
Login URL gotcha: client_credentials requires an instance-specific URL (e.g. https://<instance>.my.salesforce.com/services/oauth2/token) rather than the generic login.salesforce.com endpoint. This is called out in the updated docs.

itsankit-google

it is okay to remove null check because it is not required in certain cases.

But we should also add validation for the type when these configs are required.

vikasrathee-cs · 2026-03-23T07:24:46Z

it is okay to remove null check because it is not required in certain cases.

But we should also add validation for the type when these configs are required.

As of now, there is no explicit variable defined which calculates whether user is supporting password grant or client_creds. Based on the values, if user name and password are null, it will fallback to client creds automatically. This was done to support DTS use case I guess.

itsankit-google · 2026-03-25T12:18:48Z

it is okay to remove null check because it is not required in certain cases.
But we should also add validation for the type when these configs are required.

As of now, there is no explicit variable defined which calculates whether user is supporting password grant or client_creds. Based on the values, if user name and password are null, it will fallback to client creds automatically. This was done to support DTS use case I guess.

As discussed offline, this way we will not be able to maintain the extensibility of CDF plugin's ability to support multiple auth types.

We can add a AuthenticationType similar to google-cloud plugins to correctly fix this.

We can also hide certain fields in CDF Plugin UI based on authenticationType.

vikasrathee-cs · 2026-03-31T10:39:34Z

src/main/java/io/cdap/plugin/salesforce/plugin/sink/batch/SalesforceOutputFormatProvider.java

-                                                                                  getConsumerSecret()))
-        .put(SalesforceConstants.CONFIG_LOGIN_URL, Objects.requireNonNull(config.getConnection().getLoginUrl()));
+      switch (config.getConnection().getAuthenticationGrantType()) {
+        case BASIC_AUTHENTICATION:


there is no basic auth in salesforce, previously password grant type was supported and now it is client creds also

vikasrathee-cs · 2026-03-31T10:41:00Z

src/main/java/io/cdap/plugin/salesforce/plugin/SalesforceConnectorBaseConfig.java

+
+  public AuthenticationGrantType getAuthenticationGrantType() {
+    if (!Strings.isNullOrEmpty(authenticationGrantType) &&
+        authenticationGrantType.equals(AuthenticationGrantType.BASIC_AUTHENTICATION.getValue())) {


make it password grant type as default

this is handeled by the else case

// Default auth, handles null case when upgrading pipeline return SalesforceConstants.DEFAULT_GRANT_TYPE

vikasrathee-cs · 2026-03-31T10:42:49Z

widgets/Salesforce-batchsink.json

+    {
+      "name": "GrantTypeBasicAuthentication",
+      "condition": {
+        "expression": "authenticationGrantType == 'basicAuthentication'"


make it not clientCredentialsAuthentication, then it will be backward compatible.

vikasrathee-cs

change the auth type from based to password grant type

vikasrathee-cs · 2026-03-31T10:53:51Z

src/main/java/io/cdap/plugin/salesforce/AuthenticationGrantType.java

+ * Licensed under the Apache License, Version 2.0 (the "License"); you may not
+ * use this file except in compliance with the License. You may obtain a copy of
+ * the License at
+ *


AuthenticatorCredentials class already has a GrantType available which is getting used in DTS also, it should be set based on this UI property.

That existing class can be used instead of this.

removed this class

vikasrathee-cs · 2026-04-01T08:44:56Z

src/main/java/io/cdap/plugin/salesforce/plugin/sink/batch/SalesforceOutputFormatProvider.java

+              .put(SalesforceConstants.CONFIG_CONSUMER_SECRET,
+                      Objects.requireNonNull(config.getConnection().getConsumerSecret()))
+              .put(SalesforceConstants.CONFIG_LOGIN_URL, Objects.requireNonNull(config.getConnection().getLoginUrl()));
+      if (config.getConnection().getAuthenticationGrantType() == AuthenticatorCredentials.GrantType.PASSWORD) {


if grant type is password then only this configuration is mandatory

vikasrathee-cs added the build label Mar 19, 2026

vikasrathee-cs requested a review from MrRahulSharma March 19, 2026 16:32

MrRahulSharma requested a review from itsankit-google March 19, 2026 16:45

itsankit-google reviewed Mar 23, 2026

View reviewed changes

vikasrathee-cs changed the title ~~Removed null check for username password for client credentials type.~~ [PLUGIN-1953] Support for client credentials Grant type Mar 31, 2026

vikasrathee-cs commented Mar 31, 2026

View reviewed changes

vikasrathee-cs commented Apr 1, 2026

View reviewed changes

Support for client credentials Grant type

3b9051e

psainics force-pushed the client_creds branch from 686faaf to 3b9051e Compare April 7, 2026 12:42

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[PLUGIN-1953] Support for client credentials Grant type#353

[PLUGIN-1953] Support for client credentials Grant type#353
vikasrathee-cs wants to merge 1 commit intodevelopfrom
client_creds

vikasrathee-cs commented Mar 19, 2026 •

edited by atlassian bot

Loading

Uh oh!

itsankit-google left a comment

Uh oh!

vikasrathee-cs commented Mar 23, 2026

Uh oh!

itsankit-google commented Mar 25, 2026

Uh oh!

vikasrathee-cs Mar 31, 2026

Uh oh!

vikasrathee-cs Mar 31, 2026

Uh oh!

psainics Apr 1, 2026

Uh oh!

vikasrathee-cs Mar 31, 2026

Uh oh!

psainics Apr 1, 2026

Uh oh!

vikasrathee-cs left a comment

Uh oh!

vikasrathee-cs Mar 31, 2026

Uh oh!

psainics Apr 1, 2026

Uh oh!

vikasrathee-cs Apr 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

vikasrathee-cs commented Mar 19, 2026 • edited by atlassian bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Support for client credentials Grant type

Summary

Files updated

Widgets (UI)

Docs

What's new

Validation

UI changes

Screenshots

Tests added

Additional notes for reviewer

Uh oh!

itsankit-google left a comment

Choose a reason for hiding this comment

Uh oh!

vikasrathee-cs commented Mar 23, 2026

Uh oh!

itsankit-google commented Mar 25, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vikasrathee-cs left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

vikasrathee-cs commented Mar 19, 2026 •

edited by atlassian bot

Loading