Selecting the right Salesforce OAuth flows for your project
If you have ever spent more than five minutes in the Connected App settings, you’ve probably noticed there are a lot of Salesforce OAuth flows to choose from. It can be a bit overwhelming at first. But here is the thing: picking the right one isn’t just about making the code work, it is about keeping your data safe and making sure your users don’t have to log in every five minutes.
I have seen plenty of teams struggle with this. They’ll pick a flow because it looks easy to implement, only to realize six months later that it doesn’t support refresh tokens or it’s a massive security risk. Let’s break down the standard Salesforce OAuth flows so you can stop guessing and start building.
1. Authorization Code Grant (Web Server Flow)
This is the gold standard for web applications that have a backend server. If you can securely store a client secret on your server, this is the one you want. The user gets redirected to Salesforce, logs in, and Salesforce sends back a temporary code. Your server then swaps that code for an access token.
I usually recommend this for any traditional web app. Why? Because it supports refresh tokens, which means your app can keep working even after the initial session expires. It is a bit more work to set up the redirect logic, but it’s worth it for the security and the long-lived sessions.
2. User-Agent Flow (Implicit Grant)
Now, if you are building a single-page app (SPA) or a mobile app where you can’t really hide a client secret, you’ll likely look at the User-Agent flow. In this scenario, the access token is passed back directly in the URL fragment. It’s fast, but it’s also less secure because that token is sitting right there in the browser history.
One thing that trips people up: this flow doesn’t give you a refresh token. Once the token expires, the user has to go through the flow again. If you’re building a modern app, you might want to look into PKCE (Proof Key for Code Exchange) instead, which is a much better way to handle these types of “public” clients.
3. JWT Bearer Token Flow
This is my personal favorite for server-to-server integrations. If you have a backend process that needs to talk to Salesforce without any human ever clicking a “Grant” button, this is your winner. You’ll use a digital certificate to sign a request, and Salesforce trusts it because you’ve pre-authorized the app. If you need a deep dive on the setup, check out this guide on the Salesforce JWT flow.
It is perfect for ETL jobs or automated reports. Just remember that you have to manage that certificate. If it expires, your integration breaks. I’ve been on the receiving end of a 2:00 AM support call because a certificate expired and no one noticed. Don’t be that person.
4. Username-Password Flow
Look, I’m going to be honest: you should almost never use this. This flow requires your app to actually handle the user’s raw credentials. It’s a relic from a different era. Not only is it a security nightmare, but it also breaks the second you turn on Multi-Factor Authentication (MFA). If you’re planning a Salesforce API integration, please look at JWT or Authorization Code instead.
Practical Tip: If a vendor tells you their integration only supports the Username-Password flow, that is a huge red flag. It usually means their tech stack is outdated and won’t play nice with modern security policies.
5. Device Flow
This one is a bit niche but very cool. Think about apps on a smart TV or a CLI tool where typing a password is a pain. The device shows a code, you go to a URL on your phone or laptop to authorize it, and then the device gets the token. It’s a great user experience for input-constrained devices.
Key security tips for Salesforce OAuth flows
When you are setting up these various Salesforce OAuth flows, you need to keep a few things in mind to stay out of trouble. It’s not just about getting the “200 OK” response; it’s about doing it the right way.
- Least Privilege: Only request the scopes you actually need. If you just need to read data, don’t ask for “full” access.
- IP Relaxation: In the Connected App settings, you can restrict access to specific IP ranges. This is a huge win for server-to-server flows.
- Refresh Token Policies: Decide how long you want those tokens to last. Sometimes “until revoked” is fine, but for high-security orgs, you might want them to expire after a few hours of inactivity.
- Rotate Secrets: If you’re using a client secret, treat it like a password. If you think it’s been leaked, rotate it immediately.
Example: How the Auth Code Flow actually looks
- Your app sends the user to the Salesforce login page with your client ID and redirect URI.
- The user logs in and says “Yes, I allow this app to access my data.”
- Salesforce sends the user back to your site with a “code” parameter in the URL.
- Your server takes that code and sends it back to Salesforce (along with your client secret) to get the real access token.
- You store that token and use it for your API calls.
Key Takeaways
- Use Authorization Code for web apps where you have a secure backend.
- Use JWT Bearer for any automated, server-to-server processes.
- Avoid Username-Password like the plague; it’s bad for security and MFA.
- Always use Refresh Tokens if you need your app to stay connected without constant user logins.
- Keep your scopes tight – don’t give “Full” access if you only need “API” access.
So, which one should you pick? If there’s a human involved and you have a server, go with Authorization Code. If it’s a machine talking to a machine, go with JWT. Everything else is pretty much for edge cases. Just make sure you’re testing these Salesforce OAuth flows in a sandbox first so you don’t accidentally lock yourself out of production while messing with security policies.