“How do you authenticate?” is a deceptively open interview question. The right answer depends on who’s calling whom, whether a user is present, and how much you trust the client.
Direction matters
| Direction | Salesforce role | Auth lives in |
|---|---|---|
| Salesforce → External | Client | Named Credential + External Credential |
| External → Salesforce | Resource server | Connected App |
Inbound (external systems calling Salesforce)
| Strategy | When to use | Notes |
|---|---|---|
| OAuth Web Server flow | User-facing integration (Postman, Tableau, Power BI) | Most common. Stores a refresh token. |
| OAuth JWT Bearer flow | Server-to-server, no user (ETL, MuleSoft) | Signed JWT with private key, no secret on the wire. Modern default for headless integrations. |
| OAuth Client Credentials flow | Server-to-server, simple, no JWT support | Sends client_id + client_secret directly. Pick JWT if possible. |
| OAuth Device flow | CLIs, IoT devices | User authorizes on a different device. |
| SAML Bearer Assertion | SSO-integrated server-to-server | When the integration is already federated to your IdP. |
| Username-Password flow | Don’t. Legacy only. | Sends a password to Salesforce. Disabled by default in new orgs. |
| Session ID | Inside a Visualforce/LWC context calling back to Salesforce | Just getSessionId(); never expose externally. |
Outbound (Salesforce calling external systems)
Named Credentials hide the actual auth method behind one config record. Inside the Named Credential / External Credential setup:
- OAuth 2.0 — full flow handled by the platform, including refresh
- AWS Signature Version 4 — for direct calls to AWS services
- JWT — Salesforce signs the JWT and sends it
- Basic — username/password header (avoid in 2026 unless mandated)
- Custom Header — for APIs with bespoke auth (
X-API-Key: ...) - mTLS — client certificate authentication via a cert in Setup > Certificate and Key Management
Per-user vs per-org
External Credentials support Named Principal (one set of creds for the whole org) or Per-User Principal (each user authorizes separately). Pick per-user when the downstream system needs to know which Salesforce user is acting — like Google Calendar or DocuSign — and per-org for system accounts.
What interviewers expect you to know
- Don’t store secrets in Custom Settings. Named Credentials exist for a reason.
- Rotate the consumer secret periodically. Connected Apps support multiple secrets so you can rotate without downtime.
- Scopes are least-privilege.
apilets you query/DML.fullis rarely needed and triggers security review. - IP restrictions on Connected Apps catch leaked secrets. Set them when the integration runs from known IPs.
- Refresh token policies. “Refresh token is valid until revoked” is convenient and an exfiltration risk. Pick “Immediately expire” or a fixed window for sensitive scopes.
When mTLS makes sense
For payment processors, healthcare clearinghouses, and financial regulators, the API will often require mutual TLS. Salesforce supports this: upload a client cert to Certificate and Key Management, reference it from the Named Credential, the platform presents the cert during the TLS handshake.
Common interview follow-ups
- Username-password flow — why is it bad? — Sends a real password, defeats MFA, no per-user audit trail. Disabled by default in new orgs and being phased out.
- How does JWT Bearer flow avoid the secret problem? — The integration server signs the JWT with a private key Salesforce never sees; Salesforce verifies with the public key. The “secret” is one-way.
- Can a Connected App enforce MFA? — Yes, via “High Assurance” session security policies tied to permission sets.
Verified against: Salesforce Help — Authenticate Apps with OAuth. Last reviewed 2026-05-17 for Spring ‘26 release.