Salesforce OAuth user-agent flow retirement: prepare for 20 February 2027

Salesforce will retire the OAuth user-agent flow and hybrid user-agent flow on 20 February 2027. Applications still using either flow will stop working when Salesforce enforces the release update.

This deserves attention now because it is not only a Salesforce Setup change. The affected application sends tokens through a browser-based redirect, so migration normally requires application code, connection settings, user testing and a controlled reauthorisation. Where a managed package or third-party product owns the connection, the supplier must be involved.

Salesforce added a further signal in September 2026: new orgs created in Winter ’27 block the affected flows already. A team creating a new development, test or production org can therefore discover the dependency before the general enforcement date. The practical goal is to identify the real traffic, agree who owns each change and complete migration with enough time for failures and supplier delays.

What Salesforce has confirmed

Salesforce says the retirement applies across Lightning Experience and Salesforce Classic in all editions. The release update first became available in late Summer ’26 and is enforced on 20 February 2027. New Winter ’27 orgs block the user-agent and hybrid user-agent flows as part of the same direction of travel.

The reason is specific. In the user-agent flow, the access token is returned directly through the browser redirect. Salesforce warns that a token encoded in the redirect URL can be exposed to the user or other applications on the device. The retirement removes that token-delivery pattern.

Salesforce recommends moving to the OAuth web-server flow or hybrid web-server flow with the Proof Key for Code Exchange extension, usually shortened to PKCE. In a code-based flow, the browser receives a short-lived authorisation code rather than the access token. The client then exchanges the code, and PKCE binds that exchange to the client that initiated it.

Those are confirmed product facts. The discovery, sequencing and governance steps below are Ostrelis recommendations for turning the requirement into a manageable operational change.

Do not confuse this with the username-password retirement

Salesforce is also retiring the OAuth username-password flow on 20 February 2027. The deadlines match, but the technical dependencies do not. Username-password integrations typically submit credentials without an interactive browser. User-agent integrations direct a person through a browser and receive tokens in the redirect.

A single connected app can have several consumers, and labels such as “SSO app”, “mobile app” or “API integration” do not prove which OAuth grant is in use. Treat the two retirements as related portfolio work, but record and test each authentication route separately. Changing one route does not demonstrate that another consumer of the same app is safe.

Where to look for affected connections

Begin with Salesforce evidence, not a spreadsheet of remembered integrations. Review Login History and available event-monitoring data for OAuth User-Agent activity, client identifiers, usernames, source addresses and recent use. Use the Release Update test steps in a non-production environment to expose failures under controlled conditions.

Then reconcile that evidence with the application estate. Useful candidates include browser-based single-page applications, older desktop and mobile clients, Experience Cloud extensions, packaged applications and bespoke tools built when the implicit grant was common. Search source and configuration repositories for authorisation requests using response_type=token; Salesforce’s documented user-agent request uses that value, whereas a code-based flow requests an authorisation code.

Do not close an item merely because it has been quiet for a few weeks. Month-end tools, seasonal services and break-glass utilities may have legitimate but infrequent use. Record a last-seen date, business owner, technical owner, supplier, environments, user population and retirement decision for every candidate.

Choose the destination deliberately

Salesforce’s stated replacement for interactive browser-based integrations is the web-server or hybrid web-server flow with PKCE. The exact design depends on the client architecture and the Salesforce feature being used. Do not replace the retiring flow with a convenient grant simply because it is already available elsewhere.

A confidential server application, a native mobile client and an unattended system integration have different trust boundaries. Non-interactive workloads may justify another supported flow, but that is an architecture decision based on whether a person is present, where secrets can be protected and whose Salesforce authority the process should use. Preserve least privilege in OAuth scopes and user permissions rather than allowing the migration to widen access.

If the app is delivered by a supplier or managed package, ask for a supported version, the exact OAuth flow after upgrade, PKCE support, required callback changes, user reauthorisation steps, rollback behaviour and the date by which production migration will be supported. Salesforce explicitly directs customers to the app developer for applications they did not build.

Sequence PKCE changes to avoid an outage

Salesforce’s PKCE guidance describes a coordinated change. The client application must first be redeployed so that it can create a code verifier and send the corresponding code challenge. The Salesforce connection settings are then updated to require PKCE, and the client should be restarted and tested in a staging environment.

This order matters. Requiring PKCE before the deployed client can supply it can interrupt authentication. Conversely, leaving enforcement disabled indefinitely after the client supports PKCE weakens the control and makes regression easier. Treat application deployment, Salesforce configuration and validation as one release plan with named owners.

Be cautious with the org-wide Require Proof Key for Code Exchange (PKCE) setting. Salesforce says only the org owner can enable it and advises upgrading individual clients first. An org-wide control is valuable once compatibility is proven; it is not a shortcut for discovering which clients will fail.

A practical migration checklist

1. Open the release update. Read the current Salesforce instructions and record the status for each production org and relevant sandbox.
2. Build an evidence-based inventory. Combine Login History, OAuth usage evidence, connected or external client app records, source searches, service catalogues and supplier information.
3. Assign ownership. Name both a business owner and a technical or supplier owner. Unowned integrations are a delivery risk, not merely a documentation gap.
4. Confirm the current grant. Capture the actual authorisation request or trusted product documentation. Do not infer the OAuth flow from the application name.
5. Design the replacement. Select a supported flow for the client type, use PKCE where Salesforce recommends it, retain only necessary scopes and decide how refresh tokens will be stored and rotated.
6. Test the whole session lifecycle. Prove initial authorisation, callback validation, token exchange, renewal, revocation, logout, expired-session handling and meaningful error messages.
7. Test representative security conditions. Include SSO, MFA, network restrictions, mobile or desktop deep links and restricted users where they exist in production.
8. Cut over with observability. Monitor login failures, OAuth errors and business transactions, keep a time-bounded rollback decision and revoke obsolete tokens after success.
9. Close with evidence. Retain the migrated version, test results, approval, production timestamp and post-change monitoring outcome.

What good readiness looks like

A green status should mean more than “the connected app still exists”. A defensible record shows that current traffic was checked, the precise grant was identified, the replacement was tested in a realistic environment, the supplier committed where necessary and production behaviour was observed after cutover.

The February date leaves useful time, but supplier queues and application release cycles can consume it quickly. Prioritise integrations that are business-critical, externally maintained, used across several orgs or difficult to reproduce in a test environment. Retire abandoned connections instead of migrating them by default.

The Ostrelis view

This retirement is best handled as a small authentication portfolio, not a last-minute Salesforce toggle. The difficult work is usually ownership and evidence: knowing which application is making the request, who can change it and whether the full token lifecycle still works after migration.

A calm, staged programme can improve security while avoiding unnecessary disruption. Inventory from actual use, separate the affected OAuth grants, move interactive clients to an appropriate code-based pattern with PKCE, and leave enough time to resolve third-party dependencies before 20 February 2027.

Ostrelis can help organisations inventory Salesforce integrations, coordinate application owners, test authentication changes and manage controlled releases. See our Salesforce managed services, data and integration support and approach and experience. Need help getting prepared? Talk to a Salesforce expert.