Salesforce OAuth username-password flow retirement: prepare for 20 February 2027

Salesforce will retire the OAuth 2.0 username-password flow for connected apps on 20 February 2027. When the release update is enforced, integrations that still obtain tokens by sending a Salesforce username and password to the OAuth token endpoint will stop working.

The change deserves a controlled response, not panic. The main difficulty is often discovering where the flow is still used and who owns the calling system. A small script written years ago, a middleware connector, a desktop utility and a vendor application can all look similar from the Salesforce side while needing different migration routes.

Salesforce originally scheduled enforcement with the Winter ’27 major release, but its current release-update guidance now gives 20 February 2027 as the enforcement date. Platform owners should use that confirmed date and plan backwards with margin.

What Salesforce has confirmed

The release update applies to connected app integrations using the OAuth 2.0 username-password flow. Salesforce states plainly that affected integrations will break after enforcement. If the release update does not appear in an org, Salesforce says the flow is already blocked and the change does not affect that org.

The flow sends the resource owner’s username and password directly as part of the token request. It does not provide the browser-based authorisation and stronger separation available in newer patterns. Salesforce’s stated replacements are the OAuth web-server flow with Proof Key for Code Exchange (PKCE) for end-user login and authorisation, or the client credentials flow for server-to-server integration.

Those are confirmed product directions. Choosing the right flow for a particular application, and deciding how to sequence the migration, remains an implementation and operating decision.

Do not confuse this with SOAP API login()

Salesforce now has two retirements that can be described informally as ‘username and password integrations’:

• OAuth username-password flow: the application posts credentials to /services/oauth2/token with the OAuth password grant. This is the Winter ’27 release update covered here.
• SOAP API login(): the application calls the SOAP login() operation to obtain a session ID. Salesforce has separately scheduled that operation’s remaining supported API versions for retirement with Summer ’27.

The business symptom may be identical—an unattended integration can no longer authenticate—but the request, configuration and remediation evidence differ. Review the actual authentication handshake. Do not mark an integration safe merely because its owner says it ‘uses OAuth’, and do not assume every service account is affected because it has a password.

Build an inventory before selecting a solution

Start with the release update in Setup. Follow Salesforce’s review and testing steps, but treat the result as technical evidence rather than a complete business inventory. Then inspect connected apps, OAuth usage, login history and available event monitoring data for candidate users and clients.

Reconcile that evidence with the integration catalogue, middleware schedules, source-code repositories, secrets registers and vendor product list. Ask operations teams about month-end routines, spreadsheet utilities, data loaders and recovery jobs. A connection that did not run during a short log sample may still be important.

For every candidate, record:

• business purpose and criticality;
• production and non-production environments;
• connected app, integration user and current OAuth flow;
• internal owner, supplier and technical contact;
• execution frequency and last confirmed successful run;
• data and permissions available through the connection;
• target authentication flow, test status and cutover date.

Keep ‘unknown’ as a visible status. Uncertainty should trigger investigation, not an assumption that the integration is obsolete.

Choose the replacement from the use case

For a genuine interactive application, Salesforce recommends the web-server flow with PKCE. A person is redirected to Salesforce to authenticate and authorise access; the application exchanges the resulting authorisation code using a PKCE verifier. The client needs correct callback handling, secure token storage and a workable re-authorisation journey.

For an unattended server-to-server service, client credentials may be appropriate. Salesforce configures a specific run-as user for the connected app, and the client exchanges its app credentials for an access token. The design still needs secure secret storage, rotation, monitoring and least-privilege permissions. Anyone able to use the client secret can obtain a token acting as the configured user.

Other supported patterns, including JWT bearer, may suit particular architectures. Salesforce’s AppExchange security guidance recognises JWT bearer for server-to-server use. The Ostrelis recommendation is to document why the chosen flow matches the interaction, identity and credential-management model rather than selecting one only because a library already supports it.

Migration is also a good point to review OAuth scopes and the integration user’s permissions. Replacing the grant type while preserving unnecessary full scope or broad object access carries old risk into the new design.

Test the complete operating cycle

A successful token request is only the first test. In a representative sandbox, prove the business transaction, error handling, token expiry, repeated scheduled runs, credential rotation and recovery after revocation. Confirm that logs reveal enough to distinguish an authentication failure from a data validation or platform error without recording passwords, secrets or tokens.

Where a third-party product owns the client, obtain a supported-version statement and upgrade instructions from the supplier. Ask whether the migration requires a new connected app, administrator consent, user re-authorisation or planned downtime. A general claim that the product ‘supports Salesforce OAuth’ is not sufficient evidence that it no longer uses this flow.

Use Salesforce’s Release Updates test and activation steps before enforcement where available. Run the test in a controlled window with named observers and rollback instructions. Its purpose is to expose a dependency safely, not to prove confidence by switching it on casually.

A practical plan for 20 February 2027

1. Now: confirm the affected orgs and applications, assign an accountable platform owner and export the candidate inventory.
2. Within two weeks: classify each authentication request, contact suppliers and prioritise unclear or business-critical connections.
3. Well before 20 February 2027: implement and test the replacement in a representative sandbox, including failure and credential-lifecycle scenarios.
4. During cutover: monitor both the Salesforce and external-system sides, with explicit success measures and a time-limited rollback route.
5. After stabilisation: remove obsolete passwords and configuration, reduce unnecessary access and update the integration register and support runbook.

This timetable is Ostrelis operational guidance, not a Salesforce mandate. Organisations with numerous vendor-managed connections or limited sandbox coverage may need more lead time.

The Ostrelis view

This retirement is as much an ownership test as an authentication change. Well-governed integrations have a named service owner, a dedicated identity, a documented flow, proportionate permissions, monitored failure routes and an understood credential lifecycle. Where those details are missing, migration should begin with discovery.

A useful outcome is not simply that the legacy grant stops appearing. It is that platform and operations teams can explain which systems connect, why they have access, who supports them and how authentication can be changed safely next time.

Ostrelis can help organisations investigate Salesforce integration dependencies, coordinate vendors, review authentication designs and manage controlled cutovers. See our Salesforce data and integration services, managed Salesforce support and approach and experience.