SuccessFactors Basic Auth: What Changes in 2026 and 2027

Easily migrate from SAP SuccessFactor’s Basic Auth to SAML.

If you have seen three different dates for the end of SuccessFactors Basic Auth, you are not alone. SAP moved the API deletion date on June 12, 2026 – from November 20, 2026 to November 12, 2027 – and plenty of connector documentation has not caught up. Oracle Integration’s guide, several CData pages, and some SAP KBA articles still show the old November 2026 date.

Here is the current schedule from SAP’s own deprecation pages and the What’s New Viewer:

Date	What SAP removes	Who it hits
November 13, 2026	UI Basic Auth and direct third-party corporate IdP integration	Users logging in with passwords; SSO wired directly against SuccessFactors
November 20, 2026	Basic Auth for Document Management with OpenText	OpenText document integration only
May 14, 2027	The `/oauth/idp` endpoint	Setups that generate SAML assertions by sending a private key to SuccessFactors
1H 2027 release	API Basic Auth off by default (opt-in only for migration)	Every script, report, and connector still sending a username and password
November 12, 2027	API Basic Auth deleted, including EC integrations and point-to-point EC Payroll	Anything left

The practical deadline for most integration teams is the 1H 2027 release, not November 2027. Once that release lands – SAP typically deploys to production four to five weeks after preview – Basic Auth stops working unless you explicitly opt in for a temporary migration window. Treat November 2027 as the hard stop, not the planning date.

Sources: SAP KBA 3796078, SAP KBA 3239495, SAP What’s New Viewer.

What replaces it

SAP documents three replacement methods:

OAuth 2.0 with a SAML bearer assertion

This is the most common path for machine-to-machine integrations. Instead of a password, you send SuccessFactors a short XML document – a SAML assertion – that says who you are, which OAuth client you represent, and that the request is valid for the next ten minutes. You sign the assertion with a private key. SuccessFactors verifies the signature against the public certificate you registered when you set up the OAuth client, and returns an access token valid for about 24 hours.

The token exchange happens at the /oauth/token endpoint:

POST /oauth/token HTTP/1.1
Host: api4.successfactors.com
Content-Type: application/x-www-form-urlencoded

client_id=<API_KEY>&company_id=<COMPANY_ID>&grant_type=urn:ietf:params:oauth:grant-type:saml2-bearer&assertion=<BASE64_SIGNED_SAML>

The assertion itself must include:

An Issuer of www.successfactors.com
A NameID matching the technical API user
An api_key attribute matching the registered OAuth client
A Recipient pointing at the /oauth/token endpoint
An enveloped XML signature using RSA-SHA256 (SHA-1 is no longer accepted)
A validity window – typically five minutes in the past to ten minutes in the future

Modern connectors from SAP Integration Suite, MuleSoft (v5.0+), Boomi, and Okta handle this internally. The challenge is everything else.

OpenID Connect through SAP Cloud Identity Services

If your SuccessFactors tenant is integrated with SAP Identity Authentication Service (IAS), you can use OIDC instead. This is SAP’s stated target architecture – eventually OIDC will be the single authentication method. The trade-off is that it requires IAS setup and configuration that not every customer has in place today.

X.509 client certificates (mTLS)

Certificate-based authentication at the transport layer. Less common for integration scenarios but supported.

Why one migration is easy and fifty are not

If you have a single integration platform with a current SuccessFactors connector, the migration is a configuration change: switch the connection type from Basic Auth to OAuth SAML bearer, point the connector at your certificate and API key, and test. The connector handles assertion generation, signing, and token refresh.

The problem is the long tail.

Few SuccessFactors tenants have just one integration on Basic Auth. A typical tenant has dozens: a payroll export, an LMS sync, workforce reports in Power BI or Excel, a Python script someone wrote in 2019, an n8n or Power Automate flow, and a handful of scheduled jobs that call the OData API with a stored username and password.

For a Power BI report pulling OData, a shell script running curl, or an n8n HTTP Request node, this is a lot of pain. Power BI’s OData connector cannot sign SAML assertions. Neither can Excel’s data connection, most low-code flow tools, or a ten-line Python script that currently sends Authorization: Basic and calls it done.

Each caller that cannot sign a SAML assertion needs either a commercial connector that can, a custom middleware layer, or a rebuild. Multiply that by the number of callers across a tenant and you have the migration project nobody budgeted for.

The `/oauth/idp` complication

Some integrations solved the SAML signing problem by sending the private key to SuccessFactors’ own /oauth/idp endpoint and letting SuccessFactors generate the assertion server-side. SAP deprecated this endpoint because transmitting a private key over an API call is inherently unsafe – the whole point of asymmetric cryptography is that the private key never leaves the holder.

The /oauth/idp endpoint is deleted on May 14, 2027. If any of your integrations use it, they need to move to client-side assertion generation before that date, separate from the Basic Auth migration. SAP’s recommended alternatives are a trusted IdP (such as Microsoft Entra ID), SAP’s own offline SAML generator tool (KBA 3031657), or SAP Integration Suite.

Drop in an Auth Proxy now, and migrate on your terms

You do not have to wait for the deadline to act, and you do not have to tackle the SAML bearer migration for every caller at once. The better move is to quickly and easily put an auth proxy between your callers and SuccessFactors today – while Basic Auth still works – and get immediate value from the things Basic Auth alone never gave you: observability across every integration, scoped access per caller, and a single audit log of who reads what.

SAP’s own KBA 3796078 notes that tokens can come from “a trusted identity provider or middleware.” an auth proxy is that middleware. But the proxy does not require you to change the upstream auth method on day one. Start with your existing Basic Auth credential on the target side. Every caller still works. The difference is that now every call flows through a layer you control.

When you are ready – on your schedule, not SAP’s – you swap the target credential from Basic Auth to the OAuth SAML bearer flow. One change, in one place. No caller touches their code, their config, or their connection string. If SAP moves the date again, adds another auth method, or you decide to switch to OIDC later, the same applies: update the target credential, and every caller keeps working.

What changes per caller: the base URL and the Authorization header. What does not change: the query, the OData path, the request body, the response parsing, or any business logic.

Before (direct to SuccessFactors):

GET /odata/v2/User?$format=json HTTP/1.1
Host: api4.successfactors.com
Authorization: Basic c3ZjX3JlcG9ydGluZzpzM2NyZXQ=

After (through RequestRocket):

GET /odata/v2/User?$format=json HTTP/1.1
Host: <proxy-endpoint>
Authorization: Basic cG93ZXJiaS1yZXBvcnRzOnJhbmRvbS1rZXk=

The proxy credential (powerbi-reports:random-key) is not the SuccessFactors password. It is a separate secret that the proxy checks. The SuccessFactors credential – whether it is still Basic Auth today or OAuth SAML bearer tomorrow – stays on the target side, invisible to every caller.

What you gain the day you connect

The auth migration is the reason you are reading this post. But the value of an auth proxy starts before you touch the upstream auth method – from the moment you point your first caller at RequestRocket.

Observability across every caller

Today, SuccessFactors API calls from twenty different systems produce twenty separate sets of logs – if they produce logs at all. Through RequestRocket, every request from every caller is recorded in one place with the telemetry API: which caller, when, what OData path, what status code, how long the upstream took. When audit asks “who reads compensation data and how often,” the answer is a single API call, not a forensic exercise across twenty systems.

Scoped access per caller

Basic Auth gives every caller whatever the API user can do. With RequestRocket, each caller gets its own proxy credential paired with rules that limit it to specific HTTP methods, OData entity paths, or request patterns. The payroll export gets write access to payroll entities; the Power BI report gets read-only access to workforce data. A credential can be revoked without affecting any other caller.

One credential to rotate

When you do move to OAuth SAML bearer, the private key and certificate live in one encrypted record – the target credential – instead of being copied into every calling system. When the certificate needs rotating, you update it once. No caller changes. No reports need republishing. No scripts need editing.

A migration you control

Once every caller talks to the proxy, the SuccessFactors auth change becomes a single project: register one OAuth client, configure one target credential, test, and switch. Not twenty projects running in parallel against a deadline you did not choose.

Power BI and reporting tools

Power BI deserves a specific callout because it is one of the most common SuccessFactors reporting tools and one of the least capable when it comes to OAuth SAML bearer.

Power BI’s OData feed connector supports Basic Auth, Azure AD OAuth, and API keys. It cannot sign SAML assertions, build XML documents, or manage a custom token exchange. Once SuccessFactors switches API Basic Auth off by default, Power BI reports that pull SuccessFactors OData will stop refreshing.

The usual alternatives are a paid third-party connector (such as CData’s Power BI connector for SuccessFactors), custom M code with a gateway-hosted token, or a proxy. The proxy option is the simplest: point the OData URL at the proxy endpoint, use Basic Auth with the proxy credential, and the report keeps refreshing. The queries, model, measures, and visuals stay exactly as they are.

For a detailed walkthrough of connecting Power BI through an auth proxy, see Connect Power BI to any API using Basic Auth.

How to find every caller

Before pointing callers at the proxy, inventory every integration using Basic Auth. SAP provides two tools:

API Audit Log in Admin Center. Filter for Basic Auth to see which API users are making calls and how often. Note: this shows the API user, not the calling system – you will need to map API users to the systems that hold those credentials.
The integration list you already have – plus the one you do not. Most teams can list the major integrations: the middleware platform, the payroll connector, the LMS sync. The surprises come from the edges – the department-level Power BI report, the consultant’s Python script, the scheduled export someone set up three years ago. Check with every team that touches HR data.

Every caller – whether it has a native SAML bearer connector or not – benefits.

Next steps

The 1H 2027 release is the practical deadline, but you do not have to wait for it to start. Set up RequestRocket now with your existing Basic Auth credential on the target side. Point callers at the proxy one at a time. Get observability and access governance working across the estate today. Then migrate the target credential to OAuth SAML bearer on your own timeline – one change, in one place, when you are ready.

Read the RequestRocket documentation for the full credential and proxy reference, or reach out at hello@requestrocket.com to discuss your SuccessFactors migration.

FAQ

When does SuccessFactors Basic Auth actually stop working?

API Basic Auth is switched off by default in the 1H 2027 release, with an opt-in migration window. It is permanently deleted on November 12, 2027. The earlier November 2026 dates apply to UI Basic Auth (November 13) and OpenText document management (November 20).

What is the OAuth 2.0 SAML bearer assertion flow?

You register an OAuth client in SuccessFactors with an X.509 certificate, build a SAML XML assertion naming the API user and client, sign it with the private key using RSA-SHA256, and exchange it at /oauth/token for a bearer token valid for about 24 hours.

Why can’t Power BI do this natively?

Power BI’s OData connector supports Basic Auth, Azure AD, and API keys. It has no mechanism to construct or sign SAML XML assertions or call a custom token endpoint with a signed payload. A proxy or third-party connector fills the gap.

Does an auth proxy mean copying the private key to another system?

The private key lives in one place – the proxy’s encrypted credential store – instead of being copied into every calling system. That is fewer copies than the “do it per caller” approach, not more.

What about the `/oauth/idp` endpoint?

SAP deprecated /oauth/idp because it required sending the private key over the network. It is deleted on May 14, 2027. Do not build new integrations against it. Use client-side assertion generation, a trusted IdP, or a proxy that generates assertions locally.

Is the 1H 2027 date final?

SAP describes future dates as subject to change. The API deletion date has already moved once (from November 2026 to November 2027, changed June 12, 2026). Plan for 1H 2027 but watch the What’s New Viewer for updates.