First, Two Words People Constantly Mix Up
Before we get anywhere near flows, let’s clear up two terms that get used interchangeably and absolutely shouldn’t be.
Authentication is proving you are who you say you are. Logging in with a username, password and probably an MFA prompt. It answers “who are you?”
Authorization is being granted access to specific resources. It answers “what are you allowed to touch?”
In Salesforce terms: authentication is the login page. Authorization is your profile and permission sets deciding whether you can see the Account object. Two completely different jobs, and picking the right integration flow depends on knowing which one you’re solving.
Three Protocols
SAML and OpenID Connect both authenticate users. They’re what you use for single sign-on, and they’re functionally very similar.
Which should you pick? There’s no hard rule, but most new things are being built on OpenID Connect, because it’s built on top of OAuth 2.0, it’s JSON based rather than XML based, and it plays much better with mobile and single page apps. SAML is older, extremely well established, and still everywhere in enterprise. If you’re integrating with something that already speaks SAML, use SAML. If you’re starting fresh, OpenID Connect.
OAuth 2.0 is the odd one out and the one people misunderstand most. OAuth is an authorization protocol, not an authentication one. It’s about granting an application permission to access resources on your behalf, without handing over your password.
That distinction is why OpenID Connect exists at all: it’s a thin authentication layer sitting on top of OAuth, because people kept trying to use OAuth for login and getting it subtly wrong.
Most of what follows is OAuth flows, because that’s what you’ll be picking between for integrations.
The Flows You’ll Actually Choose Between
Web Server Flow
The classic. A user clicks “connect,” gets redirected to Salesforce to log in, approves the app, and Salesforce sends an authorization code back to your server, which swaps it for an access token behind the scenes.
Use it when: there’s a real human involved and your app has a secure server side to hold the client secret.
Don’t use it when: there’s no user, or you can’t keep a secret safe.
JWT Bearer Flow
My default recommendation for server to server integrations. No user, no browser, no interaction. Your system signs a JSON Web Token with a private key, Salesforce verifies it against the certificate on your Connected App, and hands back an access token.
Use it when: a backend system needs to talk to Salesforce on a schedule with no human present. Nightly data syncs, middleware, CI/CD pipelines.
Why it’s good: no password stored anywhere, no refresh token to expire and wake you up at 3am.
That last point is worth emphasising. If you’ve built an integration on the Username-Password flow and it dies whenever someone rotates the password, JWT is the fix.
Refresh Token Flow
Not really a standalone flow, more a companion. Access tokens expire; a refresh token lets you get a new one without dragging the user back through login.
Use it when: you’ve used the Web Server flow and need long-lived access.
Watch out for: refresh tokens can be revoked, and they do expire based on your Connected App’s session policies. Handle that failure properly rather than assuming it’ll work forever.
User Agent Flow
For apps that can’t keep a secret: JavaScript running in a browser, mobile apps. The access token comes straight back in the redirect.
Use it when: you genuinely have no secure backend.
Be aware: the token is exposed to the browser. This is the least secure of the bunch, and modern guidance increasingly favours the Web Server flow with PKCE instead.
Username-Password Flow
You send a username and password, you get a token.
Use it when: honestly, don’t. It exists mostly for legacy scenarios and quick testing. You’re storing credentials, there’s no MFA, and it breaks the moment somebody rotates a password. If you’re reaching for this, JWT Bearer almost certainly does the job better.
The Decision, Simplified
Almost every real decision comes down to two questions.
1. Is there a human involved?
No → JWT Bearer Flow.
Yes → keep going.
2. Can you securely store a client secret?
Yes → Web Server Flow (plus refresh tokens).
No → User Agent Flow, and think hard about whether you can restructure to avoid it.
That covers the overwhelming majority of integrations you’ll build.
Going The Other Way
Everything above is about getting into Salesforce. When Salesforce is calling out to somebody else, the tool you want is Named Credentials.
They let Salesforce handle the whole authentication dance for you, so your Apex doesn’t contain a single credential. I’ve written up how to use Named Credentials to simplify your integrations, and if you’re currently storing API keys in Custom Settings, go read that one next.
For cases Named Credentials can’t cover, I’ve also got a post on building custom authentication in Apex.
A Few Things That Will Save You Pain
Never put a certificate or private key in your repo. Add it to .gitignore before you generate it, not after.
Set your Connected App’s permitted users to “Admin approved users are pre-authorized.” The default lets any user self-authorize, which is rarely what you want for an integration.
Use an integration user, not a person. If your nightly sync runs as Dave, it stops working the day Dave leaves. Create a dedicated user with exactly the permissions the integration needs and nothing more.
Handle token expiry properly. Tokens expire, sessions get revoked, admins change policies. Assume it will fail and code for it.
Diagrams for each of these flows are up in my GitHub repo, and Salesforce’s OAuth flow documentation is genuinely good if you want the full detail on any one of them.
Get Coding With The Force Merch!!
We now have a redbubble store setup so you can buy cool Coding With The Force merchandise! Please check it out! Every purchase goes to supporting the blog and YouTube channel.
Get Shirts Here!
Get Cups, Artwork, Coffee Cups, Bags, Masks and more here!
Check Out More Coding With The Force Stuff!
If you liked this post make sure to follow us on all our social media outlets to stay as up to date as possible with everything!
Youtube
Patreon
Github
Facebook
Twitter
Instagram
Salesforce Development Books I Recommend
Advanced Apex Programming
Salesforce Lightning Platform Enterprise Architecture
Mastering Salesforce DevOps
Good Non-SF Specific Development Books:
Clean Code
Clean Architecture
