Authentication Types and Proxy Types in Destinations: Choosing the Right Configuration

Explanation

Once a consultant understands what a destination is, the next critical skill is choosing the correct authentication type and proxy type, because these two properties determine how the platform actually establishes trust and routes traffic to the target system. Getting this wrong is one of the most common causes of failed integrations in production, and it is rarely obvious from the error message alone. Proxy Type controls the network path. 'Internet' means the BTP runtime calls the target system directly over the public internet, appropriate for SaaS APIs, SuccessFactors, Ariba, or any endpoint reachable without a tunnel. 'OnPremise' means traffic is routed through the Cloud Connector tunnel to a system inside a customer's private network, typically an on-premise ECC or S/4HANA system, or an internal middleware box. Selecting the wrong proxy type produces immediate connection failures: choosing Internet for a system only reachable via Cloud Connector results in DNS or connection-refused errors, while choosing OnPremise for a public SaaS endpoint results in the platform trying to route through a Cloud Connector that has no matching virtual-to-internal mapping, producing a 'destination not found in Cloud Connector' style error. Authentication Type controls how the call is secured once the network path is established. Common options include: - NoAuthentication: used for public endpoints or systems where security is handled downstream; rarely appropriate for production business data. - BasicAuthentication: username and password sent with each call; simple but requires credential rotation discipline and is unsuitable for systems requiring end-user identity propagation. - OAuth2ClientCredentials / OAuth2SAMLBearerAssertion / OAuth2UserTokenExchange: token-based flows used heavily with SAP SuccessFactors, S/4HANA Cloud public edition APIs, and other OAuth-secured services; require correct token endpoint, client ID/secret (often from a service key), and scope configuration. - PrincipalPropagation: used specifically with OnPremise proxy type and Cloud Connector, allowing the logged-in BTP user's identity to be propagated to the backend system via a trust configuration (certificate-based), so the backend can apply its own authorization rather than a generic technical user. - ClientCertificateAuthentication: mutual TLS, used for systems that authenticate via X.509 client certificates rather than credentials. A frequent architectural decision is whether to use a generic technical user (Basic or OAuth2ClientCredentials) or principal propagation. Technical users are simpler to configure and debug, and are appropriate for background/batch integration scenarios where there is no interactive end user. Principal propagation is required when the backend must apply user-specific authorizations, such as an S/4HANA on-premise system enforcing organizational-level restrictions per employee, but it introduces additional moving parts: a trust relationship must exist between the Cloud Connector and the backend's identity provider or a client certificate must be issued and mapped to backend users, and the Cloud Connector must be configured to allow principal propagation for the specific system mapping. At runtime, when an application or integration flow reads a destination, the Destination service resolves the full set of properties (URL, proxy type, authentication type, and any associated credentials or certificates) and returns them to the calling runtime, which then executes the actual authentication handshake. For OAuth2 flows, this may include the Destination service silently fetching and caching an access token on the application's behalf before returning connection details, reducing latency for repeated calls. Troubleshooting typically starts with the 'Check Connection' feature in the BTP cockpit, which validates that the destination configuration is syntactically correct and that the network path is reachable, but does not fully validate application-level authentication success in all cases. Deeper validation, such as confirming a valid OAuth token was issued or that Cloud Connector principal propagation succeeded, usually requires checking Cloud Connector logs, the Connectivity service's diagnostic tools, or backend authorization traces. A consultant should also verify that certificate-based trust has not expired, since certificate rotation is a common source of intermittent production failures that appear suddenly after months of stable operation.

Code example

// Example destination configuration illustrating OnPremise with PrincipalPropagation// (values shown for illustration only; actual property names must match// the destination configuration screen or configuration file in use) Name=S4_ONPREM_PPType=HTTPURL=http://virtual-host-defined-in-cloud-connector:8000ProxyType=OnPremiseAuthentication=PrincipalPropagationCloudConnectorLocationId=LOC1 // Example destination configuration for a SaaS OAuth2 client-credentials scenarioName=SFSF_OAUTHType=HTTPURL=https://api.successfactors.example.comProxyType=InternetAuthentication=OAuth2ClientCredentialstokenServiceURL=https://api.successfactors.example.com/oauth/tokenclientId=<from service key>clientSecret=<from service key> // Note: property names above are illustrative; always confirm exact field// labels in the destination configuration UI or service documentation// for the specific service instance being used.

Real project scenario

A project team building an employee self-service app on BTP needed the app to show only the leave records the logged-in employee was authorized to see in the on-premise S/4HANA system. Initially the team configured the destination with BasicAuthentication using a generic technical user, which worked functionally but returned all records because the backend had no way to know which real user was calling. The team reconfigured the destination to OnPremise proxy type with PrincipalPropagation, coordinated with the basis team to establish the Cloud Connector-to-backend trust and map client certificates to backend user IDs, and validated the change in a non-production system before promoting it, since incorrect trust configuration could have caused a full outage of the integration.

Common mistakes

• Selecting Internet proxy type for a system that is only reachable via Cloud Connector, causing immediate connection failures. • Using PrincipalPropagation without first confirming that the Cloud Connector-to-backend trust configuration exists and is mapped correctly. • Assuming 'Check Connection' success in the cockpit guarantees full end-to-end authentication success at the application layer. • Hardcoding OAuth2 client secrets directly in destination properties instead of referencing values from a service key or secure credential store. • Not planning for certificate expiration in ClientCertificateAuthentication or PrincipalPropagation scenarios, leading to sudden production failures. • Mixing up authentication types between environments (e.g., Basic in dev, OAuth2 in production) without updating dependent integration flows accordingly.

Best practices

• Match proxy type strictly to the actual network reachability of the target system, verified with the basis or network team. • Reserve PrincipalPropagation for scenarios that genuinely require per-user backend authorization; use technical users for batch and background integration. • Store OAuth2 client credentials and certificates in secure credential stores or service keys rather than plain destination properties where the platform supports it. • Document the authentication type and its prerequisites (trust, certificates, token endpoints) alongside each destination for support handover. • Include destination authentication validation as an explicit step in deployment and cutover checklists, not just a network connectivity check. • Monitor certificate and token expiration proactively rather than reactively after a production incident.

Interview angle

Interviewers commonly ask candidates to explain the difference between Internet and OnPremise proxy types, and to describe when principal propagation is appropriate versus a technical user. A strong answer distinguishes network routing (proxy type) from identity/authorization (authentication type), explains the trust prerequisites for principal propagation, and can describe a realistic troubleshooting sequence when a destination call fails intermittently in production.