Configuring OAuth Credentials for SAP SuccessFactors – A Step by Step Guide

Hello All,

Greetings for the Day!!

Basic Authentication is being phased out for SuccessFactors. If your standard or custom SAP Cloud Integration (CPI) interfaces still rely on Basic Authentication, now is the time to transition to OAuth2.0.

Even though the SAP documentation regarding OAuth2 SAML is comprehensive enough, this article will guide you practically through the setup. It covers the end-to-end configuration across both CPI and SuccessFactors, including generation of certificates and registering your credentials.

This article outlines the exact methodology I utilize during the project implementations. It emphasizes the proper sequence of operations within both systems to ensure you can activate OAuth seamlessly, eliminating the need for trial and error. The steps are straightforward, reproducible, and perfect for distributing among your project members.

Prerequisites

• Access to your SAP CPI tenant with permissions for Monitor → Keystore and Security Material.
• Administrator access in SuccessFactors to manage OAuth2 Client Applications
• SuccessFactors Company ID along with API/Data Center URL
• A dedicated technical/API user in SuccessFactors

Architecture Overview

From a high level perspective, here is how the OAuth flow functions:

1. CPI creates a key pair (the certificate);
2. The certificate is then registered in the SuccessFactors by setting up an OAuth2 client mapped to a technical user;
3. SuccessFactors generates an API Key specific to this client application.
4. In CPI, an OAuth2 SAML Bearer Assertion credential is configured using the client parameters;
5. Lastly, the iFlow leverages this credential to obtain access tokens, enabling secure communication with SuccessFactors APIs.

Part A – CPI: Create the Key Pair (Steps 1 – 4)

Step 1: Log in to your SAP CPI environment and navigate to Monitor → Integrations and APIs → Key store.

Step 2: Click Create → Key Pair.

Step 3: Populate the Key Pair parameters:

• Alias: Choose a recognizable name for your setup (e.g., successfactorsoAuth).
• Common Name (CN): Enter the exact SuccessFactors technical user ID.
• Country/Region: Input your location code, such as IN (India).
• Validity: set a sufficient validity period (don’t keep default short dates)

Step 4: Hit Create, then choose Download Certificate. You will need this certificate for the SuccessFactors configuration.

Tip: Keep a secure record of both the Alias and the CN, as you will need to reference them later during the CPI OAuth setup.

Part B – Success Factors: Register the OAuth Client (Steps 5 – 9)

Step 5: Sign into Success Factors and use the search tool to find Manage OAuth2 Client Applications.

Step 6: Click Register Client Application.

Step 7: Enter application details:

• Application Name: You can give any meaningful name for your architechture.
• Application URL: your middleware base URL (up to *.ondemand.com)
• Check the box for Bind to Users
• In User IDs section, provide the SF technical user (this must exactly match the CN you used in CPI)

Now, paste the CPI certificate:

1. Open the downloaded certificate file using a basic text editor (like Notepad).
2. Copy only the text situated between
   —–BEGIN CERTIFICATE—– and —–END CERTIFICATE—–
3. Paste this string into X.509 Certificate field.

Click Register.

Step 8: Select View next to the newly created application to see its details.

Step 9: Copy the generated API Key and store it safely. This will be required for the CPI configuration.

Common pitfall: If the certificate block includes the BEGIN/END CERTIFICATE lines or extra white space, registration can fail. Only paste the primary block of text.

Part C – CPI: Create OAuth2 SAML Bearer Assertion Credential (Steps 10 – 12)

Step 10: Return to CPI and navigate to Monitor → Integrations and APIs → Security Material.

Step 11: Go to Create → OAuth2 SAML Bearer Assertion.

Step 12: Create a new entry with the following details:

• Name: An identifiable title (e.g., SF_OAuth_SAML_Prod)
• Audience: www.successfactors.com
• Token Service URL: your API host + /oauth/token
  (For instance: https://api4.successfactors.com/oauth/token – make sure use your specific Data Center host).
• Target System Type: Select SuccessFactors.
• Company ID: your SF Company ID.
• User ID: Select Key Pair Common Name (CN).
• Key Pair Alias: the alias you created (e.g., successfactorsoAuth).
• Client Key: The API key you retrieved from SuccessFactors.
• Deploy.

Notes: 

• The User ID must match the user you bound in SuccessFactors.
• The Key Pair Alias must be exactly the CPI keystore alias.
• The Token Service URL must be your DC’s API endpoint with /oauth/token.

Part D – Test with a Simple iFlow (Steps 13 – 15)

Step 13: Build a basic test iFlow that calls a simple SuccessFactors API (e.g., a GET on FOCompany or User with minimal fields).

Step 14: In the receiver adaptor settings, apply the following:
Authentication: Set to OAuth2 SAML Bearer Assertion.
Select the credential you created above.

Step 15: Turn HTTP Session Reuse = On Exchange (important).
This minimizes token overhead and prevents intermittent auth failures.

Deploy and execute the test. You should receive a valid response from Success Factors.

Troubleshooting (what usually goes wrong)

401/403 errors:

• Review your Audience and Token URL (spelling mistakes or incorrect DC hosts happen frequently).
• Verify that HTTP Session Reuse is turned on in the adapter settings.
• Double-check the Company ID and User ID in the CPI credential.

Invalid certificate / client errors:

• Re‑paste only the certificate body exclusively (without BEGIN/END lines).
• Check the CPI Keystore to make sure the Key Pair hasn’t passed its expiration date.

Wrong user context:

• The User ID applied in “Bind to Users” must be the same user used as CN in the CPI Key Pair and User ID in CPI OAuth credential.

Token URL not reachable:

• Confirm if the API host is correct for your data center.
• Ensure there are no proxies/firewalls that might be restricting outgoing connections from CPI to SF.

Best Practices (My Project Recommendations)

1. Make use of Technical User in SF for API interactions rather than relying on personal or administrator accounts;
2. Monitor certificate validity – set up calendar reminders 30–45 days before expiry.
3. Store API Keys securely; refrain from sharing them in casual chats or open documents.
4. Enable HTTP Session Reuse for the SuccessFactors adapters.
5. Start with a minimal test iFlow before applying changes to your live business integrations.
6. Review OAuth clients in SF quarterly; remove unused clients and rotate certs periodically.
7. Use CPI Monitoring & Traces for root cause; they’re incredibly valuable for OAuth issues.

Conclusion

If you have followed the above mentioned instructions generating the key pair in CPI, OAuth client in SuccessFactors, credential in CPI, and a small test iFlow you’re set for a clean migration from Basic Auth to OAuth2 SAML Bearer Assertion.

The vast majority of errors I encounter are configuration typos or missed details (wrong token URL, incorrect User ID/CN mapping, certificate pasted incorrectly, or HTTP Session Reuse left off). Once those are correct, the flow is very stable.

Implementing this architecture ensures your integrations remain aligned with SAP’s roadmap, preventing you from unexpected disruptions when Basic Authentication is officially retired.

Best Regards,
Rasesh Thakkar.

  Read More Technology Blog Posts by Members articles 

#abap