Background
If your SailPoint Identity Security Cloud (ISC) implementation uses a Web Services connector to integrate with SAP SuccessFactors, there is a reasonable chance you have been relying on the SuccessFactors-native OAuth IDP endpoint (/oauth/idp) to generate SAML assertions for API authentication. SAP deprecated this endpoint ( SAP Help Portal | SAP Online Help ) because it required passing a private key directly in an API call, which SAP deemed insecure. The endpoint has now been removed for all tenants.
This post documents how we migrated our ISC Web Services connector-based SuccessFactors integration off the SF OAuth/IDP flow and onto SAP Cloud Identity Services (CIS) using OpenID Connect (OIDC) through SAP Identity Authentication Service (IAS). It covers the motivation, the architectural change, the configuration steps, and the key lessons from the migration.
Why We Used the Web Services Connector
Our implementation used the Web Services connector in addition to the out-of-the-box SuccessFactors connector. The primary reasons were the need to call non-standard OData v2 endpoints and apply custom transformations at the connector layer. The Web Services connector gives you full control over authentication, operations, and response mappings, which the native connector does not expose.
The original authentication flow worked as follows:
-
ISC called the SF
/oauth/idpendpoint, passing a private key to generate a signed SAML assertion using a connector rule. -
That assertion was exchanged at the SF
/oauth/tokenendpoint for a Bearer access token. -
The Bearer token was passed in the
Authorizationheader of all subsequent OData API calls.
This worked until SAP set a firm removal date. Once /oauth/idp was removed, there was no way to generate a SAML assertion through that path and the integration would fail entirely.
The New Authentication Architecture
SAP’s recommended approach is to use SAP Cloud Identity Services, specifically IAS, as the trusted identity provider for API-based authentication. As of the 2H 2024 SuccessFactors release, SAP introduced OIDC support for API calls. This allows IAS to act as the central identity provider not just for user SSO but for system-to-system API authentication as well.
The new flow using OIDC through IAS works as follows:
ISC Web Services Connector
|
| Step 1: Request an access token from IAS
| POST https://<ias-tenant>/oauth2/token
| grant_type=client_credentials
| resource=<dependency name in IAS>
| client_id=<oidc-client-id>
| client_secret=<oidc-client-secret>
|
v
SAP IAS returns a SuccessFactors-trusted access token (JWT)
|
| Step 2: Test the connection the SuccessFactors OData API
| GET https://<sf-api-host>/odata/v2/PerPerson?$filter=personIdExternal eq '0'
| Authorization: Bearer <access_token_from_step_1>
| Body:Form Data: company_id=<SF compay ID>
v
SuccessFactors OData v2 API responds
Rather than relying on SAML assertions and private key operations, authentication is now handled entirely through standard OIDC token flows. IAS acts as the trusted broker between ISC and SuccessFactors. No private key material is transmitted in any API call.
Prerequisites
Before starting, confirm the following are in place:
-
Your SuccessFactors tenant is already integrated with SAP IAS. OIDC-based API authentication will not work without this.
-
The API technical user (service account) used by ISC exists in both SuccessFactors and IAS with matching usernames.
-
You have administrative access to the SAP IAS admin console.
-
You have administrative access to the ISC tenant and the Web Services connector source configuration.
Configuration Steps
Step 1: Register an OIDC Application in SAP IAS
In the IAS admin console, create an application to represent the SailPoint ISC integration.
Navigate to Applications and Resources > Applications and create a new application. Set the Protocol Type to OpenID Connect. Under OpenID Connect Configuration, enable the Client Credentials grant type. If your configuration requires a two-step token exchange, also enable Token Exchange (RFC 8693).
Generate a Client ID and Client Secret. Store these securely as they will be used in the ISC connector configuration.
Under Subject Name Identifier, configure the attribute that maps to the SuccessFactors technical username. This ensures the token issued by IAS carries the correct user identity claim when it reaches the SuccessFactors OData layer.
Step 2: Configure the IAS Dependency for SuccessFactors
In IAS, open the application representing your SuccessFactors tenant and navigate to Dependencies. Add the OIDC application created in Step 1 as a dependency. This is what enables the token exchange. When ISC presents its IAS access token and specifies the SuccessFactors dependency as the resource, IAS will issue a token that SuccessFactors trusts.
Note the dependency name exactly as it appears. This string is used in the resource parameter of the token exchange request and any mismatch will cause the exchange to fail.
Step 3: Confirm Certificate Trust in SuccessFactors
SuccessFactors must trust tokens issued by IAS. Retrieve the IAS signing certificate from the IAS admin console under Tenant Settings > Single Sign-On > SAML 2.0 Configuration > Signing Certificates. Confirm that IAS is registered as an asserting party in SuccessFactors SSO settings.
The OAuth2 client application registration in SuccessFactors is still required. The OData authentication layer in SuccessFactors uses this registration to validate the incoming token, even when the token is issued by IAS rather than generated from a SAML assertion.
Step 4: Update the ISC Web Services Connector to Use Custom Authentication
This is where the migration is realised in SailPoint.
Why Custom Authentication rather than OAuth 2.0?
The Web Services connector’s built-in OAuth 2.0 grant types do not accommodate a two-step token exchange where a resource parameter scoped to a specific IAS dependency is required. Custom Authentication gives you full control over each HTTP call in the token acquisition sequence, including the ability to pass the output of Step 1 as the assertion in Step 2.
In the connector source configuration, set Authentication Type to Custom Authentication.
Create a Custom Authentication operation for Step 1 with the following structure:
-
Operation Type: Custom Authentication
-
HTTP Method: POST
-
URL:
https://<your-ias-tenant>/oauth2/token -
Content-Type:
application/x-www-form-urlencoded -
Request Body:
grant_type=client_credentials
&client_id=<ias-client-id>
&client_secret=<ias-client-secret>
&resource=urn%3Asap%3Aidentity%3Aapplication%3Aprovider%3Aname%3A<dependency-name>
Response Mapping
Map the access_token field from the Step 1 token response to a connector attribute. Use a unique name such as customaccesstoken rather than the reserved name accesstoken. This token is then referenced in all subsequent API call headers as:
Authorization: Bearer $customaccesstoken$
Securing Sensitive Attributes
Do not enter client_id, client_secret, or token values directly in the connector UI for production configurations. Add these as encrypted attributes using the SailPoint partial update REST API, appending the _CA suffix to any sensitive key names. This ensures credentials are stored encrypted within the ISC source configuration and are not exposed in plain text.
Step 5: Validate with a Test Connection
Once the custom authentication operations are configured, use Test Connection in ISC. The connector will execute the authentication operations first, retrieve the final access token, and then attempt a call to the SuccessFactors OData API. A 200 response confirms the full OIDC flow is working end to end.
A useful baseline validation call is a $top=1 query on the User entity:
GET https://<sf-api-host>/odata/v2/User?$top=1&$format=json&company_id=<SF company ID>
Authorization: Bearer <access_token>
Key Lessons
The IAS dependency configuration is critical. Without correctly naming and registering the SuccessFactors application as a dependency of your OIDC application in IAS, the token exchange will fail. Confirm the dependency name matches exactly what you use in the resource parameter of Step 2.
The technical user must exist in both systems. IAS and SuccessFactors must both have a user with a matching identifier. If the API technical user exists only in SuccessFactors and not in IAS, the Subject Name Identifier mapping will fail and the resulting token will not carry the correct identity claim.
Remove old private key material after migration. Once the migration is confirmed working, remove the private key that was previously used for SAML assertion generation. There is no reason to retain it and doing so leaves unnecessary credentials in the environment.
Validate with a real OData call, not just a token fetch. A successful token response from IAS does not guarantee that SuccessFactors will accept it. Always validate by executing an actual OData call before declaring the migration complete.
Authentication Comparison
| Aspect | SF OAuth/IDP (deprecated) | SAP CIS OIDC (current) |
|---|---|---|
| Assertion generation | SF /oauth/idp endpoint |
IAS issues JWT token directly |
| Private key handling | Key passed in API call | No private key in connector |
| Standards compliance | Proprietary SF mechanism | Standard OIDC and OAuth 2.0 RFC 8693 |
| IDP dependency | None | SAP IAS required |
| Token type | OAuth Bearer derived from SAML | JWT Bearer issued by IAS, trusted by SF |
| SailPoint auth type | OAuth 2.0 or Custom | Custom Authentication |
| Viability | Deprecated and removed | SAP strategic direction |
Summary
Migrating from the deprecated SF OAuth/IDP mechanism to SAP Cloud Identity Services with OIDC is not just a compliance exercise. The new approach eliminates private key transmission in API calls, centralises identity trust in IAS, and aligns with SAP’s strategic direction for SuccessFactors API authentication.
For ISC implementations using the Web Services connector, the Custom Authentication configuration provides the flexibility needed to accommodate the multi-step OIDC token flow. With the connector correctly configured, aggregation, delta aggregation, and provisioning operations continue to function without change. The only difference is how the Bearer token is obtained before each session.
If your environment is still relying on /oauth/idp-based authentication in any form, the time to migrate is now. The endpoint is gone and any integration still depending on it will fail.