Short answer: On 20 February 2027, Salesforce stops supporting the OAuth 2.0 username-password flow for connected apps. That's the token request with grant_type=password. After that date, integrations that use the flow can't get access tokens and stop working. Salesforce says there's no opt-out. To find them, run this query from Salesforce Help KA 005461279:
SELECT Application
FROM LoginHistory
WHERE LoginSubType = 'OAuth Username-Password'
Before 20 February 2027, move each application the query returns to one of two flows. Use client credentials for server-to-server integrations. Use the web-server flow with PKCE where a user logs in.
What changes
KA 005461279 explains the reason: the username-password flow "sends a user's credentials directly in an HTTP request." Salesforce is retiring it to improve security. The change was first announced in Spring '26.
Salesforce describes three effects once the flow is blocked or retired:
- Integrations that use the flow can't get access tokens and stop working.
- Login History shows the status OAuth Username-Password Flow Disabled.
- Token requests fail with
invalid_grantand the descriptionauthentication failure.
What users see depends on how each app handles the failed token request. The app might only show a generic login error, so search your integration logs for the invalid_grant / authentication failure response.
Who's affected
This covers any connected app integration that uses the username-password flow, in all editions, in both Lightning Experience and Salesforce Classic. That includes custom integrations and apps installed from managed packages.
One quick check: look for the Release Update Retirement of OAuth 2.0 Username-Password Flow for Connected Apps. If it doesn't appear in your org, Salesforce says the flow is already blocked in your OAuth and OpenID Connect settings and the change doesn't affect you. It's still worth confirming that your integrations work as expected.
In general, scripts, ETL or middleware connectors, and internal tools can use this flow because it's simple. A username-password token request needs only the user's username and password plus the app's consumer key and consumer secret, with no browser step. These integrations are easy to overlook once they work.
How to check your org
Option 1: the SOQL query. Run the query above with Salesforce CLI: sf data query --query "SELECT Application FROM LoginHistory WHERE LoginSubType = 'OAuth Username-Password'" --target-org <alias>. You can also use Web Console (Setup gear menu) or VS Code. Since Winter '27, Developer Console doesn't appear in the Setup menu by default (Salesforce Developers: Winter '27 developer guide). Use the English value 'OAuth Username-Password' exactly as written. The KA specifies this.
To trace each entry back to a server or service, you also need the user, source IP and login URL. The Connected App Retirement Kit's D02 query returns those for the last 180 days, and its notes explain which login URLs the client credentials flow won't accept.
Option 2: Login History in Setup. Open Setup → Login History. Make sure the Login Subtype column is in the view; if it isn't, edit the view or create one. Then look for OAuth Username-Password.
Don't rely on Login History alone. Salesforce's device-flow article (KA 005461280) notes that Login History holds up to six months of usage, so an annual job may not show up. Ask integration owners and vendors directly, and search app configurations and code for grant_type=password.
What to do
From KA 005461279:
- Identify affected integrations with the query or Login History.
- Server-to-server integrations → client credentials flow. Client credentials needs My Domain and runs as one execution ("Run As") user. If the integration logs in as several usernames in one org, Salesforce recommends the JWT bearer flow instead (KA 000886201).
- Integrations that need an end user to log in and authorize → web-server flow with PKCE (Proof Key for Code Exchange).
- Apps you didn't build: contact the developer and confirm an updated version will be available before 20 February 2027.
- Test with the flow blocked. In a test environment, block the username-password flow, test each integration and update any that fail. The Release Update in Setup has Salesforce's guided testing and activation steps.
- Deploy to production once every integration works with the flow blocked.
KA 005461279 names only client credentials for server-to-server integrations. Salesforce's SOAP login() article (KA 005132110) and its username-password migration article (KA 000886201) also document the JWT bearer flow for server-to-server integrations, and which one fits depends on how many usernames the integration uses and what your middleware supports. The kit's decision tree walks through that choice.
Timeline
| Date | What happens | Source |
|---|---|---|
| Spring '26 | Retirement first announced | KA 005461279 |
| Before 20 Feb 2027 | Use the Release Update to test with the flow blocked | KA 005461279 |
| 20 Feb 2027 | Flow retired for connected apps; token requests fail; no opt-out | KA 005461279, KA 005461287 |
FAQ
When does Salesforce retire the OAuth username-password flow?
On 20 February 2027. After that, connected app integrations that use it can't get access tokens.
Can I opt out or turn it back on after 20 February 2027?
No. KA 005461279 says there's no opt-out, and re-enabling the flow isn't a supported fix.
What error will a retired username-password request return?
invalid_grant with the description authentication failure. Login History shows OAuth Username-Password Flow Disabled.
Which flow should replace it?
KA 005461279 says to use client credentials for server-to-server integrations and the web-server flow with PKCE when an end user logs in. Salesforce's SOAP login() article (KA 005132110) also lists JWT bearer for server-to-server integrations, and KA 000886201 recommends JWT bearer when the integration uses several usernames in one org.
The Release Update isn't in my org. Am I affected?
According to Salesforce, no, because the flow is already blocked in your OAuth and OpenID Connect settings. Still check that your integrations work.
Does a managed-package app count?
Yes, apps installed from managed packages are included. Ask the vendor for an updated version before the deadline.
Sources
- KA 005461279, Security Change: Retirement of the OAuth 2.0 Username-Password Flow by February 20, 2027 (published Oct 14, 2026)
- KA 005461287, Connected App & External Client App Security Requirement Updates (hub table, Oct 14, 2026)
- KA 005132110, Platform SOAP API login() Retirement & new Security Requirements (JWT bearer as a server-to-server option)
- KA 000886201, Migrate from OAuth Username-Password to Client Credentials Flow (My Domain and Run As user requirements; JWT bearer for several usernames)
- KA 005461275, Security Change: Refresh Token Idle TTL Is Limited to 30 Days
- KA 005461280, Security Change: OAuth 2.0 Device Flow Restrictions by November 30, 2026 (six months of Login History)
- Salesforce Help: OAuth 2.0 Username-Password Flow for Special Scenarios and OAuth 2.0 JWT Bearer Flow for Server-to-Server Integration (general flow behaviour)
- Salesforce Developers Blog: The Salesforce Developer's Guide to the Winter '27 Release (Web Console; Developer Console hidden by default)
Last checked: 29 October 2026, against the Salesforce pages above. If a Salesforce page and this article disagree, go by the Salesforce page.
Want the other checks too? The free 15-Minute Integration Auth Risk Check starts with this query and covers the other deadlines, and there's no sign-up. It's also in the sfauthdeadline.com checklist section. To plan and run the migrations, the Connected App Retirement Kit has discovery queries, an inventory workbook, a decision tree and migration runbooks.
sfauthdeadline.com is an independent resource. It is not affiliated with, endorsed by or sponsored by Salesforce. Salesforce is a trademark of Salesforce, Inc.