Okta + Salesforce integration
Set up Okta as the identity provider for Salesforce via SAML + SCIM — with optional SCIM provisioning for automated user lifecycle.
- Okta admin access (or app-admin role)
- Salesforce administrator with permission to enable SSO + SCIM
- A Salesforce org with My Domain configured (required for SAML)
- A test user in both Okta + Salesforce for end-to-end verification
1. Create a new SAML 2.0 application in Okta
In the Okta admin console, create a new SAML 2.0 application. Choose "Web Application" type. Note the placeholders for ACS URL + Entity ID — you'll get these from Salesforce in step 3.
2. Get the SAML metadata URL from Okta
Okta exposes the IdP metadata at a stable URL. Copy this URL — you'll paste it into Salesforce's SSO configuration. Alternatively, download the metadata XML if Salesforce doesn't support URL-based metadata.
3. Configure SSO in Salesforce
In Salesforce's admin → security → SSO settings, paste the Okta metadata URL (or upload the XML). Salesforce will display the ACS URL + Entity ID it expects — copy these.
4. Return to Okta + complete the SAML app config
Paste Salesforce's ACS URL into the Okta app's Single Sign-On URL field. Paste the Entity ID into the Audience URI field. Set the NameID format to EmailAddress (or persistent if Salesforce expects that).
5. Configure attribute mapping
Map the attributes the SP expects (see the Attribute Mapping section below). At minimum, email is required. Most apps also expect firstName + lastName.
6. Assign users + groups
In Okta, assign the SAML app to users or groups that should have access. Test with a pilot group before broad rollout.
7. Test end-to-end
Sign in to Salesforce via the IdP-initiated link (from Okta dashboard) AND via SP-initiated (direct Salesforce login URL). Both should work. Check the SAML Tracer browser extension or SAML decoder to inspect the assertion if anything fails.
What flows from where.
| Source (Okta) | Target (Salesforce) | Note |
|---|---|---|
| user.email | NameID | EmailAddress format |
| user.email | Username (Federation ID) | Salesforce Federation ID must match |
| user.firstName | FirstName | — |
| user.lastName | LastName | — |
| user.title | Title | — |
| user.department | Department | — |
- Clock skew: Okta and Salesforce clocks must be within ~5 minutes. NTP-sync both. SAML's NotBefore + NotOnOrAfter are strict.
- NameID format mismatches are the most common failure. Salesforce typically wants EmailAddress; Okta defaults vary. Mismatch → cryptic "invalid assertion" errors.
- Just-in-time (JIT) provisioning vs SCIM: many apps support both. SAML JIT creates the user on first SSO; SCIM creates them ahead of time. Pick one — both can cause attribute drift.
- Audience restriction: Salesforce's expected Audience URI must match exactly what the IdP sends. Trailing slashes + protocol (http vs https) matter.
- Signed Response vs signed Assertion: many SPs require the Assertion to be signed (not just the Response envelope). Check the SP's docs.
- Salesforce Federation ID must exactly match the NameID — case-sensitive. A common failure is users whose email case differs.
- Salesforce profiles vs Okta groups: SSO authenticates the user, but Salesforce profile assignment is independent. Use SCIM (or a manual mapping) to keep them in sync.
- My Domain is required for SAML — if Salesforce reports "SSO not configured properly," the org likely doesn't have My Domain enabled.
- IdP-initiated SSO works (sign in from the IdP dashboard)
- SP-initiated SSO works (visit Salesforce directly + get redirected to IdP)
- User attributes flow through correctly (email, name, groups)
- Logout (single logout if supported) works as expected
- Step-up MFA fires when policy requires it
- Unauthorized users (not assigned to the app) get a clean denied message
- Capture a successful SAML response and inspect it (use the SAML decoder tool)
For the latest vendor-side configuration changes, refer to:
Okta Salesforce integration guide →