A practical step-by-step guide to configure SAML-based Single Sign-On (SSO) between Okta (IdP) and Salesforce (SP). Covers My Domain, Okta app setup, metadata/certificate exchange, user provisioning, and troubleshooting tips.
Overview
Single Sign-On (SSO) using SAML 2.0 lets users authenticate once with an Identity Provider (IdP) such as Okta and access Salesforce as the Service Provider (SP). This post explains the technical steps, configuration details, and best practices to implement a secure and reliable Okta–Salesforce SSO integration.
Prerequisites
- Okta admin access (a paid or trial business account)
- Salesforce org with My Domain enabled
- Admin access to both systems to create apps, upload certificates, and map users
Step-by-step configuration
- Enable My Domain in Salesforce — Create a My Domain to provide a unique Assertion Consumer Service (ACS) endpoint required by SAML.
- Configure Okta as Identity Provider — In Okta Admin: Applications > Browse App Catalog > Add Salesforce. Choose SAML 2.0 and open the setup instructions.
- Enable SAML in Salesforce — In Salesforce SSO settings, create a new SAML SSO configuration. Set Entity ID (https://saml.salesforce.com or your custom domain), SAML Identity Type (e.g., Federation ID), NameID format, and upload Identity Provider details from Okta.
- Exchange metadata and create certificate — Download Salesforce metadata, extract the ds:X509Certificate value, wrap with BEGIN/END lines and save as slo.crt. Use this in Okta when enabling Single Logout.
- Update Okta Sign-On configuration — Paste Salesforce Login and Logout URLs into Okta Advanced Sign-On settings, upload slo.crt, enable Single Logout if required, and save.
- Update Salesforce SSO settings — Enable Single Logout in the Salesforce SSO config and paste the IdP Single Logout URL from Okta.
- Set Okta as Authentication Service in My Domain — On Salesforce My Domain page, edit Authentication Configuration and add the new Okta SSO as an authentication service so it appears on the login page.
- Prepare users — Populate the Federation ID field in Salesforce user records with the corresponding Okta username (or chosen identifier) and assign users to the Okta application (Assignments tab).
- Test and demo — Perform sign-in tests, test Single Logout, and check SAML assertions. Use SAML trace and Salesforce/Okta logs for debugging.
Certificate file example
-----BEGIN CERTIFICATE----- MIIC+TCCAeGgAwIBAgIBADANBgkqhkiG9w0BAQsFADA... (truncated example) -----END CERTIFICATE-----
Troubleshooting tips
- Verify ACS, Entity ID and Audience values match exactly on both sides.
- Confirm the NameID (e.g. Federation ID) mapping is correct and populated for users.
- Check certificate validity, chain and enablement of Single Logout if used.
- Review Salesforce debug logs and Okta System Logs for SAML errors and assertion contents.
Best practices
- Use Federation ID as a stable unique identifier for cross-system mapping.
- Rotate certificates before expiry and test a fallback plan.
- Enable multi-factor authentication (MFA) from Okta for stronger security.
- Document the SSO configuration and keep metadata files in a secured repository.
Conclusion
Implementing SSO between Okta and Salesforce reduces password sprawl, strengthens security with centralized authentication, and simplifies user management. Follow the steps above, validate metadata and certificate exchanges carefully, and map users accurately to ensure a smooth rollout.
This guide is designed for Salesforce admins, identity architects, and integration engineers implementing SAML-based SSO. If you need hands-on help, consult Okta and Salesforce documentation or reach out to a certified consultant.