SAP BTP Destinations and Authentication Types

Destination service lets applications refer to a named target rather than hard-code endpoint/credentials. Internet targets use direct proxying; on-premise targets can use the Connectivity service/Cloud Connector. Technical-user patterns authenticate the application itself, such as OAuth client credentials. User-centric patterns exchange/propagate the logged-in user's token/identity so backend authorization can run per user. Certificate-based destinations avoid password sharing but add certificate lifecycle. Additional properties can drive adapters/framework behavior, but secret material should remain managed by platform services.

Use a destination whenever multiple BTP applications/integration artifacts need centrally governed target configuration or when the SDK/framework expects Destination service. Choose client credentials for system-to-system operations where one technical identity is correct. Choose user propagation/token exchange when audit/authorization must reflect the end user. Use principal propagation for supported cloud-to-on-premise identity flow through Cloud Connector. Do not select Basic simply because it is easiest.

Applications obtain destination configuration/token material from Destination service; Connectivity handles OnPremise routing; Cloud Connector maps internal resources; XSUAA/IAS/identity services provide user/client tokens depending on architecture. The backend still validates scopes/roles/SAP authorizations. API Management can use a destination/backend but adds proxy policies. Cloud Integration adapters can also externalize connection properties/credentials rather than embedding them in iFlows.

A BTP app displays purchase orders according to the logged-in user's S/4HANA authorizations. A client-credentials destination would make every request run as one technical user and could expose data beyond the user's role. The design uses supported user propagation/token exchange so S/4HANA sees the business user. A nightly batch integration instead uses a least-privilege technical client because no interactive user exists.

BTP Destinations are a key clean-core connectivity mechanism for S/4HANA side-by-side extensions. SAP's current destination service supports a wide range of OAuth, certificate and propagation methods. The correct method depends on the released S/4HANA API/communication scenario and deployment model.

BTP administrators own destination configuration/secrets; Security architects choose identity model; app/integration teams consume the named destination; backend Security/Application teams define authorizations/scopes.

Cloud Connector explains OnPremise routing. Principal propagation explains end-user identity forwarding. API Management adds policies in front of APIs, while destinations remain backend connectivity configuration.

Production verification: Capture tenant/subaccount, artifact or API-proxy name/version, message/correlation ID, source and target endpoints, authentication flow, HTTP/status or broker outcome, retry count, and target business document ID. Use MPL/trace only for the shortest necessary diagnostic window and avoid logging secrets or sensitive payload fields.

Operational readiness: For production readiness of SAP BTP Destinations and Authentication Types, add an operational runbook that names the source owner, integration/platform owner and target application owner; defines correlation, retry/replay and duplicate handling; and states where a support engineer can prove the last successful handoff. Test authentication expiry, receiver outage, malformed/business-invalid payloads and ambiguous timeouts—not only the happy path. If the interface is asynchronous, document queue/retention/order behavior and how a corrected message is reprocessed without duplicating a business transaction.

Review checkpoint: Review checkpoint for SAP BTP Destinations and Authentication Types: document one successful message and one intentionally failed message from source to target, including the correlation key visible in every participating monitor. Record whether the operation is synchronous, queued, retried or event-driven and what constitutes final business success. Verify secret and certificate ownership, expiry monitoring, destination or endpoint promotion between environments, timeout behavior, and the exact manual replay procedure. A support engineer should be able to determine within minutes whether the failure belongs to source data, BTP connectivity or security, middleware processing, target API validation, or downstream business posting.