May, 2026  |  SAP Integration Suite & Identity Security

Introduction

A recurring challenge in heterogeneous enterprise landscapes is enabling API consumers operating under a Microsoft Azure identity — authenticated via Microsoft Entra ID — to securely call SAP S/4HANA APIs without duplicating credentials, bypassing SAP's trust model, or building custom token-translation logic into every integration.

This post describes a robust, standards-based architecture that solves this challenge. SAP Integration Suite – API Management acts as the central enforcement and mediation point. SAP Cloud Identity Services – Identity Authentication (IAS) performs an OAuth 2.0 JWT Bearer Token Exchange (RFC 7523), converting the inbound Entra ID token into an IAS-issued access token that SAP S/4HANA trusts. The result: API consumers authenticate once with Entra ID and receive governed, auditable access to S/4HANA OData and REST APIs.

The Challenge: Bridging Azure Identity and SAP S/4HANA

SAP S/4HANA enforces a well-defined identity trust chain. For OIDC-based API access, the system expects tokens issued by a trusted identity provider — and will validate signature, claims, and timeliness before granting access. Beyond token validation, S/4HANA adds a critical additional step: it must resolve the token's claims to a concrete ABAP user before authorizing any API operation.

This two-layer requirement — token trust plus user mapping — makes direct presentation of a Microsoft Entra ID token to S/4HANA impractical. Entra tokens are not issued by a provider in S/4HANA's trust configuration, and the claim structure may not align with the ABAP user mapping mechanism without an explicit mediation layer.

For organizations running on-premise or private cloud S/4HANA, there is also a connectivity dimension: the API gateway on SAP BTP must reach S/4HANA through SAP Cloud Connector, adding another component to configure and operate correctly.

The pattern described here addresses all three concerns in a single, coherent design:

• Token trust — the IAS exchange bridges Entra ID into SAP's identity model.
• User mapping — the IAS-issued token carries the claims S/4HANA needs to resolve an ABAP user.
• Connectivity — SAP Cloud Connector provides the secure on-premise channel from API Management to S/4HANA.

Solution Overview

The architecture connects five components across three platforms — Azure, SAP BTP, and the S/4HANA landscape. Each plays a distinct and non-overlapping role.

Component Platform Role in the Pattern

Architecture Diagram

Several trust relationships underpin this architecture:

• Azure ↔ IAS: Microsoft Entra ID is registered as a Corporate Identity Provider in the IAS application that represents the SAP API Management integration. Entra ID is set as the default trusted issuer under Conditional Authentication for that application.
• IAS ↔ S/4HANA: The IAS S/4HANA application holds the OAuth scopes for S/4HANA APIs and is trusted by the S/4HANA system via OIDC configuration. The dependency between the IAS APIM application and the IAS S/4HANA application (APIM2S4HANA) enables the scoped token to be issued.
• BTP ↔ S/4HANA: SAP Cloud Connector establishes the secure tunnel between the SAP BTP subaccount hosting API Management and the S/4HANA system network.

Step-by-Step Authentication Flow

1. Client acquires a Microsoft Entra ID access token. The API consumer authenticates to Microsoft Entra ID using the client_credentials grant type. Entra ID issues a signed JWT access token bound to the registered application's identity.

   # Step 1 — Token request to Microsoft Entra ID
   POST https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token
   
   client_id     = {{ENTRAClientid}}
   client_secret = {{ENTRASecret}}
   grant_type    = client_credentials
   scope         = {{scope}}

2. Client calls the SAP API Management endpoint with the Entra token. The Entra JWT is passed in the standard Authorization: Bearer header. The API Management proxy receives the request and begins its policy chain evaluation. The client application has no knowledge of — and requires no changes for — the token exchange that follows.

   # Step 2 — Inbound call to SAP API Management
   GET https://{apim-host}/api/{resource-path}
   Authorization: Bearer {{EntraAccessToken}}

3. SAP API Management performs JWT Bearer Token Exchange (RFC 7523) via IAS. A ServiceCallout policy in the API proxy calls the IAS token endpoint, presenting the Entra token as the assertion and targeting the S/4HANA dependency via the resource parameter.

   # Step 3 — Token exchange: APIM calls IAS (RFC 7523)
   POST https://{ias-tenant}.accounts.ondemand.com/oauth2/token
   
   client_id     = {{IASClientid}}
   client_secret = {{IASSecret}}
   grant_type    = urn:ietf:params:oauth:grant-type:jwt-bearer
   assertion     = {{EntraAccessToken}}
   resource      = urn:sap:identity:application:provider:name:{{dependency}}

4. SAP IAS validates the Entra JWT and issues an S/4HANA-scoped IAS token. IAS validates the inbound Entra JWT against RFC 7523 criteria — signature integrity, issuer trust, audience binding, and token expiry. Because Entra ID is configured as a trusted Corporate Identity Provider in the IAS APIM application, and the dependency link to the IAS S/4HANA application (APIM2S4HANA) is in place, IAS issues a new access token scoped for S/4HANA APIs. If validation fails at any point, IAS returns an OAuth 2.0 error response per RFC 6749.

5. SAP API Management routes the request to S/4HANA via Cloud Connector, carrying the IAS token. The API proxy replaces the inbound Entra token with the IAS access token and forwards the request to the S/4HANA OData or REST API endpoint through SAP Cloud Connector.

   # Step 5 — Outbound call from APIM to S/4HANA (via Cloud Connector)
   GET https://{virtual-host}/{odata-service-path}
   Authorization: Bearer {{IASAccessToken}}

6. SAP S/4HANA validates the IAS token and resolves the ABAP user via claim mapping. S/4HANA performs a multi-step validation and authorization sequence unique to the ABAP platform. This step is described in detail in the next section.

S/4HANA Token Validation and ABAP User Mapping

The S/4HANA side of this pattern introduces a layer of processing that is specific to the ABAP platform and has no direct equivalent in other SAP API scenarios. Understanding it is essential for a successful implementation.

When SAP S/4HANA receives the IAS access token, it executes the following sequence:

1. Token Validation

S/4HANA verifies the token against multiple criteria:

• Digital signature check — the token signature is validated against the public keys of the trusted OIDC provider (IAS).
• Timeliness check — the iat, exp, and nbf claims are evaluated to confirm the token is currently valid.
• Token claim checks — audience (aud), issuer (iss), and other configured claims are verified against the OIDC trust configuration in S/4HANA.

2. ABAP User Mapping

Upon successful token validation, S/4HANA triggers user mapping. The purpose of user mapping is to resolve the token's identity to a known ABAP user account, so that ABAP authorization checks can proceed as usual.

The process works as follows:

1. S/4HANA reads the value of the configured User Mapping Claim from the token. Common choices include the sub (subject) claim or the oid (object identifier) claim, depending on the configuration.
2. That claim value is compared against the property selected in the User Mapping Mechanism — for example, matching against the ABAP user's logon name, email address, or a custom attribute.
3. If exactly one ABAP user matches the claim value, that user's session is established and their ABAP authorization profile governs the API request.
4. If no match is found, or if more than one user matches, S/4HANA rejects the request. Proper ABAP user provisioning and claim alignment are therefore prerequisites for successful authorization.

Key Configuration Prerequisites

1. SAP Identity Authentication (IAS) — Corporate IdP and Dependency Setup

Two IAS application registrations are required:

• IAS SAP API Management application — The application the ServiceCallout authenticates against. Configure:
  • Grant Type: JWT Bearer
  • Trusted token issuer: Entra ID (set as the Default Corporate Identity Provider under Conditional Authentication)
  • Dependency: APIM2S4HANA — links to the IAS S/4HANA application
• IAS S/4HANA application — Holds the OAuth scopes for S/4HANA APIs. This is the application S/4HANA trusts as its OIDC provider.

2. Microsoft Entra ID — App Registration

Register an application in Microsoft Entra ID for the API consumer service principal. Configure the client_credentials grant and assign the appropriate scope. Entra ID must be set as the Corporate Identity Provider in the IAS application configuration so that the RFC 7523 exchange can proceed.

3. SAP Cloud Connector — Virtual Host Mapping

For on-premise or private cloud S/4HANA systems, SAP Cloud Connector must be configured to expose the S/4HANA host as a virtual host accessible from the SAP BTP subaccount where API Management is deployed. The API Management target endpoint in the API proxy uses this virtual host address.

4. SAP S/4HANA — OIDC Trust Configuration and User Mapping

5. SAP API Management — Policy Chain

The API proxy requires two policy steps:

1. A ServiceCallout policy to call the IAS token endpoint with the RFC 7523 parameters (as shown in Step 3 above).
2. A Set Authorization: Bearer / Route to S4HANA API policy to replace the inbound Entra token with the IAS token and forward the call via the Cloud Connector virtual host.

Why This Pattern Works

The design is effective because it preserves the integrity of each platform's identity model while creating a clean, opaque mediation layer at the API gateway:

• No SAP credentials in the Azure estate. The API consumer never holds S/4HANA or IAS credentials. It authenticates exclusively with Entra ID using its existing service principal — reducing credential sprawl and audit surface.
• Standards-based, auditable exchange. RFC 7523 is a published IETF standard. The token exchange is deterministic, well-documented, and can be traced at each hop using standard OAuth 2.0 logging.
• Single policy enforcement point. Token exchange and routing logic reside entirely in the API Management policy chain — not duplicated across client applications. Changing the token exchange configuration requires updating one policy, not every consumer.
• Transparent to API consumers. The client presents an Entra token and receives S/4HANA data. All mediation — token exchange, routing via Cloud Connector, ABAP user resolution — is invisible to the consumer.
• S/4HANA's ABAP authorization model is preserved. Because user mapping resolves to a real ABAP user, all existing ABAP role and authorization object assignments apply to every API call. No bypass of the ABAP authorization layer occurs.

Standards and References

Reference Description

Part of a Broader Pattern Series

This scenario is part of a series documenting standardized OIDC-based API access patterns across the SAP portfolio using SAP API Management as the common enforcement layer. A companion blog post (Link) covers the same RFC 7523 JWT exchange pattern applied to SAP SuccessFactors APIs, where the S/4HANA-specific Cloud Connector connectivity and ABAP user mapping steps are replaced by the SuccessFactors IAS trust configuration (SAP Note 3681224). The core token exchange mechanics — and the IAS dependency model — are identical across both scenarios.

Conclusion

Exposing SAP S/4HANA APIs to Azure-native consumers does not require abandoning SAP's identity trust model or introducing platform-specific credential stores on the Azure side. The combination of SAP API Management, SAP Identity Authentication (IAS), and RFC 7523 JWT Bearer Token Exchange provides a clean, standards-based bridge that preserves the security posture of both platforms.

For on-premise and private cloud S/4HANA deployments, SAP Cloud Connector completes the connectivity picture without requiring S/4HANA to be directly internet-reachable. And the ABAP user mapping step ensures that S/4HANA's granular role-based authorization model continues to govern every API call — regardless of where the original identity token originated.

Teams building Azure-integrated SAP landscapes should consider this pattern as a reusable building block, applicable wherever an Entra ID service principal needs governed access to S/4HANA data through a centrally managed API gateway.