Skip to Content

Salesforce security provider in Jitterbit App Builder

The Salesforce security provider enables Salesforce authentication and authorization. It is fundamentally an OAuth 2.0 security provider, supporting the following grants:

Configuration

See the OAuth security provider for configuration.

Note that Salesforce refers to the client identifer (client_id) and secret (client_secret) as the "consumer key" and "consumer secret."

Defaults

The Salesforce security provider defaults the following endpoints:

  • Authorization Endpoint: https://login.salesforce.com/services/oauth2/authorize
  • Token Endpoint: https://login.salesforce.com/services/oauth2/token

SAML 2.0 bearer assertion

When using the SAML 2.0 Bearer Assertion grant, the Salesforce provider will default the following properties:

  • Issuer: Defaults to the client identifier (client_id).
  • Audience: https://login.salesforce.com
  • Recipient: https://login.salesforce.com/services/oauth2/token

JWT bearer token

When using the JWT Bearer Token grant, the Salesforce provider will default the following properties:

  • Issuer: Defaults to the client identifier (client_id).

Known issues and limitations

Refresh token synchronization

Salesforce only maintains the previous 4 refresh tokens. Practically speaking, this means a different Connected App is required for each App Builder instance. Otherwise, each App Builder instance will retrieve a separate refresh token, possibly invalidating a refresh token used by another instance.

Multiple Salesforce instances

It is possible to configure multiple Salesforce instances. App Builder will maintain a separate set of security tokens for each instance. However, the user will have to log into each instance at least once. If the user has already logged into one instance, the user must sign out of that instance before logging into the second. Otherwise, Salesforce will skip the sign-in process. In other words, when the user attempts to log into the second instance, Salesforce may automatically log them into the first instance.

Prior authorization

When using either the SAML Bearer Assertion or JWT Bearer Token grants, Salesforce requires a prior authorization. In practice, this means that users must authenticate once using the Authorization Code grant.

SAML assertion source

The Salesforce security provider cannot source SAML assertions from a SAML Single Sign-On (SSO) provider. There are two reasons for this:

  1. Salesforce requires a prior authorization (see above). Forcing users to sign on with OAuth before authenticating with SAML SSO defeats the purpose.
  2. Salesforce expects the SAML assertion's Issuer to match the Connected Client's Consumer Key. Consumer Keys are opaque blobs. Though some SAML SSO Identity Providers (IdPs) can be configured to generate a SAML assertion with an arbitrary Issuer, they may describes the Issuer as urn:oasis:names:tc:SAML:2.0:nameid-format:entity. That format describes a URI. Since the Consumer Key can't be parsed as a URI, App Builder rejects the SAML assertion.