A Connected App is the Salesforce-side definition of an external application that wants to talk to your org. It holds the OAuth client credentials, scopes, callback URL, and security policies that govern how that external app authenticates and what it’s allowed to do.
If a Named Credential is how Salesforce calls out, a Connected App is how external systems call in.
What it actually configures
Creating a Connected App in Setup > App Manager > New Connected App generates two key values:
- Consumer Key (a.k.a.
client_id) — public identifier for the app - Consumer Secret (a.k.a.
client_secret) — the password the app proves it knows
Plus a bunch of settings:
- Callback URL — where Salesforce redirects after OAuth login
- Selected OAuth Scopes —
api,refresh_token,chatter_api,full,offline_access, etc. - IP relaxation — should this app bypass IP login restrictions?
- Refresh token policy — how long refresh tokens stay valid
Two flavours of “Connected App”
| Type | Purpose |
|---|---|
| OAuth-enabled | Standard API access. Postman, MuleSoft, mobile apps, server-to-server jobs. |
| SAML / OpenID Connect | SSO. Salesforce acts as identity provider for external apps (Workday, Slack, etc.). |
A single Connected App record can do both — same metadata holds OAuth settings and SAML assertion configuration.
How an external app uses it
The classic Web Server flow:
- External app redirects user to
https://login.salesforce.com/services/oauth2/authorize?client_id=...&response_type=code&redirect_uri=... - User logs in to Salesforce, approves the requested scopes
- Salesforce redirects to the callback URL with
?code=... - External app POSTs the code + secret to
/services/oauth2/tokenand gets an access token - App calls
/services/data/v62.0/sobjects/AccountwithAuthorization: Bearer ...
Policies that often trip people up
- Permitted Users: “All users may self-authorize” vs “Admin approved users are pre-authorized.” For server-to-server, pick the admin-approved option and assign the app to specific profiles/permission sets — otherwise random users can grant access without anyone noticing.
- IP Restrictions: “Enforce IP restrictions” by default. For headless backends with rotating IPs, set “Relax IP restrictions for activations” or you’ll spend an afternoon debugging
invalid_grant. - Token Validity: Refresh tokens can be set to expire (1 day to 12 months) or last forever. Long-lived tokens are convenient and a security liability.
Common interview follow-ups
- Where does an external integration’s Salesforce auth live? — In a Connected App on the Salesforce side, and as a stored client_id/secret + refresh token on the external side.
- How do you rotate the consumer secret? — Setup > Manage Connected Apps > Edit > generate a new secret. Old secret remains valid until manually invalidated.
- Connected App vs Auth Provider? — Auth Providers handle Salesforce acting as a client against an external IdP (login with Google/Microsoft). Connected Apps handle Salesforce acting as the resource server being accessed.
Verified against: Salesforce Help — Connected Apps. Last reviewed 2026-05-17 for Spring ‘26 release.