Salesforce 2027 Auth Migration: Replacing Username-Password Flow

Salesforce 2027 Auth Migration: Replacing Username-Password Flow

Salesforce is killing username-password authentication in 2027 across two coordinated retirements. In Winter '27, Salesforce will stop supporting the OAuth 2.0 username-password flow for connected apps — this update will break all connected app integrations that use this flow. The SOAP API login() operation will be fully retired on June 1, 2027. Both retirements target the same anti-pattern — the username-password flow directly passes the user's credentials in HTTP requests, which presents security risks — and both require the same fix: OAuth 2.0.

If your org runs nightly data loads, middleware syncs (MuleSoft, Boomi, Informatica, Workato, Jitterbit), or custom scripts that authenticate by posting a username, password, and security token, this guide covers exactly what breaks, how to find every affected integration, and how to migrate to a supported auth flow before the deadlines hit.

The 2027 Salesforce Authentication Retirements Explained

These are two separate retirements of the same bad pattern: passing real user credentials to authenticate. They hit different dates and affect different authentication methods, but you should plan for both in a single pass.

Retirement #1: OAuth 2.0 Username-Password Flow (Winter '27)

Salesforce is retiring the OAuth 2.0 username-password flow — the one where an integration posts grant_type=password with a username, password, and security token — for connected apps. It ships as a Release Update enforced with Winter '27. When your org reaches its Winter '27 upgrade date, every integration still using that flow stops getting an access token and fails to authenticate.

This is not optional. Salesforce enforces this update in Winter '27. It is already blocked by default in newly created orgs, so this is mostly about existing orgs that still have long-running integrations wired the old way.

The production upgrade weekends are August 29, October 3, and October 10, 2026. Your specific date depends on your Salesforce instance. To get the major release upgrade date for your instance, go to Trust Status, search for your instance, and click the Maintenance tab.

Retirement #2: SOAP API login() Operation (June 1, 2027)

In Summer '27, the SOAP API login() call in SOAP API versions 31.0 through 64.0 will no longer be supported and no longer be available. This is the legacy method that authenticates by sending a username, password, and security token in an XML payload to receive a session ID.

An important distinction: Salesforce is not retiring the SOAP API itself. The retirement specifically affects the SOAP API login() authentication operation. Organizations can continue using SOAP API functionality after Summer '27, provided authentication is performed through supported OAuth-based mechanisms.

If your organization relies on SOAP login() for Data Loader, MuleSoft, Informatica, Jitterbit, Boomi, custom Java or .NET applications, or any integration that passes a username and password to get a session ID — you must migrate before June 1, 2027.

The Security Rationale

Passing passwords in HTTP requests — even over TLS — is a known security liability. Service accounts using legacy flows typically have non-expiring passwords and bypass Multi-Factor Authentication entirely. SOAP login() bypasses multi-factor authentication, creating a security gap that undermines your MFA investment.

By forcing a move to OAuth 2.0 Client Credentials and JWT Bearer flows, Salesforce is removing the password from the integration layer entirely and eliminating an entire class of attack vector.

The API Version Retirements Compounding This

These auth retirements land on top of an ongoing API version deprecation cycle:

If you have a legacy integration that survived the v21–30 sunset by bumping the endpoint to /services/data/v31.0/, you are on the clock again. Full retirement of API versions 31.0–40.0 follows in Summer '28, at which point calls to those versions will fail. All integrations must be on API version 41.0 or later to remain operational. When migrating your authentication flows, upgrade your API endpoints simultaneously to prevent compounding failures.

What Breaks: The Silent Failure of Server-to-Server Integrations

The failure mode is what makes these retirements dangerous. The break happens at the authentication layer — integrations don't degrade gracefully, they fail completely and instantly.

Anything sending grant_type=password to your token endpoint dies on upgrade weekend. When login() in SOAP API versions 31.0–64.0 is retired, applications using those versions will experience disruption. The requests will fail with an error message indicating that the login() endpoint has been deactivated.

Systems That Will Break

• Middleware Platforms: Older connectors in MuleSoft, Boomi, Informatica, Workato, and Jitterbit often default to SOAP login() or grant_type=password. If the connector configuration requires a password and a security token, it will break.
• Custom Scripts: Python, Node.js, Java, and .NET applications running nightly cron jobs that pass credentials in the auth payload.
• Data Loader: Any Data Loader instance prior to version 45.0, or any modern Data Loader instance configured to use Password Authentication instead of OAuth. Version 45.0 was the first release with full native OAuth support and is the minimum supported version for continued operation after Winter '27. To check your version, open Data Loader and navigate to Help > About Data Loader. Salesforce's Data Loader release notes document the OAuth configuration steps for v45 and later.
• Connected App Integrations: Every connected app using grant_type=password stops authenticating on your org's Winter '27 upgrade date.

The Failure Modes

For OAuth Username-Password flow: The token endpoint returns HTTP 400 Bad Request with an unsupported_grant_type or invalid_grant error. Downstream API calls fail with HTTP 401 Unauthorized.

For SOAP login(): Requests fail with a SOAP fault indicating that the login() endpoint has been deactivated. The specific fault code is sf:UNSUPPORTED_CLIENT or a deactivation message depending on the API version targeted.

How to Audit Your Org for Impacted Integrations

Do not rely on institutional memory to find legacy integrations. You must audit the system to see exactly how external systems are authenticating right now.

1. Check Setup > Release Updates

From Setup, enter Release Updates in Quick Find, then select Release Updates. Find Retirement of OAuth 2.0 Username-Password Flow for Connected Apps and follow the testing and activation steps. If you don't see this release update listed, you already have the username-password flow blocked and this change doesn't affect you.

The Release Update page includes an assessment tool that flags Connected Apps actively using grant_type=password.

2. Query LoginHistory for OAuth Username-Password Flow

The most definitive way to find systems using the OAuth Username-Password flow is to query the LoginHistory object. Logins using grant_type=password appear with LoginType = 'Remote Access 2.0'. Run this SOQL query via Developer Console or Salesforce CLI:

SELECT Application, UserId, COUNT(Id) Logins,
       MAX(LoginTime) LastSeen
FROM LoginHistory
WHERE LoginType = 'Remote Access 2.0'
  AND LoginTime = LAST_N_DAYS:180
GROUP BY Application, UserId
ORDER BY MAX(LoginTime) DESC

This returns every connected app using the legacy OAuth flow, the user it runs as, how often it authenticated, and when it last logged in. Cross-reference the Application column with your connected app list.

3. Query LoginHistory for SOAP login() Usage

SOAP login() calls appear in LoginHistory with LoginType = 'Application' and a null ConnectedAppId. Use this query to identify them:

SELECT Application, UserId, LoginType, COUNT(Id) Logins,
       MAX(LoginTime) LastSeen
FROM LoginHistory
WHERE LoginType = 'Application'
  AND LoginTime = LAST_N_DAYS:180
GROUP BY Application, UserId, LoginType
ORDER BY MAX(LoginTime) DESC

Cross-reference results against known OAuth-authenticated applications. Any Application value that cannot be matched to a Connected App with a valid OAuth token is a candidate for SOAP login() usage. The CONNECTED_APP_ID field in LoginHistory being empty or null is a strong indicator that the application is authenticating through SOAP API login() or a session-based approach.

Additionally, search your codebase and middleware configurations for:

• login.salesforce.com/services/Soap/u/
• login.salesforce.com/services/Soap/c/
• test.salesforce.com/services/Soap/u/
• <n1:login xmlns:n1="urn:enterprise.soap.sforce.com">
• Any login() calls in custom Java, .NET, or Python SOAP clients

4. Check Connected Apps OAuth Usage

Navigate to Setup > Connected Apps OAuth Usage. This page lists every Connected App currently generating OAuth tokens in your org, with user counts and last-used dates. Any app here that your team doesn't recognize is worth investigating.

5. Analyze EventLogFile Records

Organizations can query EventLogFile records to analyze API consumption programmatically, including authentication methods, API versions, and application activity across the organization. This is useful for identifying SOAP login() usage in high-volume environments where LoginHistory sampling may miss infrequent calls.

Any system hitting SOAP login endpoints must be re-architected before June 1, 2027.

Replacement Paths: Client Credentials, JWT Bearer, and Named Credentials

For better security, update your integrations to use the OAuth 2.0 web-server flow or the OAuth 2.0 client credentials flow. For server-to-server integrations — which is most of what breaks here — the two primary replacement flows are Client Credentials and JWT Bearer. Named Credentials act as an abstraction layer on top of either.

OAuth 2.0 Client Credentials Flow

Best for: Nightly jobs, middleware connectors, ETL scripts — any server-to-server integration that doesn't need per-user context.

In this flow, the client app exchanges its consumer key and consumer secret for an access token. This flow eliminates the need for explicit user interaction, though it does require you to specify an integration user to run the integration. You can use this flow as a more secure alternative to the OAuth 2.0 username-password flow.

The token request changes from:

POST /services/oauth2/token
grant_type=password&client_id=...&client_secret=...&username=...&password=...

To:

POST /services/oauth2/token
grant_type=client_credentials&client_id=...&client_secret=...

No username. No password. No security token.

Setup steps:

1. Create an External Client App (ECA) in Setup > App Manager. As of Spring '26, Salesforce no longer allows creation of new Connected Apps through the UI or API except during package installation. Existing Connected Apps continue to function, but all new integrations must use External Client Apps.
2. Under API (Enable OAuth Settings), select Enable Client Credentials Flow.
3. Set the OAuth scope to api.
4. Assign a Run As user (required). Although there's no user interaction in the client credentials flow, Salesforce still requires you to specify an execution user. Navigate to the ECA's settings and set the Run As user explicitly. If you skip this step, the token endpoint returns an error even if all other settings are correct — this is the most common silent setup failure for this flow. Use a Salesforce Integration User license (API Only) to restrict the scope.
5. Assign the ECA to a permission set that grants the integration user least-privilege access.

Token behavior: The Client Credentials flow issues an access token with a default expiration of 2 hours. It does not issue a refresh token. Your integration must handle token re-acquisition by repeating the client credentials exchange when it receives an HTTP 401. Build this retry logic before deploying to production.

Trade-offs: This is the easiest flow to implement, but it still requires transmitting a client secret over the wire. For most standard integrations and middleware connectors, this trade-off is acceptable.

OAuth 2.0 JWT Bearer Flow

Best for: High-value integrations, regulated environments, or anywhere your infosec policy prohibits transmitting shared secrets over the wire.

For higher-value integrations, prefer JWT because secrets do not travel across the wire during authentication. The integration signs a JWT assertion with a private key. The corresponding X.509 certificate is uploaded to the Connected App or ECA in Salesforce. Salesforce verifies the signature using the stored certificate and issues an access token.

How it works:

1. Generate an X.509 certificate and private key (2048-bit RSA minimum; 4096-bit recommended for new implementations).
2. Upload the certificate to the Connected App or ECA in Salesforce under Use Digital Signatures.
3. The external system uses the private key to sign a JSON Web Token (JWT) containing the iss (consumer key), sub (username of the integration user), aud (https://login.salesforce.com or https://test.salesforce.com), and exp (expiration, max 3 minutes from issue) claims.
4. Post the signed JWT to the token endpoint with grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer.
5. Salesforce verifies the signature against the stored certificate and returns an access token.

Token behavior: The JWT Bearer flow issues both an access token (2-hour default expiration) and a refresh token. Long-running integrations can use the refresh token to obtain new access tokens without re-signing a JWT on every request. This is a meaningful operational difference from Client Credentials.

Trade-offs: This flow provides superior security but requires rigorous certificate lifecycle management. X.509 certificates have a fixed expiration date — if the certificate expires, authentication fails silently until someone investigates. Track certificate expiration dates in your secrets management system (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) and implement rotation procedures with at least 30 days of lead time. Distribute the private key securely using your secrets manager, not in source code or config files. For critical financial data, HRIS syncs, or integrations where transmitting a client secret is prohibited by policy, JWT Bearer is the stronger option.

Named Credentials

Best for: Abstracting authentication so Apex code and middleware configurations never touch secrets directly.

Named Credentials in Salesforce simplify managing API calls to external services by securely storing the required authentication details. By leveraging Named Credentials, you can securely access external systems without hard-coding sensitive information like usernames, passwords, or OAuth tokens.

Named Credentials aren't a replacement flow — they're a layer on top of Client Credentials or JWT Bearer that keeps secrets out of your code. The external credential represents the details of how Salesforce authenticates to an external system via an authentication protocol. Your Apex callouts or middleware configs reference the Named Credential by name, and Salesforce handles token acquisition and refresh automatically.

Sandbox-to-production credential management: Named Credential configurations do not automatically carry credential values (consumer key, consumer secret, certificates) when deployed between sandboxes and production. The Named Credential definition (the metadata) deploys, but the credential values must be re-entered manually in each environment, or provisioned via a secrets management integration. Build this into your deployment runbook to avoid broken integrations after change set deploys.

IP restrictions interaction: If your org enforces IP restrictions on Connected Apps or profiles, newly migrated OAuth flows may fail even after correct configuration. Client Credentials and JWT Bearer flows originate from Salesforce's IP ranges (when used with Named Credentials for outbound callouts) or from your middleware platform's IP ranges (for inbound token requests). Verify that the integration user's profile and the Connected App/ECA do not have IP restrictions that would block the new OAuth flow's source IP before cutting over.

Which Flow to Choose

Executing the Migration Without Integration Downtime

Migrating authentication flows on production systems carries a high risk of downtime if executed poorly. The safest path uses sandbox validation, parallel auth configurations, and Salesforce's built-in test run feature.

Step 1: Build Your Integration Inventory

Use the LoginHistory SOQL queries, Connected Apps OAuth Usage page, EventLogFile analysis, and code repository searches from the audit section above. Document every integration: what it does, who owns it, what auth flow it uses, what API version it targets, and the Data Loader version if applicable.

Step 2: Test the Retirement in Sandbox

Sandbox upgrade timing: Preview sandboxes receive the Winter '27 release over the August 28–29, 2026 weekend. Most production orgs upgrade on October 3 or October 10, 2026 — your specific date depends on your instance. Check Trust Status for your instance's exact maintenance window. These two dates are not contradictory: sandbox upgrades happen first, giving you approximately 5 weeks to validate before production enforcement.

To enable the retirement simulation in your sandbox:

1. Navigate to Setup > Release Updates.
2. Find the Username-Password flow retirement update.
3. Click Enable Test Run.

This immediately blocks grant_type=password in that org. Use this in a Full Copy Sandbox to verify your new auth flows work correctly and confirm no legacy integrations were missed during your audit.

Salesforce also provides a test run for the SOAP API login() retirement: enabling this test run disables the SOAP API login() call in your org, allowing you to validate integrations before the June 1, 2027 enforcement date.

Step 3: Configure Replacement Auth in Parallel

Don't rip out the old flow before the new one is validated. Configure the new External Client App with Client Credentials or JWT Bearer, test it against your sandbox, and confirm the integration runs end-to-end. Only then switch production.

For each integration:

1. Create the new ECA or update the existing Connected App settings.
2. Provision a dedicated Integration User with a least-privilege permission set — not a full admin profile.
3. For Client Credentials: Assign the Run As user explicitly in the ECA settings. Verify the token request returns an access token before proceeding.
4. For JWT Bearer: Upload the X.509 certificate, verify the JWT claims (iss, sub, aud, exp), and confirm the token endpoint returns an access token. Store the private key in your secrets manager, not in the codebase.
5. Update the integration's auth configuration to use the new client_credentials or jwt-bearer grant type.
6. Implement token expiration handling: for Client Credentials, implement retry logic that re-acquires a token on HTTP 401; for JWT Bearer, implement refresh token rotation.
7. Run a full sync cycle and verify data integrity.
8. Cut over in production during a low-traffic window.

Step 4: Monitor Post-Cutover

After cutover, monitor LoginHistory for any remaining grant_type=password entries or SOAP login() calls using the queries from the audit section. If Remote Access 2.0 entries or null-ConnectedAppId Application logins still appear, you have missed an integration that will break on upgrade day.

Once all integrations are migrated, consider manually enabling the Test Run in production to lock down the org ahead of the enforcement date.

What Happens If You Do Nothing

Here is the complete timeline:

Once enforcement goes live, every integration relying on this authentication method will stop working. API calls will fail, data syncs will break, and automated business processes will halt with no grace period.

There is no extension coming. The retirement is a Release Update, so it enforces whether or not you act, and the break is at authentication, so the integration fails completely rather than degrading.

Why Data Migration Is the Right Time to Re-Architect Auth

When organizations migrate CRM, helpdesk, or HRIS data, the integration layer gets exposed. Every connector between Salesforce and other platforms — Zendesk, HubSpot, Freshdesk, ServiceNow, Intercom — has an authentication configuration. If it was set up before 2024, there's a meaningful chance it's using username-password auth.

During a data migration, you already have a complete integration inventory, a tested cutover window, and the attention of the people who own each system. This is when it costs the least to also migrate auth flows: the sandbox is already provisioned, the integration owners are already engaged, and the deployment runbook already exists.

This is especially relevant for organizations running middleware connectors between Salesforce and other SaaS platforms. If you're migrating from Freshdesk to Salesforce Service Cloud, or consolidating from HubSpot into Salesforce, the integrations that connect your old platform are going away anyway — and the new ones need to be built on supported auth from day one. Rebuilding on Client Credentials or JWT Bearer during the migration means you aren't returning to this problem six months before the October 2026 deadline.