Salesforce OAuth Flows: Choosing the Right Authentication Design

How do you choose the right Salesforce OAuth flow? Send a human through the Authorization Code Flow with PKCE, wire a server-to-server job to the JWT Bearer Flow (or the Client Credentials Flow), and never fall back to a username, password, and security token because it is quicker to stand up. That last shortcut is now on a countdown: Salesforce retires the OAuth 2.0 username-password flow for connected apps on each org's Winter '27 upgrade date, between September 4 and October 9, 2026, and it is already blocked by default in newly created orgs. Get the design wrong and you either lock legitimate integrations out of your org or leave a long-lived credential where an attacker can find it.

How do you choose the right Salesforce OAuth flow?

Every OAuth decision starts with one question: is a person authorizing this connection, or is a machine?

If a person is present, route them through the Authorization Code Flow with PKCE (Proof Key for Code Exchange). PKCE binds the authorization code to the client that requested it, so a code intercepted in transit is useless to an attacker. Prefer it over the OAuth 2.0 Device Flow, which Salesforce has been pulling back: it removed Device Flow support from the auto-installed Data Loader connected app on 2 September 2025, and Data Loader 64.1.0 dropped both the Device Flow and the User-Agent Flow. Both were easy to abuse because they could be kicked off with little more than a client ID, a favorite target for social engineering.

If no person is present, such as a nightly ETL job or middleware pushing records into Salesforce, choose a server-to-server flow: the JWT Bearer Flow or the Client Credentials Flow. Both let a backend service authenticate without a browser or a session to redirect. The same either-or choice sits underneath most of the integration architecture patterns that actually scale, because the authentication design has to survive every retry, timeout, and credential rotation those patterns throw at it.

JWT Bearer vs Client Credentials: which server-to-server flow?

Both flows authenticate the app itself with no user in the loop, but they trade differently on secret handling.

• JWT Bearer Flow authenticates with a digitally signed certificate instead of a shared secret. There is no client secret sitting in a config file to leak, the signed assertion is short-lived, and rotating the key means swapping a certificate rather than redeploying code. Reach for this when you want the strongest posture and can manage a private key.
• Client Credentials Flow exchanges a consumer key and consumer secret for an access token and runs as a designated integration user. It is simpler to set up, but the secret is a bearer credential: anyone who intercepts it can impersonate the integration, so it has to be stored and rotated with real discipline.

Whichever you pick, scope the running or integration user tightly with a dedicated profile and permission sets instead of granting broad admin access for convenience. A machine account that can only touch the objects it needs is the difference between a contained incident and a full-org compromise.

Connected Apps vs External Client Apps: what changed for 2026?

Salesforce has been splitting the classic connected app into two purpose-built app types, and the timeline now forces the decision. As of Spring '26, Salesforce restricts the creation of new connected apps and recommends external client apps instead; existing connected apps keep working during and after the change. If you genuinely must create a new connected app, you have to contact Salesforce Support.

External client apps are the newer, recommended path for any external system authenticating into Salesforce over OAuth, including your own middleware, ETL tools, and partner integrations. They take a deliberately stricter stance: they support the secure OAuth flows only and exclude the username-password flow entirely. They also support the Metadata API fully and keep consumer secrets out of packaged components, which makes them far easier to manage through source control and CI/CD pipelines than a legacy connected app.

The practical takeaway in an architecture review: default to an external client app for new integrations, and reserve connected apps for the Salesforce-native cases that still need them, such as canvas and mobile publishing. Reaching for a legacy connected app out of habit now means running into a creation restriction on your next build.

Where do Named Credentials fit into a secure integration design?

Named Credentials solve a different problem: outbound callouts from Salesforce to external systems, driven by Apex or Flow. Instead of hardcoding an endpoint URL and OAuth details inside a class, you register a Named Credential once and reference it by name, scoped per user or org-wide, and Salesforce handles the token exchange and refresh behind the scenes.

This matters for security review because it removes credentials from code entirely. Whether the underlying handshake is JWT Bearer or Client Credentials, the secret or key lives outside your integration code, so rotating it happens in one place instead of hunting through Apex classes and Flow definitions. When you connect Salesforce to a heavyweight system of record like an ERP, this is what keeps the Salesforce and SAP integration patterns auditable rather than a pile of embedded passwords.

How do you migrate legacy username-password integrations to modern OAuth flows?

Most orgs we review still have at least one integration authenticating with a username, password, and security token, sometimes from a script nobody remembers writing. With the Winter '27 retirement window fixed, that is no longer technical debt you can defer. A structured migration looks like this:

• Inventory every integration user and API-enabled profile to find where password-based logins are still in use.
• Classify each integration as user-present or server-to-server, then map it to Authorization Code Flow with PKCE, JWT Bearer Flow, or Client Credentials Flow.
• Register a dedicated External Client App per integration rather than sharing one app across unrelated systems.
• Move outbound callouts behind Named Credentials so secrets live outside the codebase.
• Rotate the old integration user's password and revoke its API access once traffic has fully cut over.

Sequence the cutover integration by integration, confirming each connection authenticates in a sandbox before touching the credential production depends on. The same authentication design also underpins newer patterns like running CRM actions from an agentic hub, where a single machine identity fans out across many actions and a leaked secret would be that much more damaging.

This is the kind of work our consulting team handles regularly. If your org still runs password-based integrations, we can map the migration path before your org's Winter '27 upgrade turns it into a fire drill. Get in touch to talk through your setup.

FAQ

When is the Salesforce username-password OAuth flow retired?

Salesforce retires the OAuth 2.0 username-password flow for connected apps on each org's Winter '27 upgrade date, between September 4 and October 9, 2026, and it is already blocked by default in newly created orgs. Migrate affected integrations to the web server flow, JWT Bearer Flow, or Client Credentials Flow before then.

Can I still create a new Connected App in 2026?

Salesforce restricts creation of new connected apps as of Spring '26 and recommends external client apps instead. Existing connected apps keep working, and you can request an exception through Salesforce Support if you truly need one.

What is the difference between JWT Bearer and Client Credentials flows?

Both are server-to-server flows with no user present. JWT Bearer authenticates with a signed certificate and has no shared secret to leak, while Client Credentials exchanges a consumer key and secret and runs as a designated integration user, which is simpler but relies on a bearer secret you must store and rotate carefully.

Should new integrations use Connected Apps or External Client Apps?

Default to external client apps for new external integrations. They support only the secure OAuth flows, work fully with the Metadata API for CI/CD, and are the path Salesforce now recommends. Reserve connected apps for Salesforce-native cases like canvas and mobile publishing.

Do Named Credentials replace OAuth flows?

No. Named Credentials manage outbound callout authentication and can use OAuth flows like JWT Bearer under the hood, keeping secrets out of Apex and Flow rather than replacing the flow itself.