Destinations
BTP & Integrationadvanced

BTP Destinations Part 3: Choosing the Right Authentication and Proxy Type

Key takeaway

Decide authentication by scenario: technical integration, user-specific access to on-premise (principal propagation), user-specific access to cloud (OAuth2 SAML bearer / token exchange / JWT bearer), certificate-based auth — and troubleshoot 401/403/500 errors with destination, Cloud Connector and back-end traces.

Explanation

📌 KEY POINTS
✅ Technical scenarios (batch, system integration): OAuth2 client credentials, client certificate or basic with technical user.

✅ User on-premise: principal propagation (needs Cloud Connector system certificate and back-end trust/rules).

✅ User to cloud APIs: OAuth2 SAML bearer, user token exchange or JWT bearer, depending on the target.

✅ Troubleshoot layer by layer: destination → connectivity → Cloud Connector → back end.

⚠️ Principal propagation fails silently into anonymous/401 if the back-end certificate mapping is incomplete.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE

Part 2 covered configuration. Now decisions and troubleshooting.

━━━━━━━━━━━━━━━━━━━━
▶ 1. TECHNICAL ACCESS

  • Client credentials, certificate, basic (technical).

━━━━━━━━━━━━━━━━━━━━
▶ 2. USER ON-PREMISE

  • Principal propagation chain.

━━━━━━━━━━━━━━━━━━━━
▶ 3. USER CLOUD

  • SAML bearer, token exchange, JWT bearer.

━━━━━━━━━━━━━━━━━━━━
▶ 4. ERRORS

  • 401 auth, 403 authorization, 500/503 routing.

━━━━━━━━━━━━━━━━━━━━
▶ 5. TRACES

  • Cloud Connector audit/trace, back-end logs.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

  1. Classify each integration as technical or user-based.
  2. Pick auth type per decision matrix.
  3. Test and trace failures layer by layer.

✅ CHECKPOINT: every destination has a documented reason for its auth type.

Code example

ABAP Code
===== DECISION MATRIX =====Technical, cloud API → OAuth2ClientCredentials / client certificateTechnical, on-prem → BasicAuthentication (technical user) or client certificate via SCCUser, on-prem → PrincipalPropagation (SCC system certificate + back-end CERTRULE/mapping)User, cloud (SAP SaaS) → OAuth2SAMLBearerAssertion / OAuth2UserTokenExchange / OAuth2JWTBearer ===== TROUBLESHOOTING =====401 → credentials/token/certificate mapping | 403 → back-end authorizations | 503 → SCC not connected / resource not exposed

Real project scenario

Users of an SAP Build app saw 401 errors when calling S/4HANA on-premise via principal propagation. Cloud Connector traces showed the short-lived certificate was created, but the back end had no certificate-to-user mapping rule. Adding the rule fixed it.

Common mistakes

  • Permanent technical fallbacks.
  • Skipping trace analysis.
  • Incomplete PP setup.
  • Wrong flow for SaaS APIs.
  • No documentation.

Best practices

  • Decision matrix.
  • Layered troubleshooting.
  • Complete PP chain.
  • Match target's supported flow.
  • Document reasons.

Interview angle

Questions: "Which auth for user access to on-premise?", "How do you troubleshoot principal propagation?", "When use SAML bearer?"
Strong answer: decision matrix, PP chain, cloud user flows, layered troubleshooting.

Practice this lesson

Quick check

1. A destination is configured with Authentication set to 'NoAuthentication' to call a publicly accessible REST API that requires no credentials. What is a correct implication of this configuration?

2. A destination is configured with Authentication set to 'ClientCertificateAuthentication' for a system requiring mutual TLS. What additional configuration is required for this destination to function correctly?

3. A destination is configured with Authentication type 'OAuth2ClientCredentials' pointing to an external API. What does this authentication type require the runtime to do before calling the target system?

Interview questions

1. A production issue is reported in Destinations. What would you check first, and how would you troubleshoot it systematically?

Answer it in your own words first, then compare.

2. Suppose you inherit an existing Destinations solution. How would you review it before making a change?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.

More lessons in this topic

Interview questions on this topic

Related SAP topics