Salesforce Connected Apps and Single Sign-On (SSO) are the primary mechanisms for integrating Salesforce with external applications and centralising authentication. Connected Apps allow external systems to authenticate to Salesforce using OAuth 2.0, enabling API access, mobile app integrations, and the “Login with Salesforce” pattern. SSO allows users to log into Salesforce using their corporate identity provider (Okta, Azure AD, Google Workspace) rather than a Salesforce-specific username and password. This guide explains both features and how to configure them for common integration scenarios.
Done well, the configuration keeps security policy and user experience moving in the same direction.
The goal is not just login convenience. It is controlled access that still feels simple for the user.
A clean configuration also makes it easier to manage connected systems over time.
For larger teams, that balance matters because access rules affect both security and adoption.
If the configuration is wrong, the setup can become either too open or too restrictive.
The practical benefit is that administrators can centralise access while still giving users a smoother sign-in experience.
That makes them especially important for organisations that care about both security and day-to-day usability.
Salesforce connected apps and SSO configuration are useful when teams want secure access across multiple systems without making users log in repeatedly. They help Salesforce fit into a wider identity and access setup.
Connected Apps: The OAuth Gateway for Salesforce
A Connected App in Salesforce is an application framework that enables external applications to integrate with Salesforce using APIs and OAuth 2.0. Any external application that needs to access Salesforce data via API – a custom web application, a mobile app, a third-party integration tool, or a developer’s Salesforce CLI – must be registered as a Connected App in the Salesforce org.
What a Connected App Provides
- OAuth Consumer Key and Secret: credentials the external application uses to initiate the OAuth authentication flow with Salesforce
- Callback URL: the URL Salesforce redirects to after successful authentication – the external application receives the access token at this URL
- OAuth Scopes: the permissions granted to the external app – which Salesforce APIs it can call (api, web, full, refresh_token, chatter_api, custom_permissions)
- IP Restrictions: optionally restrict which IP addresses can use the Connected App
- Permitted Users and Policies: control which Salesforce users can authorise the Connected App (all users, pre-authorised users, or admin-approved users)
Creating a Connected App: Step-by-Step
- Go to Setup ? App Manager ? New Connected App
- Fill in the Basic Information: Connected App Name, API Name, Contact Email
- Check Enable OAuth Settings
- Enter the Callback URL – the URL of the external application that will receive the OAuth token (e.g.,
https://myapp.example.com/oauth/callback). For development,https://localhost:8080/oauth/callbackis common. - Select the required OAuth Scopes: at minimum, “Access the identity URL service (id, profile, email, address, phone)” and “Manage user data via APIs (api)” for standard API access
- Save – Salesforce generates the Consumer Key (the OAuth client_id) and the Consumer Secret (the OAuth client_secret)
- Copy and securely store the Consumer Key and Consumer Secret – these are used by the external application to authenticate
OAuth 2.0 Flows Supported by Salesforce
Salesforce supports multiple OAuth 2.0 grant types, each appropriate for different integration scenarios:
- Web Server Flow (Authorization Code): the user-facing flow where a browser user logs into Salesforce and authorises the external app. Used for web applications where a user explicitly grants access. Steps: external app redirects user to Salesforce login ? user authenticates ? Salesforce redirects back to Callback URL with an authorisation code ? external app exchanges code for access and refresh tokens.
- Username-Password Flow: the external application sends Salesforce credentials (username, password + security token) directly to the Salesforce token endpoint to obtain an access token. Used for server-to-server integrations where no user interaction is possible. Less secure than the Web Server Flow – avoid in production if alternatives exist, as it requires storing user credentials in the application.
- JWT Bearer Token Flow: the application authenticates using a JSON Web Token signed with a private key (corresponding to a certificate registered in the Connected App). No user interaction required – the application presents its JWT and receives an access token. This is the most secure server-to-server flow and is the recommended approach for integrations like MuleSoft or middleware connecting to Salesforce.
- Client Credentials Flow: available in newer Salesforce API versions – a server-to-server flow using the Consumer Key and Secret without user credentials. Used for integration applications that act on behalf of the system rather than any individual user.
Single Sign-On (SSO): Centralising Authentication
Salesforce SSO allows users to log in to Salesforce using their corporate identity provider (IdP) credentials – the same username and password they use for email, Google Workspace, Office 365, or other corporate applications. Users do not maintain a separate Salesforce password; authentication is delegated entirely to the IdP.
SSO Benefits
- Reduced password fatigue – one set of credentials for all corporate applications
- Centralised access control – revoking access in the IdP (disabling an employee in Azure AD) immediately blocks their Salesforce access
- Enforced MFA at the IdP level – corporate MFA policies (Duo, Microsoft Authenticator, Google Authenticator) apply to Salesforce access without separate Salesforce MFA configuration
- Compliance alignment – user access auditing happens at the IdP, providing a single audit trail for all corporate application access
SSO Protocols: SAML vs OpenID Connect
Salesforce supports two SSO protocols:
- SAML 2.0: the older, XML-based standard. Widely supported by enterprise IdPs (Okta, Azure AD SAML, PingFederate). Salesforce can act as the Service Provider (SP-initiated SSO) or the Identity Provider can initiate the login (IdP-initiated SSO).
- OpenID Connect (OIDC): the newer, OAuth 2.0-based identity standard. Used with modern IdPs and social login providers. Salesforce can act as a Relying Party (OIDC SP equivalent). OIDC is simpler to configure than SAML for integrations with modern IdPs.
Configuring SAML SSO with Okta (Common Example)
- In Salesforce: Setup ? Identity ? Single Sign-On Settings ? New SAML
- Enter the SAML Identity Type (Assertion contains User’s Salesforce Username, or a federated ID)
- Download the Salesforce Service Provider Metadata XML (or note the ACS URL and Entity ID)
- In Okta: create a new SAML 2.0 application, provide Salesforce’s ACS URL and Entity ID from step 3, configure Attribute Statements to map Okta user attributes to Salesforce user attributes (username, email, etc.)
- Download the Okta IdP Metadata XML
- Back in Salesforce: upload the Okta IdP Metadata XML – this configures the SAML Identity Provider settings (Issuer, Login URL, Certificate)
- Set Salesforce domain: SSO requires My Domain to be configured on the Salesforce org (Setup ? My Domain). SSO login flows through the My Domain URL.
- Assign the Okta SAML application to Salesforce users/groups in Okta
- Test SSO login using the IdP-initiated flow from Okta or the SP-initiated flow from the Salesforce My Domain login page
Session Security and Token Management
After a user authenticates (via username/password or SSO), Salesforce issues a session token that persists for the session. Session security settings (in Setup ? Session Settings) control session duration, IP restrictions, login hours, and the security level of activities that require step-up authentication. For Connected Apps, the OAuth access token has a configurable expiry (typically 2 hours) and the refresh token allows the external application to obtain a new access token without user re-authentication – until the refresh token expires or is revoked.
Monitoring Connected App Access
Salesforce Shield’s Event Monitoring logs all OAuth token grants, API calls made with access tokens, and Connected App authorisations – providing an audit trail for which external applications are accessing Salesforce data and with what permissions. Without Shield, basic OAuth audit data is available in Setup ? Connected Apps ? OAuth Usage.
Salesforce Connected Apps and SSO: Security and Governance Best Practices
What is a Salesforce Connected App?
A Connected App is a framework that enables external applications to integrate with Salesforce using APIs, OAuth, SAML, or OpenID Connect. It controls what data the external app can access and how users authenticate.
What is the difference between SAML SSO and OAuth in Salesforce?
SAML SSO is for user authentication into the Salesforce UI – employees logging into Salesforce via your company identity provider. OAuth is for application-to-application API access – an external app requesting data from Salesforce on behalf of a user.
Is Salesforce SSO free?
Salesforce supports SAML-based SSO at all edition levels including Essentials. Integration with a third-party IdP (Okta, Azure AD, Ping) may require licensed IdP seats depending on your provider.
Can you use Salesforce as an identity provider?
Yes. Salesforce can act as an IdP for other applications using SAML or OpenID Connect. This is called Salesforce Identity, available as a separate license add-on.
What should be in a Salesforce Connected App review?
Review: which users can authorize the app, what scopes (permissions) are granted, when the app was last authorized, whether it uses IP restrictions, and whether the external vendor is still active and contractually authorized to access your data.
Problem: Unreviewed Third-Party Connected Apps with Excessive Permissions
Connected apps granted full API access create security exposure if the third-party vendor is compromised or the integration is abandoned. Fix: Run a quarterly connected app audit. Navigate to Setup > Connected Apps > Manage Connected Apps. Revoke access for any app not actively used. Change all connected apps from “All Users May Self-Authorize” to “Admin-Approved Users Only” with explicit permission set assignments.
Problem: SSO Configuration Breaking When Identity Provider Certificates Rotate
IdP certificate rotation is a routine security practice, but it breaks Salesforce SSO silently until users report login failures. Fix: Track IdP certificate expiry dates in your calendar. Download and upload the new IdP certificate to Salesforce SAML Single Sign-On Settings at least one week before expiry. Test SSO with a non-admin test user after each certificate update before declaring success.
Problem: SSO Rollout Locking Out Admins Who Cannot Log In
Enabling SSO for all profiles can accidentally prevent Salesforce admins from logging in if the IdP is unreachable. Fix: Never apply SSO to the System Administrator profile during initial rollout. Keep one admin account with Salesforce credentials as a break-glass account. Roll SSO out to non-admin profiles first, validate for 2 weeks, then evaluate whether admin SSO is needed.
The best connected-app setup is the one that makes access predictable. If the trust model is unclear, the integration becomes harder to manage.