Salesforce OAuth Password-Flow Retirement
Salesforce retires the OAuth 2.0 username-password flow on 20 February 2027. Any integration still using it will stop authenticating. The code change is the easy part; finding every caller is the real work.
The Quick Answer
The OAuth 2.0 username-password flow sends credentials directly to the token endpoint and bypasses MFA. Salesforce is retiring it on 20 February 2027. Replace it with client credentials flow for server-to-server jobs, JWT bearer flow for multi-user clients, or web-server flow with PKCE for person logins. Start with the inventory: build a Login History view, reconcile with external systems, and give every connection an owner.
Pick the Replacement Flow
| Use Case | Replacement Flow | Notes |
|---|---|---|
| Server-to-server jobs | Client credentials | Configure a run-as user on the connected app. Treat the client secret like a production password. |
| Multiple usernames in one org | JWT bearer | Issue a JWT signed with a private key. More complex but supports per-user context. |
| Person logs in (UI) | Web-server with PKCE | Dynamically generated secret per login. The modern standard for user-facing apps. |
The Migration Checklist
- Check the setting first In Setup, open OAuth and OpenID Connect Settings. See whether "Allow OAuth Username-Password Flows" is on. If it's off, you're not affected.
- Build a Login History view Filter on Login Subtype equals "OAuth Username-Password." Every row is a caller you need to explain. Export and deduplicate by Connected App.
- Look at the release update in Setup If the release update doesn't appear in your org at all, the flow is already blocked and the change doesn't affect you.
- Reconcile with external systems Check middleware schedules, source repositories, secrets registers, and vendor product lists. A month-end job or recovery script may not show in a short log sample.
- Ask vendors for proof "We support Salesforce OAuth" is not an answer. Ask which flow their current version uses, and whether migrating needs a new connected app, admin consent, or downtime.
- Give every connection an owner Track: purpose, environments, run-as user, frequency, last successful run, target flow, test status, cutover date. Keep "unknown" as a visible status.
- Pick the replacement flow per integration Server-to-server → client credentials. Multiple users → JWT bearer. Person login → web-server with PKCE.
- Test the full lifecycle Not just a single token request: scheduled reruns, token expiry, secret rotation, and recovery after revocation.
- Verify Login History stays empty After migration, rerun the Login History view with the OAuth Username-Password filter. It should show zero new rows.
Frequently Asked Questions
When does Salesforce retire the OAuth password flow?
Salesforce retires the OAuth 2.0 username-password flow for connected apps on 20 February 2027. On the morning after enforcement, any integration still sending username, password, and security token to the token endpoint will fail to log in.
What replaces the OAuth password flow?
For server-to-server jobs, use the client credentials flow. For clients using multiple usernames in one org, use the JWT bearer flow. For apps where a person logs in, use the web-server flow with PKCE.
How do I find integrations using the password flow?
In Setup, create a Login History view. Filter on "Login Subtype equals OAuth Username-Password." Every row represents a caller that needs to migrate. Export this list and deduplicate by Connected App name.
Is SOAP API login() also being retired?
Yes, but it's a separate retirement. The SOAP API login() call for remaining supported API versions is scheduled for retirement with Summer '27. The symptom is the same (unattended jobs can't authenticate), but the fix and evidence are different.
What if the release update doesn't appear in my org?
If the release update doesn't appear in your org's Setup, the flow is already blocked and this change doesn't affect you. Orgs created in Summer '23 or later have the flow blocked by default.
Is client credentials flow more secure?
Not automatically. Anyone holding the client secret can get a token as the run-as user. Treat the secret like a production password: store it in a vault, rotate it regularly, and give the run-as user minimum permissions.
Sources & Related Posts
This guide is maintained by Devarshi Mishra and updated as Salesforce releases new information.