The types of OAuth flows in Salesforce are something almost every Salesforce professional runs into sooner or later. You see it while setting up an integration, connecting middleware, building automation, or onboarding a third-party tool. Most people follow the steps and move on. Very few stop to understand what’s really happening.
That gap matters. Configured properly, OAuth quietly protects your org. Configured poorly, it becomes a long-term security risk that nobody notices until something breaks or access leaks.
This blog explains OAuth in Salesforce without overcomplicating it. First, what OAuth actually does. Then, a practical look at the different OAuth flows, when they’re useful, and when they should be avoided.
What does OAuth mean in Salesforce?
OAuth is how Salesforce lets external applications access data without sharing usernames or passwords.
Instead of credentials, Salesforce issues an access token. That token represents permission. It limits what the app can do, which APIs it can call, and how long access lasts.
If access needs to be removed, Salesforce simply revokes the token. No password changes. No user impact. That alone makes OAuth far safer than older integration methods.
Authentication vs. Authorisation
These two concepts are often confused, but they solve different problems. Authentication answers one simple question: Who is the user? Authorization answers another: what is this application allowed to access? OAuth is focused on authorization. It doesn’t replace login. Instead, it controls what an application can do after the user’s identity has already been verified.
How OAuth Works in a Salesforce Integration?
Every OAuth flow may look different on the surface, but the core process is straightforward. An application requests access, Salesforce validates the request and the user’s approval, and then Salesforce issues a token. That token is included with every API call to prove the application is allowed to access the data.
Salesforce both issues the token and guards the data behind it. The token is the key, and Salesforce decides how long it stays valid.
Why Connected Apps Matter?
Almost every OAuth setup in Salesforce depends on a connected app. The connected app defines scopes, approval rules, token policies, and access controls. From an admin’s perspective, this is where visibility and control live.
If something looks suspicious, access can be revoked instantly without touching integration code. That’s why connected apps are a governance tool, not just a setup step.
Note – Starting with the Spring ’26 release, Salesforce is disabling the ability for customers to create connected apps directly. Going forward, new connected apps can be created through package installations, and customers who still need to create their own connected apps can request access by reaching out to Salesforce Support.
OAuth Flows (Practical View)
Web Server Flow
This is the default choice for most serious web applications. It’s built for apps with a backend server that can store secrets securely. The user approves access, and the server exchanges an authorization code for a token.
Used for
- Customer and partner portals
- Backend-driven web apps
Security: High
Client secrets stay on the server, and refresh tokens are supported.
User-Agent Flow
This exists for browser-only applications. Because secrets can’t be protected in the browser, the access token is returned directly to the app after approval.
Used for
- Single-page apps
- Browser tools
Security: Medium to low
Tokens live in the browser. Salesforce discourages this flow for new builds.
Refresh Token Flow
This isn’t a standalone option. It supports other flows. Access tokens expire by design. Refresh tokens let apps get new access without asking users to log in again.
Used for
- Long-running apps
- Background jobs
Security: Depends on storage
If refresh tokens leak, access leaks.
JWT Bearer Flow
This is built for server-to-server communication with no user involved. The app signs a JWT using a certificate. Salesforce validates it and issues a token.
Used for
- Middleware
- Scheduled jobs
- Batch processing
Security: High
No passwords. No refresh tokens. Certificate-based trust.
Client Credentials Flow
Here, the application authenticates as itself, not as a user. Access usually runs under a tightly controlled integration user.
Used for
- Microservices
- Internal system calls
Security: High
Designed around least-privilege access.
Token Exchange Flow
In larger identity setups, Salesforce often trusts another identity provider. This flow allows an existing token to be exchanged for a Salesforce token instead of forcing another login.
Used for
- Enterprise SSO
- Distributed architectures
Security: High
Trust depends on the upstream identity provider.
Device Flow
Some devices can’t show a login screen at all. The device displays a short code. The user approves access from another device.
Used for
- CLI tools
- Smart devices
- IoT
Security: Medium
Approval still happens, just not on the device itself.
SAML Bearer Assertion Flow
This fits orgs already using SAML-based SSO. A signed SAML assertion is exchanged for an OAuth token, avoiding an extra login.
Used for
- Enterprise SSO
- Federated identity
Security: High
Trust is enforced through signed assertions.
Username–Password Flow
This flow trades a username and password directly for a token. It works, but it’s risky. Credentials are exposed, and control is limited. Salesforce disables it by default in newer orgs.
Security: Low
Use only when legacy systems leave no other option.
Asset Token Flow
This flow is designed for connected devices tracked as Salesforce Assets. Devices authenticate securely and link activity directly to asset records.
Used for
- Service Cloud
- Connected equipment
- Monitoring systems
Security: High
Built for large-scale device authentication.
Blocking Risky OAuth Flows
Salesforce lets admins block weaker OAuth flows entirely. Disabling flows like User-Agent or Username–Password reduces risk and enforces modern security standards across the org.
Also Read – Salesforce Spring ’26 Release Updates For Admins
FAQs
1. Is OAuth just another login method?
No. Login confirms identity. OAuth controls access after that.
2. Do Salesforce integrations always need OAuth?
Yes. Any external API access should use OAuth. Password-based integrations are a liability.
3. Which OAuth flow suits most web apps?
Web Server Flow. It’s secure, flexible, and supports refresh tokens.
4. Why is User-Agent considered unsafe?
Because tokens live in the browser. If they leak, Salesforce access leaks too.
Conclusion
OAuth isn’t something you set once and forget. It sits quietly behind every integration and decides how much trust your Salesforce org is really extending. The right flow depends on context. User-facing apps need consent and visibility. System-to-system integrations should avoid passwords completely. Devices and background jobs need approaches that fit their limits without cutting corners on security.
If there’s one key takeaway, it’s this: don’t pick an OAuth flow just because it’s easy to set up. Choose one that truly fits how your integration works in the real world. That’s what keeps your security strong over time.”
