SAP Authentication
Authenticating to SAP APIs establishes who is calling and what they may do, via mechanisms ranging from basic auth to OAuth 2.0 and certificates. Correct, secure authentication is essential for any SAP integration.
SAP APIs authenticate four ways: OAuth 2.0 bearer tokens, the standard for S/4HANA Cloud and BTP; basic authentication, simple and weak; X.509 certificates and mutual TLS for system-to-system; and SAML or principal propagation to carry a user's identity through. Authentication proves identity; the backend authorisation objects then decide access, so an authenticated caller can still get a 403.
- For S/4HANA Cloud and BTP APIs, OAuth 2.
- Watch out: Basic auth over HTTP, credentials exposed.
Common authentication methods
- OAuth 2.0: token-based, preferred for cloud/modern APIs.
- Basic authentication: user/password, simple but weaker; avoid over HTTP.
- Certificate-based (X.509 / mTLS): strong, common for system-to-system.
- SAML/principal propagation: passing user identity through integration.
OAuth in the SAP context
For S/4HANA Cloud and BTP APIs, OAuth 2.0 is standard: a client obtains a token (e.g. client-credentials for system integration) and sends it as a bearer token. This avoids storing user passwords and supports scoped, revocable access, the modern best practice.
Security practices
Use OAuth or certificates over basic auth, always use TLS, store credentials/secrets securely (never in code), and apply least-privilege scopes/authorizations to integration users.
Common pitfalls
- Basic auth over HTTP, credentials exposed.
- Secrets in code instead of a secure store.
- Over-privileged integration users.