Clean Core Architecture Guide #53

SAP Clean Core OAuth2 mTLS & Zero-Trust Security Guide

⏱️ 15 min read 🏢 Enterprise Architectural Blueprint 🛡️ Security Baseline 2024

1. The Evolution of SAP API Security

Legacy SAP landscapes relied heavily on static technical users (DIALOG or COMMUNICATION type) with long-lived passwords stored in cleartext configuration files.

Security Mechanism	Credential Exposure Risk	Revocation Granularity	Clean Core Compliance
HTTP Basic Authentication	Extreme (Password sniffed or leaked in logs)	Global password change breaks all interfaces	❌ Strictly Deprecated
Static API Keys	High (Tokens committed to git repos)	Tenant-wide revocation needed	❌ Non-Compliant
OAuth 2.0 Client Credentials	Low (Short-lived 3600s tokens)	Automated client credential rotation	⚠️ Minimum Baseline
Mutual TLS (mTLS) + OAuth2 Token Exchange	Zero (Cryptographic private key never leaves client)	Instant CRL / OCSP certificate revocation	✅ Gold Standard Clean Core

2. Anatomy of Mutual TLS (mTLS) in S/4HANA

In standard TLS, only the server proves its identity to the client. In Mutual TLS (mTLS), the SAP S/4HANA ICM (Internet Communication Manager) challenges the incoming BTP client to present a trusted X.509 client certificate during the TLS handshake before any HTTP payload is processed.

• FIPS 140-3 Compliance: Enforces RSA 4096-bit or ECDSA secp384r1 keys.
• Subject Alternative Name (SAN): Must contain the fully qualified BTP application domain or subaccount URN.
• No Shared Secrets: Private keys remain securely stored in the BTP Destination Keystore; only the public certificate is uploaded to S/4HANA Communication Users.

3. OAuth 2.0 JWT Bearer Token Exchange (RFC 7523)

When external third-party applications (e.g. Salesforce or external portals) invoke S/4HANA APIs, they should not authenticate directly against the ERP system.

The Clean Core pattern leverages SAP Cloud Identity Services (IAS) as an identity broker:

1. The client requests a JWT from its corporate IdP (Microsoft Entra ID / Okta).
2. The client presents this assertion to SAP IAS via RFC 7523 token exchange.
3. SAP IAS validates the signature, maps the user to an internal enterprise identity, and issues a short-lived S/4HANA-scoped OAuth2 token.
4. The token is presented to S/4HANA, which grants access strictly based on ABAP Cloud DCL authorization master checks.

4. Automating with SAP Communication Arrangements

In SAP S/4HANA Cloud (Public & Private), security configurations are never done via raw transaction codes (SU01 / SICF). Instead, developers configure Communication Arrangements:

• App F1762 (Communication Systems): Binds the external BTP host and designates trusted root CA certificates.
• App F1763 (Communication Arrangements): Links a standard scenario (e.g. SAP_COM_0008 for Sales Orders) to the communication user, automatically exposing the approved Tier-1 RAP OData V4 services.

Summary Architectural Checklist

• ✅ Zero Passwords in Code: All connections use mTLS keystores or OAuth2 JWT tokens.
• ✅ Certificate Rotation Plan: 365-day automated keystore rotation with alerting.
• ✅ Identity Brokering via IAS: Centralized governance connecting Azure AD/Okta to S/4HANA.
• ✅ Audited Authorization: DCL checks executed on every API call under verified identity.