Step‑by‑step guide to configure SAML 2.0 Single Sign‑On between Okta (IdP) and Salesforce (SP). Covers My Domain, certificate creation, Okta app setup, user mapping, and troubleshooting tips.
Why SSO between Okta and Salesforce matters
Single Sign‑On reduces password fatigue, centralizes authentication, and improves security and compliance. Integrating Okta as an Identity Provider (IdP) with Salesforce as a Service Provider (SP) streamlines login, enables centralized user provisioning, and supports MFA and policy enforcement from Okta.
Prerequisites
- Okta business account (Admin access)
- Salesforce org with My Domain enabled
- Admin access to both Okta and Salesforce
Step‑by‑step configuration
1. Enable My Domain in Salesforce
Enable My Domain to create a unique Assertion Consumer Service (ACS) endpoint. SAML requires a distinct endpoint for Salesforce to receive assertions. After creating My Domain, note your custom domain (for ACS/Entity ID).
2. Configure Okta as the Identity Provider
In Okta Admin: Applications → Browse App Catalog → Add Integration → Search for Salesforce.com and choose SAML 2.0 as the sign‑in method. Configure general settings such as application label and instance type (Production or Sandbox).
3. Configure SAML Single Sign‑On in Salesforce
In Salesforce: Setup → Single Sign‑On Settings → New. Enter values from Okta’s “View Setup Instructions”:
- Issuer / Entity ID: use Okta-provided value (or use https://saml.salesforce.com for standard)
- SAML Identity Type: Assertion contains the Federation ID from the User object
- Identity Provider Certificate: upload certificate downloaded/created from Okta metadata
- Identity Provider Login URL: Okta SSO URL
4. Create signature certificate from Salesforce metadata (for Okta)
Download Salesforce metadata, copy the ds:X509Certificate value into a text file and wrap it with certificate headers:
-----BEGIN CERTIFICATE----- MIIF... (certificate base64 data) -----END CERTIFICATE-----
Save as slo.crt for upload to Okta.
5. Update Salesforce login details in Okta
In Okta Sign‑On settings for the Salesforce app, enter the Salesforce Login URL and Logout URL (from Salesforce Single Sign‑On settings / My Domain). Enable Single Logout and upload slo.crt.
6. Update Salesforce SSO configuration
Back in Salesforce Single Sign‑On Settings, enable Single Logout and paste Okta’s Single Logout URL. Save and verify the Sign‑On, Sign‑Out, and Issuer fields match Okta values.
7. Configure My Domain authentication
Setup → My Domain → Authentication Configuration → select the newly created Okta SSO authentication service so users see an Okta SSO option on the login screen.
8. Map users and provision
When using Federation ID as the SAML identity, update each Salesforce user’s Federation ID to match the Okta username. In Okta, assign users to the Salesforce app (Assignments tab) or import users in bulk via provisioning.
9. Test and troubleshoot
- Test login from Okta app and Salesforce My Domain login page
- Check SAML assertions for NameID and Federation ID mapping
- Use Salesforce and Okta logs to troubleshoot failures; see Salesforce Ben’s SSO troubleshooting guide for common errors
Best practices
- Use Federation ID mapping consistently across users
- Enable MFA in Okta to increase security for Salesforce access
- Document the SAML attributes and certificate rotation plan
- Test SSO in a sandbox before enabling in production
Conclusion
Setting up SSO between Okta and Salesforce improves user experience and security when done carefully. Follow the steps above, keep certificates and attributes in sync, and test thoroughly before rollout.
Why this matters: Admins gain centralized access controls, developers avoid building custom auth flows, and business users get faster, safer access to Salesforce.