Secure SAP SuccessFactors APIs with SAP API Management and Microsoft Entra Token Exchange in IAS

April, 2026  |  SAP Integration Suite & Security

Introduction

Enterprise organizations frequently operate in multi-cloud environments where Microsoft Azure — and specifically Microsoft Entra ID (formerly Azure Active Directory) — serves as the primary identity provider. At the same time, SAP landscapes rely on SAP Cloud Identity Services – Identity Authentication (IAS) as the trusted token authority for SAP applications.

When these worlds need to meet at an API boundary — for example, a custom application or integration runtime managed in Azure that must consume SAP SuccessFactors APIs — a common question arises: how do you bridge identity without compromising security or creating brittle, hard-to-maintain workarounds?

This post walks through a standardized pattern that solves exactly this problem. Using SAP Integration Suite – API Management as the enforcement point, SAP Identity Authentication (IAS) as the canonical token issuer, and OAuth 2.0 JWT Bearer Token Exchange (RFC 7523) as the bridge mechanism, API consumers can present a native Microsoft Entra ID token and receive seamless, secure access to SAP SuccessFactors OData and REST APIs — with no custom identity mapping code required.

The Challenge: Two Identity Worlds, One API Gateway

SAP SuccessFactors enforces that API access tokens must be issued by a trusted identity provider. Historically, this meant developers either had to maintain separate credential sets within the SAP ecosystem or implement custom token-translation logic inside their integration middleware.

Neither approach scales well. Separate credentials introduce operational overhead and increase the attack surface. Custom token-exchange code is fragile, difficult to audit, and tightly coupled to specific implementation details.

The ideal solution standardizes identity at the API gateway layer, ensuring that:

API consumers authenticate against the identity provider they already trust — Microsoft Entra ID.The gateway handles token exchange transparently, with no changes required in client applications.SAP SuccessFactors receives only IAS-issued tokens, preserving SAP’s trust model.All token validation and exchange follows open, auditable standards (OAuth 2.0, OIDC, RFC 7523).

Solution Overview

The pattern uses SAP API Management as the central brokering point. Inbound API calls carry a Microsoft Entra ID JWT token. The API Management policy pipeline intercepts this token, exchanges it for an IAS-issued access token via a ServiceCallout policy, then forwards the IAS token to SAP SuccessFactors. The SuccessFactors API endpoint validates the IAS token and returns the requested data.

Component Role in the Pattern

Microsoft Entra IDIssues the initial JWT access token to the API consumer (service principal / app registration).API ConsumerAny client application that holds an Entra ID token.SAP API ManagementPerforms the JWT Bearer Token Exchange, and routes the call to SuccessFactors with the IAS token.SAP Identity AuthenticationAccepts the Entra JWT, validates it, and issues an IAS access token scoped for SuccessFactors.SAP SuccessFactorsTarget API. Accepts only IAS-issued tokens (as per SAP Note 3681224).

Architecture Diagram

Figure 1 — End-to-end authentication flow: API Consumer → Microsoft Entra ID → SAP API Management → SAP Cloud Identity Services (IAS) → SAP SuccessFactors

The diagram illustrates the trust relationships and communication paths:

Azure side: An app registration in Microsoft Entra ID issues access_token JWTs to the API consumer under the client_credentials grant type.SAP BTP side: Within SAP Cloud  identity Service – Identity Authentication (IAS) an IAS application representing SAP API Management is configured with Entra ID as a trusted (corporate) identity provider. A dependency link maps this IAS application to the IAS SuccessFactors application, which holds the scopes for SF APIs.SuccessFactors side: Create technical user with authorization (RBAC) according to the resources exposed in API. User Name should be the same as subject claim (Entra ID service principal). To avoid user claims in the IAS access token, the technical user should not be synchronized, created in IAS.

Step-by-Step Authentication Flow

Key Configuration Prerequisites

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

In the IAS administration console, configure Microsoft Entra ID as a Corporate Identity Provider and set it as the Default Identity Provider under Conditional Authentication for the SAP API Management application. This establishes the trust chain that allows IAS to accept Entra-issued JWTs during the RFC 7523 exchange.

2. IAS Application — Dependency Configuration

Two IAS application registrations are required:

IAS SAP API Management app — This is the application that the ServiceCallout authenticates against. It must haveGrant Type: JWT BearerTrusted token issuer: Entra IDDependency: e.g. APIM2SF (pointing to the IAS SuccessFactors app)IAS SuccessFactors app — Holds the OAuth scopes for SuccessFactors APIs and is referenced via the dependency link.

3. SAP SuccessFactors — Accept IAS-Issued Tokens

4. SAP API Management — Policy Configuration

The API proxy in SAP API Management must implement two policy steps:

A ServiceCallout policy to call the IAS token endpoint with the RFC 7523 parameters described above.A Set Authorization: Bearer policy to replace the inbound Entra token with the IAS token before routing to SuccessFactors.

Why This Pattern Works — Key Design Principles

This design is effective because it respects the trust model of each platform without forcing either side to accept a foreign token directly:

No credential sharing across platforms. Client applications never need SAP-specific credentials. They authenticate exclusively with Entra ID using their existing service principal.Standards-based token exchange. RFC 7523 is a well-specified IETF standard. Using it means the exchange logic is predictable, auditable, and interoperable.Centralized policy enforcement. SAP API Management is the single enforcement and mediation point. Token exchange logic lives in the gateway policy, not scattered across individual client applications.Transparent to API consumers. Client applications are completely unaware that a token exchange occurs. They present an Entra token and receive SuccessFactors data — the mediation is entirely internal to the gateway.SAP’s trust model is preserved. SuccessFactors only ever receives IAS-issued tokens, maintaining the integrity of the SAP identity trust chain.

Relevant Standards and References

Reference Description

RFC 7523JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants — defines the urn:ietf:params:oauth:grant-type:jwt-bearer grant type used for the token exchange.RFC 6749The OAuth 2.0 Authorization Framework — baseline specification for token request/response formats, including error responses.OIDCIdentity layer on top of OAuth 2.0. Microsoft Entra ID issues OIDC-compliant JWTs; IAS supports OIDC for trust federation.SAP Note 3681224SAP Identity Authentication (IAS) configuration to enable generation of IAS-issued access tokens. Part 1 – Must be applied before this pattern can be used. Part 2  – Manage OIDC OAuth Client Application is not needed in this scenario!

Conclusion

The JWT Bearer Token Exchange pattern described here provides a clean, standards-based path for enterprises running Microsoft Entra ID as their primary identity provider to consume SAP SuccessFactors APIs through SAP API Management — without compromising on security, maintainability, or SAP’s identity trust model.

By centralizing the token exchange in SAP API Management and leveraging the proven RFC 7523 grant type, organizations can:

Onboard new API consumers rapidly, using only their existing Entra ID service principal.Restrict authorizations per API consumers (Entra ID service principal) via RBAC in SAP SuccessFactors. Enforce consistent security policies at a single gateway layer.Avoid brittle, platform-specific identity workarounds.Maintain a clear audit trail of token issuance and exchange across both identity systems.

If your organization is evaluating multi-cloud API security patterns for SAP workloads, this approach is worth considering as part of your broader integration suite strategy.

​  April, 2026  |  SAP Integration Suite & SecurityIntroductionEnterprise organizations frequently operate in multi-cloud environments where Microsoft Azure — and specifically Microsoft Entra ID (formerly Azure Active Directory) — serves as the primary identity provider. At the same time, SAP landscapes rely on SAP Cloud Identity Services – Identity Authentication (IAS) as the trusted token authority for SAP applications.When these worlds need to meet at an API boundary — for example, a custom application or integration runtime managed in Azure that must consume SAP SuccessFactors APIs — a common question arises: how do you bridge identity without compromising security or creating brittle, hard-to-maintain workarounds?This post walks through a standardized pattern that solves exactly this problem. Using SAP Integration Suite – API Management as the enforcement point, SAP Identity Authentication (IAS) as the canonical token issuer, and OAuth 2.0 JWT Bearer Token Exchange (RFC 7523) as the bridge mechanism, API consumers can present a native Microsoft Entra ID token and receive seamless, secure access to SAP SuccessFactors OData and REST APIs — with no custom identity mapping code required.In scope: This pattern covers machine-to-machine (M2M) API access using the client_credentials grant type. The approach is equally applicable to service integrations, middleware, and automated data pipelines operating under a service principal identity registered in Microsoft Entra ID.The Challenge: Two Identity Worlds, One API GatewaySAP SuccessFactors enforces that API access tokens must be issued by a trusted identity provider. Historically, this meant developers either had to maintain separate credential sets within the SAP ecosystem or implement custom token-translation logic inside their integration middleware.Neither approach scales well. Separate credentials introduce operational overhead and increase the attack surface. Custom token-exchange code is fragile, difficult to audit, and tightly coupled to specific implementation details.The ideal solution standardizes identity at the API gateway layer, ensuring that:API consumers authenticate against the identity provider they already trust — Microsoft Entra ID.The gateway handles token exchange transparently, with no changes required in client applications.SAP SuccessFactors receives only IAS-issued tokens, preserving SAP’s trust model.All token validation and exchange follows open, auditable standards (OAuth 2.0, OIDC, RFC 7523).Solution OverviewThe pattern uses SAP API Management as the central brokering point. Inbound API calls carry a Microsoft Entra ID JWT token. The API Management policy pipeline intercepts this token, exchanges it for an IAS-issued access token via a ServiceCallout policy, then forwards the IAS token to SAP SuccessFactors. The SuccessFactors API endpoint validates the IAS token and returns the requested data.Component Role in the PatternMicrosoft Entra IDIssues the initial JWT access token to the API consumer (service principal / app registration).API ConsumerAny client application that holds an Entra ID token.SAP API ManagementPerforms the JWT Bearer Token Exchange, and routes the call to SuccessFactors with the IAS token.SAP Identity AuthenticationAccepts the Entra JWT, validates it, and issues an IAS access token scoped for SuccessFactors.SAP SuccessFactorsTarget API. Accepts only IAS-issued tokens (as per SAP Note 3681224).Architecture DiagramFigure 1 — End-to-end authentication flow: API Consumer → Microsoft Entra ID → SAP API Management → SAP Cloud Identity Services (IAS) → SAP SuccessFactorsThe diagram illustrates the trust relationships and communication paths:Azure side: An app registration in Microsoft Entra ID issues access_token JWTs to the API consumer under the client_credentials grant type.SAP BTP side: Within SAP Cloud  identity Service – Identity Authentication (IAS) an IAS application representing SAP API Management is configured with Entra ID as a trusted (corporate) identity provider. A dependency link maps this IAS application to the IAS SuccessFactors application, which holds the scopes for SF APIs.SuccessFactors side: Create technical user with authorization (RBAC) according to the resources exposed in API. User Name should be the same as subject claim (Entra ID service principal). To avoid user claims in the IAS access token, the technical user should not be synchronized, created in IAS.Step-by-Step Authentication FlowClient acquires a Microsoft Entra ID access token.The API consumer authenticates to Microsoft Entra ID using the client_credentials grant type and receives a signed JWT.# 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}}Client calls the SAP API Management endpoint with the Entra token.The Entra JWT is presented in the standard Authorization: Bearer header. The API Management proxy receives the request and begins policy evaluation.# Inbound API call to SAP API Management
GET https://{apim-host}/api/{resource-path}
Authorization: Bearer {{EntraAccessToken}}SAP API Management performs JWT Bearer Token Exchange (RFC 7523) via IAS.A ServiceCallout policy in the API proxy calls the IAS token endpoint. The Entra token is passed as the assertion parameter. The resource parameter targets the IAS dependency that represents the SuccessFactors application.# Token exchange request from APIM to IAS
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}}SAP IAS validates the Entra JWT and issues a SuccessFactors-scoped IAS token.IAS validates the inbound Entra JWT per RFC 7523 criteria (signature, issuer, audience, expiry). Because Microsoft Entra ID is configured as a trusted corporate identity provider in the IAS application, and the dependency link to the SuccessFactors IAS app is in place, IAS issues a new access token scoped for SuccessFactors. If validation fails, IAS returns an OAuth 2.0 error response (RFC 6749).SAP API Management forwards the call to SAP SuccessFactors with the IAS token.The API proxy replaces the inbound Entra token with the IAS access token and routes the request to the SuccessFactors OData or REST API endpoint. SuccessFactors validates the IAS token and returns the requested data.# Outbound API call from APIM to SuccessFactors
GET https://{sf-api-host}/odata/v2/{entity-set}
Authorization: Bearer {{IASAccessToken}}Key Configuration Prerequisites1. SAP Identity Authentication (IAS) — Corporate IdP SetupIn the IAS administration console, configure Microsoft Entra ID as a Corporate Identity Provider and set it as the Default Identity Provider under Conditional Authentication for the SAP API Management application. This establishes the trust chain that allows IAS to accept Entra-issued JWTs during the RFC 7523 exchange.2. IAS Application — Dependency ConfigurationTwo IAS application registrations are required:IAS SAP API Management app — This is the application that the ServiceCallout authenticates against. It must haveGrant Type: JWT BearerTrusted token issuer: Entra IDDependency: e.g. APIM2SF (pointing to the IAS SuccessFactors app)IAS SuccessFactors app — Holds the OAuth scopes for SuccessFactors APIs and is referenced via the dependency link.3. SAP SuccessFactors — Accept IAS-Issued TokensImportant: SAP SuccessFactors must be explicitly configured to trust and accept IAS-issued tokens. This is a prerequisite documented in SAP Note 3681224. Review and apply part 1 of this note before deploying the pattern.4. SAP API Management — Policy ConfigurationThe API proxy in SAP API Management must implement two policy steps:A ServiceCallout policy to call the IAS token endpoint with the RFC 7523 parameters described above.A Set Authorization: Bearer policy to replace the inbound Entra token with the IAS token before routing to SuccessFactors.Why This Pattern Works — Key Design PrinciplesThis design is effective because it respects the trust model of each platform without forcing either side to accept a foreign token directly:No credential sharing across platforms. Client applications never need SAP-specific credentials. They authenticate exclusively with Entra ID using their existing service principal.Standards-based token exchange. RFC 7523 is a well-specified IETF standard. Using it means the exchange logic is predictable, auditable, and interoperable.Centralized policy enforcement. SAP API Management is the single enforcement and mediation point. Token exchange logic lives in the gateway policy, not scattered across individual client applications.Transparent to API consumers. Client applications are completely unaware that a token exchange occurs. They present an Entra token and receive SuccessFactors data — the mediation is entirely internal to the gateway.SAP’s trust model is preserved. SuccessFactors only ever receives IAS-issued tokens, maintaining the integrity of the SAP identity trust chain.Relevant Standards and ReferencesReference DescriptionRFC 7523JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants — defines the urn:ietf:params:oauth:grant-type:jwt-bearer grant type used for the token exchange.RFC 6749The OAuth 2.0 Authorization Framework — baseline specification for token request/response formats, including error responses.OIDCIdentity layer on top of OAuth 2.0. Microsoft Entra ID issues OIDC-compliant JWTs; IAS supports OIDC for trust federation.SAP Note 3681224SAP Identity Authentication (IAS) configuration to enable generation of IAS-issued access tokens. Part 1 – Must be applied before this pattern can be used. Part 2  – Manage OIDC OAuth Client Application is not needed in this scenario!ConclusionThe JWT Bearer Token Exchange pattern described here provides a clean, standards-based path for enterprises running Microsoft Entra ID as their primary identity provider to consume SAP SuccessFactors APIs through SAP API Management — without compromising on security, maintainability, or SAP’s identity trust model.By centralizing the token exchange in SAP API Management and leveraging the proven RFC 7523 grant type, organizations can:Onboard new API consumers rapidly, using only their existing Entra ID service principal.Restrict authorizations per API consumers (Entra ID service principal) via RBAC in SAP SuccessFactors. Enforce consistent security policies at a single gateway layer.Avoid brittle, platform-specific identity workarounds.Maintain a clear audit trail of token issuance and exchange across both identity systems.If your organization is evaluating multi-cloud API security patterns for SAP workloads, this approach is worth considering as part of your broader integration suite strategy.Related resources:SAP Note 3681224 — SAP SuccessFactors: Enabling IAS token acceptanceSAP Cloud Identity Services – Identity Authentication documentationSAP API Management documentationIETF RFC 7523 — JWT Profile for OAuth 2.0   Read More Technology Blog Posts by SAP articles 

#SAP

#SAPTechnologyblog