3146449 - OAuth Authentication: Frequently Asked Questions (FAQ)

Please refer to the FAQ below for answers to commonly asked questions in relation to OAuth Authentication.

SAP SuccessFactors OAuth Authentication

IMPORTANT: The Second Half 2022 decommissioning date for Basic Authentication has been postponed until further notice. 
Please note SAP SuccessFactors still advise customers to switch to more secure methods of authentication. Any updates on this topic will be communicated on the regular channels


Q1) Is there a possibility to create multiple OAuth accounts or configurations (each having a different client ID and client secret) to be applied to a single client application?
A1) In SAP SuccessFactors OAuth, an application URL uniqueness validation is in place. What this means is that the same application URL registration cannot be used twice to generate the API key.
However, the application URL field does not validate for the correctness or existence of the URL, so a potential workaround for customers whose requirement is to use different OAuth Client Applications for different Integration scenarios would be to add a character at the end of the URL in the application URL field (e.g. sap.com, sap1.com, etc.)

Q2) Does SF support the registration of a single application to multiple OAuth accounts or configurations? Or is a client application restricted to a single OAuth configuration
A2) See Question 1. above
The same API key can be used for multiple integrations and can be bound to various API users

Q3) Is it possible to use the same token for two authentication requests?
A3) This is not possible. A separate token is needed per authentication request

Q4) If a user has deleted an application from the Manage OAuth2 Client Applications page in SuccessFactors, is there a way to find out who deleted it and when?
A5) This is currently not possible

Q5) How long is the OAuth bearer token valid for?
A5) The OAuth2 Bearer token is valid for ~24 hours

Q6) Where is the Blog for Partners to post questions in the Communities?
A6) https://partnercommunity.successfactors.com/t5/Delivery-Blog/Deprecation-of-HTTP-Basic-Authentication-Second-Half-2022/ba-p/99199

Q7) Where is the Blog for Customers to post questions in the Communities?
A7) https://community.successfactors.com/t5/API-and-Integration-Resources/2H-2020-announcement-Planned-Retirement-of-HTTP-Basic/ba-p/259021

Q8) Can OAuth2 be used for both SFSF OData and SFAPI (including CompoundEmployee API)?
A9) Yes, both are supported

Q9) If using SF API and OData API calls in CPI, how does the system handle the authentication when the SFAPI and OData APIs calls are made in a Local Integration Process and being invoked by a Looping Process Call (and not in the main integration process)?
A9) If using the SAP SFSF Adapter, if you have used SFSF SAP Cloud Integration in the looping process call it should be the same whether it's in the main process or the local one.

Q10) Will Basic Authentication also be deprecated in Salesdemo instances?
A10) There are currently no planned dates to end Basic Authentication

Q11) When will the function import operation be supported for the SAP SuccessFactors adapter?
A11) We do not have a timeline for this yet, we will share when available

Q12) Is there any way that the http connectors/adapter in SAP Integration Suite can be configured (similar to the SAP SuccessFactors' Connectors in CPI)?
A12) The http adapter supports OAuth2 with SuccessFactors. Please do not use "/oauth/idp" to generate the SAML assertion in https CPI connector, as it is sending a private key over the internet (not recommended)

Q13) How is the keypair/ key pair generated in SAP SuccessFactors?
A13) The Manage OAuth2 Client Applications page in SuccessFactors helps you generate and download a key pair, which contains a private key (API key) and the corresponding certificate.
Both will be tied to a single URL (the "Application URL" which is a mandatory and unique field, meaning, you must maintain this field and ensure it is not used in any other registration, cf. Q26 below)
When a new client is registered, you will see a generate certificate button. This certificate is self signed.
Should you wish to replace the X.509 Certificate, you will need to delete and re-create a new registration (as simply changing the X.509 Certificate field will not generate a new API/private key)

Q14) Does this change apply to custom integrations (e.g. Custom Integration from Integration Suite to ECP)
A14) Yes. Again, there is no ETA on the full decommissioning of Basic Authentication

Q15) Will the Delta Extract Report based the SFSF Excel AddIn continue to be supported?
A16) Yes. Please review the announcement in our What's New Viewer (See Also section) and the Using the Employee Delta Export Add-In for MS Guide below.

Q16) For standard integrations in Boomi or CPI will the customer need to deploy these changes, or will they be deployed automatically?
A16) Until standard packages has been updated by SAP SuccessFactors' development teams, no action is required by customers.
Once the SAP SFSF connector is available, SAP Dev team would start changing standard iFlows in Boomi/CPI, no action is required from customers/partners 
Recommendation: keep an eye on the above-mentioned blogs

Q17) Does the Talent Add-on support OAuth authentication (PA-SFI-TM "SAP HCM on-premise Talent Hybrid Integration")?
A17) Currently, our Engineering teams are working to deliver a more secure means of authentication for this replication package. No ETA is known at this time. 
In the meantime, you can refer to our WNV announcement on the Deprecation of HTTP Basic Authentication for APIs: 
Notwithstanding the anticipated End of Maintenance of HTTP Basic Authentication for APIs (“Basic Authentication”) as of June 2, 2023, maintenance of Basic Authentication will continue solely where it's provided and used as part of the integration add-on 3.0 for SAP ERP HCM and SAP SuccessFactors HXM Suite. The June 2, 2023 End of Maintenance will apply to all other direct and indirect use of Basic Authentication.

Q18) Currently in our CPI and/or Boomi environments, we use a different userid for each integration.  This allows us to easily determine which integration did the data update in SFEC or SFLMS or SFRecruiting, ect...  With the deprecation of the basic auth userid/pwd and the switch to the new OAuth, this does not seem possible any longer, it appears that we will have only one userid for all CPI jobs and one userid for all Boomi jobs, is this true?
A18) In the 2H 2021 release our team covered this requirement by creating this feature: Restrict API Access Through OAuth 2.0 to Specific Users (sap.com)
Meaning, you can have one OAuth key for each integration tied with one userID only for example, i.e. from SFSF and after the 2H 2021 release, we can tie one userID with one created OAuth API
From CPI however, you can create as many "Credentials Name" to be used in the "OAuth2 SAML Bearer Assertion" as needed. You can also create as many OAuth API keys in SF side tied to these credentials as needed, cf. OAuth2 SAML Bearer Assertion in SAP Cloud Integration connecting with SAP SuccessFactors
(if you repeat the steps of this blog above twice, you will have 2 OAuth API keys inside SF and 2 CPI "Credential Name" with 2 different userIDs, one for each process if needed)

Q19) Is there a way customers can determine the authentication method(s) used in their environment?
A19)  Yes, please check KBA 3138533 - How to use SuccessFactors API Audit Log to determine authentication methods used in your environment - SAP ONE Support Launchpad for this

Q20) Is there a way to bind many users in one application?
A20) Previously, you could bind a client application to a single technical user to allow only this user to request OAuth tokens for API access. This feature has been enhanced to allow optional binding of multiple users, including both technical users and business users, cf. KBA 3046598 - SuccessFactors SFAPI/ODATA API OAUTH: API User ID binding with API Key (client_id)

Q21) Is there an up-to-date list of SAP SuccessFactors Integrations supporting a secure authentication mechanism?
A21) Yes, please bookmark and regularly review KBA 3156202 - SAP SuccessFactors Integrations supporting a secure authentication mechanism

Q22) I'm getting a P3244 error - what can I do?
A22) Please raise a case to Support, component LOD-SF-INT-ODATA or LOD-SF-INT-CE

Q23) What happens if I have a user set up with Basic Authentication for OData API and enable SSO (this could be a scenario where CPI is calling SAP SuccessFactors with basic authentication, and SSO is enabled after the fact)?
A23) Assuming this is a technical integration for system-to-system communication based on API users, this will not be affected by enabling SSO. The SSO configuration will only affect the UI for end users and not the integration flow of system to system communication using API users.
As a general best practice, we would advise those integrations should get migrated to oAuth2 with SAML in CPI. This is a simple task (estimated time for completion 10 minutes). For full instructions, please review the "SAP SuccessFactors Integration: Migrating SAP SuccessFactors API calls from Basic Authentication to oAuth2.0" document available here: Implementation Design Principles for SAP SuccessFactors Solutions - Welcome to the SAP SuccessFactors Community! (page 21 and onwards)

Q24) What are the implications of having IP Restrictions in place, when moving to OAuth Authentication? In other words, should I remove the relevant user (API user) from Password & Login Policy Settings -> Set API login exceptions and/or IP Restriction Management?
A24) Please keep an eye on KBA 3089432 for updates on this topic

Q25) I would like to ask you if when using the OAuth2 authentication instead of basic authentication, is it still possible to restrict the IP's which would be able to access the instance? If yes, what would be the procedure?
A25) No matter if you use oAuth or Basic there is always a user accessing the system and IP filtering should work the same way. This is independent from the user you set in the user binding since user binding is just an optional filter and not wanted in some cases (e.g. UI access with named users). The client which calls the API has to define the user he is using to do the API call and he does this when generating the SAML assertion to get the oAuth token. This SAML assertion contains the user. With this SAML assertion you get an oAuth token for this same user and this user is present again in this oAuth token. When doing the API call with the oAuth token the system checks the IP address for this user.  The binding in the oAuth client is just an additional optional filter to disallow certain users to use an oAuth2 client registrations (e.g. for system to system communication).

Q26) Why is the "Application URL" a required field? Can we make it non-required? 
A26) This field was set as mandatory due to internal policies at the time it was originally set up. Should you have a strong business requirement to make it non-mandatory, please submit an enhancement request to SAP SuccessFactors via the influence channel: 2090228 - How to Submit Ideas for SAP SuccessFactors Products
See also Q1) above

Q27) What do I have to do to enable oAuth2 in IAS/IPS?
A27) In the past, the communication between IPS and SAP SuccessFactors was using the OData APIs and Basic Authentication. Now customers can use new SCIM APIs (not OData) with a certificate-based approach. This means customers can migrate from an unsecure Basic Authentication flow on OData to a secure certificate (not oAuth) based flow for the SCIM rest APIs (not OData anymore). The following documentation may be of assistance: 
Setting Up the Identity Provisioning Source and Target Systems | SAP Help Portal 
Upgrade from ODATA IPS Connector to SCIM IPS Connector with SAP SuccessFactors HXM Suite | SAP Help Portal 

Q28) Will generating the X.509 certificate or creating a new oAuth Client Registration in SuccessFactors have an impact on SSO, e.g. the IAS configuration for Career Side Builder?
A28) No, it will not have an impact (one important exception would be if you do user binding for an existing oAuth2 client registration. The best practice here would be to create a new oAuth2 client registration) 

Q29) Will enabling SSO have any impact on integrations running on SAP Integration Suite calling SuccessFactors with Basic Authentication?
A29) No

Q30) How to use oAuth2 when calling SuccessFactors APIs in the Integration Center?
A30) One alternative is to use the "SuccessFactors" Integration Type, instead of "REST". If your scenario is not supported by the "SuccessFactors" Integration Type, you could either use an existing integration from the SAP Integration Suite catalog or file an enhancement request via the Influence channel: 2090228 - How to Submit Ideas for SAP SuccessFactors Products

Q31) My 3rd party software (Okta, Microsoft Azure Provisioning Service, BizTalk, etc.) is not supporting oAuth2, only Basic: what should I do?
A31) To our knowledge, 3rd party vendors are also working on making oAuth available from their side. Please reach out to your vendor directly to get more information about timelines.

Q32) Why is binding the (Technical) User in the oAuth client registration not working?
A32) This will work for new ones, not for existing ones as there is a delay when the binding is added later. After 24h the binding will be active due to caching of the token in SAP Integration Suite. The alternative is to reconfigure the oAuth setup on both sides.

Q33) I want to call the SuccessFactors APIs from my code - is there an example on how to do this?
A33) Yes, please see the example coding in this blog: Best Practice for SAML Offline generator and local keystore with SAP SuccessFactors | SAP Blogs

Q34) When I created a Key Pair in CPI/BTP, I forgot to change the "Valid Until" field. Thus, it will expire in 2 years. I already completed all my integrations to use OAuth2. Can I go back and extend the expiration of the key pair, or should I create a new Key Pair, Register a new client application in SFSF, then update OAuth2 Credentials with the new Client Key and Key Pair alias?
A34) There currently are not known ways to extend the expiration or validity of the key pair. This topic is being reviewed internally and if any alternatives become available, they will be published via this KBA.

Q35) Under "Manage OAuth2 Client Applications", what is the "Disable" option used for?
A35) If the client is “disabled”, when you try to get Access Token by SAML Assertion, you will get error message similar to the following:
"API key xxx is disabled in company XXX. For more information, see https://help.sap.com/docs/SAP_SUCCESSFACTORS_PLATFORM/d599f15995d348a1b45ba5603e2aba9b/6b3c741483de47b290d075d798163bc1.html "

Q36) What is the encryption type used in the OAuth2 Client Application, is it Symmetric or Asymmetric?
A36) We use an asymmetric key pair while generating certificates, please refer to Authentication Using OAuth 2.0 | SAP Help Portal 

Q37) When does the SAML assertion expire? Can I set the expiry time myself?
A37) The default SAML Assertion expiry time is generally set as 5-10 minutes, SAP SuccessFactors has not set a certain limitation for its value. This means you can choose to set a long expiry time (note: the limit is maximum of integer value: 2147483647 minutes), however, we still recommend the SAML Assertion does not have a long expiry period.

Q38) June 2nd 2023 will be the end of maintenance for Basic Authentication. What action do we need to take from our side?
A38) The end of maintenance means that the development teams will no longer provide patches or fixes for bugs found in Basic Authentication, so it's just an announcement for that. The actions for your side will be the same as before: evaluate the adoption of an alternative method as soon as possible.

Q39) Will basic authentication stop working on June 2nd 2023 (End of Maintenance date)? 
A39) No, it will still work. The moment for it to stop working is the "Deleted" date mentioned in What's New Viewer which is currently November 20, 2026, and please note that this is a tentative date, meaning that it still may be pushed out even further.

 cf. OAuth 2.0 Errors | SAP Help Portal and
Generating a SAML Assertion | SAP Help Portal 

You can avail of parameters such as expireInMinutes=10 to set the expiry time, cf. the SAMLAssertion.properties file as explained in KBA 3031657 (SAML assertion via offline tool) 

Q40) How can I check the validity of the X.509 certificate for OAuth authentication?
A40) Please review KBA 3360655 - Checking the Validity of X.509 certificate for OAuth authentication 

Q41) How can I check the Validity of the SAML Assertion?
A41) Please follow these steps:

A. Generate the SAML assertion by a method of your choice.

B. Copy it in Notepad++.

C. Select All, then click on Plugins > MIME Tools > Base64 Decode. 


D. Look for the NotBefore and NotOnOrAfter fields, where NotBefore is the start date/time and NotOnOrAfter is the end date:

SAP SuccessFactors HXM Suite OData API: Developer Guide (V2)

SAP SuccessFactors HXM Suite SFAPI: Developer Guide

Community Blog: Using x.509-based authentication with SAP SFSF IC, ISC and CPI

Community Blog: How to setup secure http inbound connection with client certificates

Community blog: how to use-oauth2-saml-bearer-assertion in SAP CPI connecting with SAP SFSF sfapi-soap

Community blog: Deprecation of HTTP Basic Authentication

KBA 3138533 - How to use SuccessFactors API Audit Log to determine authentication methods used in your environment

KBA 3046598 - SuccessFactors SFAPI/ODATA API OAUTH: API User ID binding with API Key (client_id)

KBA 3156202 - SAP SuccessFactors Integrations supporting a secure authentication mechanism

ECT-164674 What's New Viewer

Using the Employee Delta Export Add-In for Microsoft Excel Guide

3089432 - 2H 2021: API login exception for external oauth when IP restriction management is enabled

3031657 - SAP SuccessFactors SAML Assertion format demonstration using SAP Provided offline tool - SAP ONE Support Launchpad

3167173 - Setting Up Point-to-Point Integration with Client-certificate based Authentication - SAP ONE Support Launchpad

OAuth, FAQ, token,  SFSF, SuccessFactors, IC, ISC, CPI, x.509, Application URL already exists, P3244, internal KBA 3201345, 3201345, ODATA, CompoundEmployee, CE, Basic, SSO, OAuth, impact, Password & Login Policy Settings, Set API login exceptions, IP Restriction Management , KBA , LOD-SF-INT , Integrations , LOD-SF-INT-API , API & Adhoc API Framework , LOD-SF-INT-CE , Compound Employee API , LOD-SF-INT-ODATA-OAU , ODATA OAUTH Authentication , How To