What different OAuth2.0 Authorization flows are available in Salesforce? | Salesforce OAuth flows

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 noticed there are a lot of Salesforce OAuth flows to choose from. The list is overwhelming the first time you see it. Picking the right one decides whether your data stays safe and whether your users have to log in again every five minutes.

I have seen plenty of teams struggle with this. They pick a flow because it looks easy to implement, then find out six months later that it doesn't support refresh tokens, or that it's a serious security risk. Here are the standard Salesforce OAuth flows and what each one is actually for.

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 recommend it for any traditional web app, mostly because it supports refresh tokens, so your app keeps working after the initial session expires. Setting up the redirect logic is more work, and it's worth it for the security and the long-lived sessions.

2. User-Agent Flow (Implicit Grant)

If you are building a single-page app (SPA) or a mobile app where you can't really hide a client secret, you'll probably look at the User-Agent flow. The access token comes back directly in the URL fragment. That's fast, and it's less secure, because the token is sitting right there in the browser history.

It also gives you no refresh token, which trips people up. Once the token expires, the user has to go through the flow again. If you're building a modern app, look at PKCE (Proof Key for Code Exchange) instead, which handles these "public" clients much better.

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 want the setup steps, 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.

4. Username-Password Flow

You should almost never use this one. It requires your app to handle the user's raw credentials, which is a security nightmare, and it breaks the second you turn on Multi-Factor Authentication (MFA). It's a relic from a different era. 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 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

A few things will keep you out of trouble when you set these Salesforce OAuth flows up.

• 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

1. Your app sends the user to the Salesforce login page with your client ID and redirect URI.
2. The user logs in and says "Yes, I allow this app to access my data."
3. Salesforce sends the user back to your site with a "code" parameter in the URL.
4. Your server takes that code and sends it back to Salesforce, along with your client secret, to get the real access token.
5. 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.

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 you're messing with security policies.