We’re exposing project accounting data through REST APIs to external partners and need to establish robust security practices. The APIs provide access to project costs, billing data, and resource allocations - all sensitive financial information.
Current concerns:
OAuth2 authentication implementation - should we use client credentials flow or authorization code flow for partner systems?
Audit logging for all API access - what’s the best way to track who accessed what data and when?
Hybrid deployment security - we’re on-premise now but planning cloud migration, need policies that work in both environments
Looking for real-world experiences with securing financial data APIs in S/4HANA 2020. What security patterns have worked well for you?
OAuth2 flow selection, audit logging, and hybrid-ready policy design are distinct problems — addressing each in sequence.
Pre-Upgrade / Pre-Implementation Checks
Before implementing any API security layer against project accounting data, verify:
Communication Management is configured in SAP BTP or your on-premise SAP API Management instance (verify feature parity in your version)
SM59 RFC destinations and SOAMANAGER bindings are inventoried — legacy channels can bypass OAuth controls if left open
SU24 authorization object checks are current for PS (Project System) and CO objects, particularly K_PCA, C_PRPS_KOK, and billing-related V_VBAK_AAT
CDS View exposure via /IWFND/MAINT_SERVICE is restricted — confirm which OData services surface WBS costs or billing documents before layering OAuth on top
Implementation Sequence
Select the correct OAuth2 flow. For machine-to-machine partner integrations (no human in the loop), use Client Credentials Flow. Authorization Code Flow is appropriate only when a human user delegates access — atypical for batch partner data pulls. In SAP API Management, configure the OAuthV2 policy with grant_type=client_credentials and bind scopes explicitly to project accounting resources.
Scope your tokens tightly. Define granular scopes: e.g., project.costs.read, project.billing.read, project.allocation.read. Never issue a broad financial-data scope. Map these scopes to PFCG roles via the OAuth 2.0 Scope assignment in transaction SU01 / Identity Provider federation (verify scope-to-role mapping behavior in S/4HANA 2020).
Enable gateway-level audit logging. In SAP API Management, activate access logs per API proxy — log client_id, timestamp, HTTP method, resource path, and response code at minimum. Do NOT rely solely on ABAP application logs; the gateway layer captures failed/rejected calls that never reach the backend.
Supplement with ABAP Security Audit Log. In SM19/SMSE, enable event class DU (authorization checks) for the technical RFC/service users executing project accounting reads. This captures backend authorization failures and successful access to sensitive CO/PS objects.
Implement field-level filtering at the CDS layer. Use @AccessControl.authorizationCheck: #CHECK annotations on CDS views exposing PRPS, COEP, and VBRP data. This enforces row-level access by controlling organizational unit visibility — critical when partners should see only their assigned projects.
Token lifetime and rotation policy. Set short-lived access tokens (≤ 1 hour) with no refresh tokens for client credentials flow. Force re-authentication per cycle. Document this in your partner integration contract.
Hybrid Deployment / Rollback Procedure
For your planned cloud migration, isolate security policy definitions in SAP API Management rather than embedding them in ABAP. This makes policies portable.
If a policy misconfiguration blocks legitimate partner access:
Revert the API proxy revision in SAP API Management to the last known-good deployment (proxy revision history is retained — verify retention period in your instance)
Re-enable the prior SM59 destination temporarily if gateway bypass is required for business continuity
Audit SLG1 for any authorization errors generated during the failed window
Do not roll back SM19 audit log activation — keep logging running throughout incident investigation
Hybrid-ready non-negotiables: centralize token issuance through a single Identity Provider (SAP IAS or external IdP federated to it) so the same OAuth client IDs work against both on-premise API gateway and BTP-hosted services post-migration. Avoid issuing separate credentials per environment.
This draft is based on general SAP S/4HANA knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
For partner systems accessing your APIs, client credentials flow is more appropriate than authorization code. These are system-to-system integrations, not user-facing apps. Client credentials gives you better control - you issue client ID/secret pairs per partner, can revoke access per partner without affecting others, and it’s simpler to implement. Use SAP Cloud Platform’s OAuth server or API Management for token generation and validation.
Audit logging is critical for financial data. Enable the Security Audit Log (SM19/SM20) and configure it to capture all RFC and HTTP calls to your project accounting APIs. Also implement application-level logging in your OData services to capture business context - which projects were accessed, what data was retrieved, not just technical call details. We log to a separate audit database that’s immutable and retained for 7 years per regulatory requirements. Make sure your logs include partner identification, timestamp, data scope, and response status.
For hybrid security policy, implement API Management as your abstraction layer. Whether you’re on-premise or cloud, partners always call the API Management endpoint. This gives you consistent security enforcement regardless of where S/4HANA runs. Use API Management for OAuth validation, rate limiting, IP whitelisting, and threat detection. When you migrate to cloud, partners don’t need any changes - just reconfigure API Management backend to point to cloud S/4HANA.
The API Management approach makes sense for hybrid deployment. How do you handle token expiration and refresh in client credentials flow? Don’t want partners getting authentication failures during long-running data extracts.
Set your access token lifetime to match typical API session duration - we use 3600 seconds (1 hour). Partners should implement automatic token refresh when they get 401 responses. Most HTTP clients have built-in OAuth retry logic. For long-running extracts, design your APIs to support pagination and resumption tokens so partners can break large requests into smaller chunks, each with its own fresh token.