Salesforce OAuth Flows: Choosing the Right Authentication Design

How do you choose the right Salesforce OAuth flow? Use the Web Server Flow with PKCE when a human logs in through a browser, use the JWT Bearer Flow when a server talks to Salesforce with no user in the loop, and never fall back to a hardcoded username and password because it is faster to wire up. Get this 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. Use PKCE instead of the OAuth Device Flow, which Salesforce has restricted because it can be initiated with nothing 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, use the JWT Bearer Flow. It authenticates with a digitally signed certificate instead of a client secret, which is harder to leak by accident and easy to rotate.

When should you use JWT Bearer instead of the web server flow?

JWT Bearer fits whenever there is no browser and no session to redirect: scheduled integrations, CI/CD pipelines, and backend services calling the REST or Bulk API on a timer. Because the certificate authenticates the app itself, there is no refresh token to renew. JWT Bearer typically runs as a specific integration user, so scope its profile and permission sets tightly instead of granting broad admin access for convenience.

Connected Apps vs External Client Apps: what's the difference?

Salesforce has been splitting the classic Connected App into two purpose-built app types. Connected Apps remain right for Salesforce-native use cases like mobile publishing, canvas apps, and Salesforce-to-Salesforce connections. 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.

The practical difference in an architecture review: External Client Apps separate "who built this app" from "what can it do," with policy management independent of the app registration. Default to an External Client App for new integrations rather than reaching for a legacy Connected App out of habit.

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. If a secret needs to be rotated, you rotate it in one place instead of hunting through Apex classes and Flow definitions.

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. 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 Web Server Flow with PKCE or JWT Bearer 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.

This is the kind of work our architecture consulting team handles regularly. If your org still runs password-based integrations, our integration practice can map the migration path before it becomes a forced deadline. Get in touch to talk through your setup.

FAQ

Is PKCE required for every Salesforce OAuth flow?

No, but Salesforce recommends it for any Authorization Code Flow, and it is the direct replacement for the deprecated Device Flow.

What is the main difference between JWT Bearer and username-password authentication?

JWT Bearer authenticates with a signed certificate that can be rotated without redeploying code, while username-password authentication ties access to a credential that is easy to leak and hard to rotate cleanly.

Should new integrations use Connected Apps or External Client Apps?

Default to External Client Apps for new external integrations, and reserve Connected Apps for Salesforce-native use 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.