Welcome back to our series on secure data connectivity in Salesforce Data Cloud! In Part 1, we explored the foundational concepts of authentication and authorization, along with Salesforce’s robust integration framework, including Named Credentials and External Credentials. Now, in Part 2, we’ll dive deep into the practicalities: understanding the diverse authentication modes supported by Data Cloud connectors and providing clear, step-by-step guides for setting up these crucial connections.
Salesforce Data Cloud is engineered to connect with a vast array of external systems. This necessitates support for a diverse set of authentication and authorization methods, ensuring organizations can integrate virtually any data source while adhering to stringent security standards. The specific authentication method chosen for a connector is always dictated by the capabilities and security requirements of the external system, ranging from simple credential-based access to complex token-based delegation. Understanding these nuances is key for administrators to ensure both seamless functionality and robust security.
Understanding Data Cloud Connector Authentication Modes & Setup
Let’s break down the primary authentication modes you’ll encounter when connecting external data sources to Salesforce Data Cloud, complete with conceptual explanations and practical setup steps.
Basic Authentication (Username/Password)
The traditional approach, known as Basic Authentication, sends credentials (typically base64-encoded) in HTTP headers with every request. While straightforward to implement, it is inherently less secure because the same static credentials are repeatedly transmitted. At Salesforce, this pattern is protected by HTTPS/TLS, ensuring encryption in transit, but it still lacks modern safeguards such as token expiration, scoped access, and automated rotation.
References:
API Key Authentication
API keys are static credentials issued to applications rather than individual end-users. They are easy to generate and integrate but have security limitations. They typically do not expire automatically, lack granular scopes, and provide no standardized lifecycle management. If an API key is leaked, it remains valid until explicitly revoked or rotated, making it vulnerable compared to OAuth, which enforces short-lived tokens, scoped access, and refresh mechanisms.
References:
Key-Pair Authentication
This method relies on asymmetric cryptography, where a public key is stored on the server and Salesforce Data Cloud holds the corresponding private key. When a connection is established, Data Cloud uses the private key to cryptographically prove its identity without transmitting sensitive secrets. SFTP connector popularly leverages this mechanism.
For SFTP connections, two variants are supported:
- SSH Private Key
- SSH Private Key & Password (adds passphrase protection)
Reference:
The password option provides defense-in-depth. Even if the key file is stolen, the passphrase is still required to gain access.
OAuth 2.0
OAuth 2.0 is the industry-standard authorization framework designed for secure delegated access to protected resources without the client application ever needing to handle the actual credentials. Instead, it issues time-limited “access tokens” that grant specific, limited permissions.
Essential OAuth 2.0 Concepts for Data Cloud
Client Credentials Flow: Machine-to-Machine Automation
The Client Credentials Flow is an OAuth 2.0 grant type specifically designed for machine-to-machine (M2M) applications or backend services that need to authenticate and access resources without direct user interaction. In this flow, the application exchanges its own credentials (a client ID and client secret) directly with the authorization server to obtain an access token.
Note: To aid simplicity, Salesforce client and backend are being represented as a single entity. It should also be understood that Salsforce is being accessed via a browser which acts as the client.
Reference:
Authorization Code Grant Flow
The Authorization Code Grant flow is a secure OAuth 2.0 method where an authorization server issues a temporary authorization code to a client application. This flow is typically used for confidential clients (like web applications with secure backends) and involves user interaction.
Reference:
Note: Meta Ads also uses a similar Browser Flow for authentication, enabling secure access to ad data after user consent. To aid simplicity, Salesforce client and backend are being represented as a single entity. It should also be understood that Salsforce is being accessed via a browser which acts as the client.
JWT Bearer Flow: Server-to-Server Trust
The OAuth 2.0 JWT Bearer Flow is also a server-to-server authentication method that allows applications to access protected resources without direct user interaction. Instead of a traditional login, the client application constructs a JSON Web Token (JWT) and signs it with a private key from a pre-configured X.509 certificate. This signed JWT is then sent to the authorization server’s token endpoint. Data Cloud Ingeation API leverages this flow.
Reference:
Note: To aid simplicity, Salesforce client and backend are being represented as a single entity. It should also be understood that Salsforce is being accessed via a browser which acts as the client.
Both Client credentials and JWT Bearer flows are leveraged for machine to machine integrations, but they differ in how the client proves its identity and in their flexibility.
Ready for more? In Part 3 of our series, we’ll explore our newest launches around federated authentication in Data Cloud and dive into essential security best practices for data ingestion.
Written by
