Introduction
Security is the cornerstone of any API strategy. In SAP Integration Suite's Edge Integration Cell (EIC), the Authentication Policy is the first line of defence for every API artifact — and it is non-deletable by design. This is intentional: no API should ever be reachable without an authentication gate.
Until recently, this policy supported only SAP tenant specific XSUAA-based authentication — a robust mechanism tightly coupled to the SAP Business Technology Platform (BTP) identity ecosystem. While this works perfectly for SAP-native landscapes, modern enterprises increasingly rely on external Identity Providers (IDPs) — whether it's SAP Identity Authentication Service (SAP IAS, Entra, or any OIDC-compliant provider — to manage identities across their application portfolio.
That's where the new External Auth (OIDC) authentication capability comes in.
In this blog, I'll walk you through:
- What the Authentication Policy is and why it is fundamental to EIC
- The difference between SAP Tenant specific XSUAA and External (OIDC) authentication — when to use which
- A real-world walkthrough using a SuccessFactors (SFSF) API secured with SAP IAS and JWT Bearer grant type
Whether you are an integration consultant, an API developer, or a decision-maker evaluating EIC's security posture, this blog is for you.
Background: The Authentication Policy in EIC API Artifacts
When you create an API artifact in SAP Integration Suite and target it to an Edge Integration Cell runtime, an Authentication Policy is automatically attached to the API. This policy sits at the ingress — meaning it validates every inbound request before any other policy, mediation or routing logic executes.
Key characteristics of this policy:
- It is default and non-deletable — enforcing the principle that no API artifact can run unauthenticated
- It governs who is allowed to call your API
Prior to the External Auth feature, the only supported mode was Tenant specific Authentication using SAP XSUAA tokens issued from BTP. Now, with the introduction of External Authentication, you can configure the policy to validate tokens issued by any OIDC-compliant external IDP.
Tenant specific XSUAA vs. External Authentication: What's the Difference?
SAP Tenant specific XSUAA Authentication
The calling application obtains an OAuth 2.0 access token from SAP XSUAA — the authorization server embedded in SAP BTP. This token is then passed in the Authorization header when invoking the API artifact URL on EIC. EIC runtime validates the token against the BTP subaccount's XSUAA instance. The token's audience, client credentials, and scopes are checked internally within the SAP trust chain.
When to use it:
- The calling application is built on SAP BTP (e.g., a BTP-hosted app, a CAP service, or another Integration Suite artifact)
- Your identity landscape is fully SAP-native
- You want zero configuration overhead — XSUAA trust is pre-established within the SAP ecosystem
- Internal system-to-system calls where all principals live in BTP
Minimal configuration, since EIC and BTP share the same trust domain, you primarily use either type (“oAuth”, “Basic”, “Client Certificate” ) and token is generated/validated with XSUAA
External Authentication (OIDC-based External IDP)
The calling application obtains a JWT token from an external OIDC-compliant Identity Provider (e.g., SAP IAS, Entra, Okta etc.). This JWT is passed to runtime, which validates it against the external IDP's OIDC configuration. EIC runtime uses the IDP's Well-Known URL (the OIDC discovery endpoint) to fetch the public keys and token metadata, then validates:
- Token signature — verified against the IDP's JWKS (JSON Web Key Set)
- Audience (aud claim) — must match what is configured in the policy
- Client ID — validated against the registered application
- Expiry and standard JWT claims
If all validations pass, the token is considered authentic and the request proceeds. The validated token can then be propagated downstream to the backend API (e.g., SuccessFactors) — enabling end-to-end token chaining.
When to use it:
- Your calling application uses a non-SAP IDP or SAP IAS as its identity authority
- You are integrating with third-party ecosystems (partner apps, customer portals, mobile apps) that are not BTP-resident
- You need to support federated identity scenarios — e.g., corporate Azure AD federated into SAP IAS
- Your organization's identity strategy mandates a centralized external IDP beyond BTP's XSUAA
- You are calling APIs on behalf of a human user whose identity lives in IAS (not in XSUAA)
Aspect | Internal (XSUAA) | External (OIDC) |
Token Issuer | SAP BTP XSUAA | Any OIDC-compliant IDP (IAS, Entra, Okta…) |
Trust Setup | Pre-established within BTP | Configured via Well-Known URL in policy |
Primary Use Case | BTP-native app-to-API calls | Cross-ecosystem, federated, or IAS-managed identities |
Token Type | XSUAA OAuth 2.0 Access Token | Standard OIDC JWT |
Policy Config Effort | Minimal | Explicit (Well-Known URL, Audience, Client ID) |
Token Propagation | Supported | Supported |
User Info Key (Audit) | Not applicable | Optional — JWT claim for audit identity; falls back to Client ID |
Create an API in SAP Integration Suite with External Auth
Now let's bring this to life with a concrete scenario.
Scenario Overview
I have a Application Status API of SuccessFactors(SFSF) managed via an API artifact on EIC runtime. The API is consumed by an application developer (or an application they have built) whose identity is managed by SAP Identity Authentication Service (IAS). The SFSF API itself is configured to accept OAuth 2.0 JWT Bearer tokens issued by IAS.
The flow looks like this:
Application Developer
│ 1. Obtains JWT from SAP IAS token endpoint
▼
SAP IAS (External IDP)
│ 2. JWT passed in Authorization header
▼
API Artifact URL on EIC
│ 3. Authentication Policy validates JWT
│ - Well-Known URL → fetch JWKS from IAS
│ - Validate: signature, audience, client ID
│ - Resolve caller identity
▼
Validation Passed
│ 4. Token propagated to SFSF API
▼
Backend API
│ 5. Backend validates JWT Bearer, returns response
▼
Response returned to caller
Prerequisites
Before we start the let’s ensure the following are in place:
- SAP Integration Suite is activated with both API Management and Cloud Integration capabilities enabled in your BTP subaccount
- Edge Integration Cell is provisioned.
- An API artifact has been created in your Integration Suite tenant targeting the EIC runtime, with the SFSF API as the backend target URL
- In SAP IAS, an application is registered representing your API client. Note down:
- The IAS tenant's Well-Known URL: https://<your-ias-tenant>.accounts.ondemand.com/.well-known/openid-configuration
- The Client ID of the registered IAS application
- The Audience configured for token issuance (often the client ID itself, or a dedicated resource URI)
- The SFSF OAuth configuration is set up to trust IAS-issued JWT Bearer tokens
Model the Authentication Policy in the API Artifact
- Navigate to Design → Integrations and APIs in your SAP Integration Suite tenant
- Open the Content Package containing your SFSF API artifact
- Click on the API artifact to open it in the editor
- Switch to the Policies tab
- You will see the Authentication Policy already present — this is the default, non-deletable policy attached to every API artifact on EIC
- Click on the Authentication Policy to open its configuration panel
Configure External Authentication
In the Authentication Policy configuration panel: Under Authentication Policy, check External OAuth (OIDC).
In the Well-Known URL field, enter your SAP IAS discovery endpoint:
https://<your-ias-tenant>.accounts.ondemand.com/.well-known/openid-configuration
This URL tells runtime where to fetch the IDP's public signing keys and token metadata. EIC calls this endpoint at runtime to validate incoming JWTs. In the Audience field, enter the audience value that IAS is configured to embed in the JWT's aud claim. This is typically the Client ID of the target application or a resource URI defined in IAS.
In the Client ID field, enter a dynamic expression which maps to the claim in your JWT token representing the Client ID of the IAS application that the calling application uses to obtain its JWT. For e.g. ${authn.oidc.jwt.azp}
In the User Info Key field (optional), enter a dynamic expression which maps JWT claim you want EIC to use for identifying the caller in audit logs — for example, email, sub, or user_name. For e.g. ${authn.oidc.jwt.email}.
There is a preference for UserInfo Key:
- If you provide a value (e.g., email), the runtime will look for that claim in the inbound JWT or in the IDP's UserInfo endpoint response, and use it as the caller identity in audit log entries.
- If you leave it empty, the runtime falls back to the Client ID as the audit identity.
- If you provide a value but the claim is not found in the JWT or UserInfo at runtime, the EIC again falls back to the Client ID — the policy does not fail. At most, audit log entries will reflect the fallback identifier rather than the preferred one.
If your organisation's audit and compliance requirements demand that API access logs reflect human-readable identifiers (like an email address or user principal name) rather than technical Client IDs, this is the field to configure. It gives you meaningful, traceable audit trails without any impact on the authentication flow itself.
Save and Deploy the API Artifact to EIC Runtime Profile
- In the artifact editor, click Deploy
- Select your Edge Integration Cell runtime as the deployment target
- Confirm the deployment
Navigate to Monitor → Integrations and APIs and switch the runtime filter to your EIC instance to verify the artifact status shows "Started"
Invoke the API — End-to-End Flow in Action
Now let's test the flow from the application developer's perspective.
Obtain a JWT from SAP IAS:
The application developer (or application) calls the IAS token endpoint using the JWT Bearer grant type. In this grant type, the application presents a signed JWT assertion to IAS, which in turn issues a new JWT scoped for the target audience (SFSF). IAS validates the assertion and returns an access token (JWT).
Call the API artifact URL on EIC:
What happens inside EIC runtime profile:
- The request hits the EIC ingress
- The Authentication Policy intercepts it
- EIC fetches the JWKS from the IAS Well-Known URL (cached after first call for performance)
- The JWT signature is verified using IAS's public key
- The aud claim is matched against the configured Audience
- The client_id (or azp claim) is matched against the configured Client ID
- The EIC runtime resolves the caller identity— using the configured User Info Key claim (e.g., email) from the JWT or IAS UserInfo endpoint; falls back to Client ID if the claim is absent
- Validation passes ✓
- The JWT is propagated as-is in the Authorization header to the SFSF API backend
- SFSF validates the JWT Bearer token against its own IAS trust configuration and returns the employee data
Response flows back through EIC to the original caller.
Step 6: What Happens on Validation Failure?
If the JWT is invalid — expired, wrong audience, or tampered signature — EIC returns:
HTTP 401 Unauthorized
{
"error": {
"code": "invalidToken",
"message": "Unable to authenticate user, invalid token"
}
}
The request never reaches the backend. This is the security guarantee of the non-deletable Authentication Policy — the backend is always protected.
Key Takeaways
- The Authentication Policy is the immovable security anchor of every EIC API artifact — and that is a feature, not a limitation.
- Tenant specific (XSUAA) authentication is your go-to for BTP-native, SAP-ecosystem calls. Zero configuration friction, pre-established trust.
- External (OIDC) authentication unlocks enterprise-wide API security — enabling any OIDC-compliant IDP to serve as the trust authority, with EIC validating tokens using standard OIDC discovery.
- Configuration is declarative and straightforward — four fields (Well-Known URL, Audience, Client ID, and the optional User Info Key) are all you need to onboard an external IDP into your API security model. The User Info Key is a lightweight but powerful addition — it shapes how callers appear in your audit logs without touching the authentication flow.
- Token propagation works seamlessly — validated external JWT tokens are forwarded to backend systems like SuccessFactors, enabling clean end-to-end identity chaining without re-authentication.
- The SFSF + SAP IAS scenario demonstrates a production-grade pattern: IAS as the central identity broker, JWT Bearer as the grant type, and EIC as the secure, policy-governed API gateway — all within your private, on-premise or hybrid landscape.
What's Next?
The introduction of External IDP authentication in EIC is a significant step toward making EIC a truly enterprise-grade, identity-agnostic API gateway — one that can sit in your private landscape while speaking the universal language of OIDC.
In upcoming post, I'll explore:
- Configuration and Authentication via Microsoft Entra ID → Integration Cell (New generation cloud based runtime for API Management) for enterprise SSO-driven API access
Stay tuned, and feel free to drop your questions and experiences in the comments below!
For official documentation, refer to the SAP Help Portal – Authentication Policy for API Artifacts
Bluesky
