Okta SSO Setup with Salesforce | SAML 2.0 Complete Lab

Okta SSO Setup with Salesforce is one of the most common—and most critical—identity projects for any organization using Salesforce CRM. This complete lab walks you through every step of configuring SAML 2.0–based Single Sign‑On between Okta (Identity Provider) and Salesforce (Service Provider). Whether you are an IAM architect, a Salesforce admin, or a DevOps engineer, this guide gives you a production‑ready Okta SSO Setup with Salesforce that you can deploy with confidence.

We cover prerequisites, My Domain enablement, Okta app creation, SAML metadata exchange, certificate handling, user mapping via Federation ID, SP‑initiated and IdP‑initiated flows, Single Logout, testing, and a full troubleshooting section. By the end of this lab, you will have a robust Okta SSO Setup with Salesforce that reduces password fatigue, strengthens security, and simplifies user access.

1. Prerequisites for Okta SSO Setup with Salesforce

Before you start your Okta SSO Setup with Salesforce, ensure you have the following:

• Okta admin access – a paid or trial business account with permissions to create applications and manage authentication policies[reference:0].
• Salesforce org – any edition that supports My Domain (required).
• My Domain enabled in Salesforce – this provides a unique Assertion Consumer Service (ACS) endpoint[reference:1].
• Admin access to both systems to create apps, upload certificates, and map users[reference:2].
• Federation ID field populated in Salesforce user records (or a plan to map users via email/username).

Many admins rush into the Okta SSO Setup with Salesforce without enabling My Domain first—and then wonder why the ACS URL is missing. Do not skip this step.

2. Enable My Domain in Salesforce

Salesforce requires a custom My Domain to expose a unique SAML endpoint. Without it, your Okta SSO Setup with Salesforce will fail because Okta cannot determine where to send the SAML assertion.

1. Log in to Salesforce as an admin.
2. Go to Setup → Company Settings → My Domain.
3. Choose a domain name (e.g., acme) and register it.
4. Deploy the domain to make it active.

Once My Domain is active, your login URL will look like https://acme.my.salesforce.com. This URL becomes the foundation of your Okta SSO Setup with Salesforce.

3. Create the Okta Application for Salesforce

Now we move to the Okta side. The fastest way to achieve a correct Okta SSO Setup with Salesforce is to use Okta’s pre‑built connector.

1. Log in to your Okta Admin Console.
2. Navigate to Applications → Applications → Browse App Catalog.
3. Search for “Salesforce.com” and add the integration[reference:3].
4. Choose SAML 2.0 as the sign‑on method[reference:4].
5. Click View Setup Instructions – this opens a page with the exact Issuer, Login URL, and Certificate that you will need in Salesforce[reference:5].

4. Configure SAML Settings in Salesforce

This is the core of the Okta SSO Setup with Salesforce. In Salesforce, you create a new SAML Single Sign‑On configuration.

1. In Salesforce, go to Setup → Identity → Single Sign‑On Settings (or Security Controls → Single Sign‑On Settings in Classic)[reference:7].
2. Click Edit and check SAML Enabled, then save[reference:8].
3. Click New to create a new SAML configuration.
4. Fill in the following fields (values come from Okta’s View Setup Instructions):

• Name: e.g., “Okta SSO”
• SAML Version: 2.0
• Issuer: copy from Okta setup instructions[reference:9].
• Identity Provider Certificate: download the certificate from Okta and upload it[reference:10].
• Identity Provider Login URL: copy from Okta[reference:11].
• Entity ID: use your My Domain URL: https://[yourdomain].my.salesforce.com (or https://saml.salesforce.com if you don’t have a custom domain)[reference:12].
• SAML Identity Type: select Assertion contains the Federation ID from the User object – this is the cleanest approach[reference:13].
• SAML Identity Location: Identity is in the NameIdentifier element of the Subject Statement[reference:14].

After saving, Salesforce generates a Login URL. Copy it – you will paste it back into Okta.

5. Complete the Okta Sign‑On Configuration

Now we wire the two sides together to finalize the Okta SSO Setup with Salesforce.

1. Go back to your Okta Salesforce app.
2. Click the Sign On tab and click Edit.
3. Paste the Salesforce Login URL you copied into the Login URL field[reference:15].
4. If you have a custom Salesforce domain, enter the subdomain (e.g., acme) in the Custom Salesforce domain field; otherwise leave blank[reference:16].
5. Set Use Fed ID for SAML to YES if you are using Federation ID mapping[reference:17].
6. Click Save.

6. Map Users via Federation ID

SSO will not work if Salesforce cannot identify the Okta user. In a correct Okta SSO Setup with Salesforce, user mapping is done via the Federation ID field.

1. In Salesforce, open any User record.
2. Find the Federation ID field (under Single Sign‑On or Identity section).
3. Set this value to the same identifier that Okta sends in the SAML assertion (usually the Okta username or email).
4. In Okta, ensure the Application username format matches the Federation ID value you are using[reference:19].

If you have many users, use Okta’s Profile Editor to map an Okta attribute (like email) to the Salesforce Federation ID[reference:20].

7. Set Okta as Default Authentication Service

To make the Okta SSO Setup with Salesforce active, you must add Okta as an authentication service in Salesforce My Domain.

1. In Salesforce, go to Setup → Company Settings → My Domain.
2. Under Authentication Configuration, click Edit.
3. Check the box for your new Okta SSO provider[reference:21].
4. Choose Okta as the Default Authentication Service if you want users to be redirected to Okta by default.
5. Save.

Now the login page will show an Okta SSO button (or redirect automatically, depending on your settings).

8. Test Your Okta–Salesforce SSO

Testing is a non‑negotiable part of any Okta SSO Setup with Salesforce. Here is a simple test plan:

• IdP‑initiated flow: Log in to the Okta dashboard, click the Salesforce app tile. You should be redirected to Salesforce and logged in automatically.
• SP‑initiated flow: Go directly to your Salesforce My Domain URL (https://acme.my.salesforce.com). You should be redirected to Okta, authenticate, and then return to Salesforce.
• Check the SAML assertion using a browser extension like SAML Tracer to verify that the NameID, Federation ID, and Audience are correct[reference:22].
• Test Single Logout (SLO) if you have configured it – logging out of Okta should also log you out of Salesforce.

9. Single Logout (SLO) Configuration

For a complete Okta SSO Setup with Salesforce, consider enabling Single Logout so that users are signed out of both systems simultaneously.

1. In Okta, go to the Salesforce app Sign On tab.
2. In the Advanced Sign‑On Settings, paste the Salesforce Logout URL (obtained from Salesforce SSO settings).
3. Upload the Salesforce certificate (download Salesforce metadata, extract the ds:X509Certificate, wrap it with -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----, and save as .crt)[reference:23].
4. Enable Single Logout and save.
5. In Salesforce, edit the SAML SSO configuration and paste the IdP Single Logout URL from Okta[reference:24].

10. Troubleshooting Common Issues

Even with a careful Okta SSO Setup with Salesforce, things can go wrong. Here are the most common pitfalls and how to fix them.

10.1 “Audience in the assertion did not match”

This is the #1 error. The Entity ID in Salesforce must match exactly what Okta sends. Check case sensitivity and ensure you are using the production URL, not the sandbox URL[reference:25]. For sandboxes, use the production My Domain URL (e.g., https://acme.my.salesforce.com) not the sandbox‑specific one[reference:26].

10.2 Users are not found

If users authenticate in Okta but get a “user not found” error in Salesforce, the Federation ID mapping is likely broken. Verify that the Federation ID in Salesforce matches the value Okta sends in the SAML assertion[reference:27].

10.3 Certificate errors

If Salesforce rejects the certificate, ensure you uploaded the correct Identity Provider Certificate from Okta. Sometimes the certificate needs to be manually wrapped with BEGIN CERTIFICATE and END CERTIFICATE lines[reference:28].

10.4 SCIM provisioning issues

If you are using SCIM for automated provisioning and see an about:blank popup, check your Salesforce sandbox environment – Developer Edition orgs have known compatibility issues with Okta SCIM provisioning[reference:29].

11. Best Practices for Production Okta SSO Setup with Salesforce

• Always test in a sandbox first. I have seen too many admins lock themselves out of production because they did not test their Okta SSO Setup with Salesforce properly[reference:30].
• Use Federation ID as a stable unique identifier – it is much cleaner than using usernames, especially when usernames do not match exactly between systems[reference:31].
• Rotate certificates before they expire and have a fallback plan[reference:32].
• Enable MFA from Okta for stronger security[reference:33].
• Document everything – keep metadata files and configuration details in a secured repository[reference:34].

12. Beyond SSO – SCIM Provisioning and Lifecycle Management

Once your Okta SSO Setup with Salesforce is stable, consider adding SCIM provisioning to automate user lifecycle management. With SCIM, when someone joins, Okta creates their Salesforce account automatically. When they move departments or leave, access is updated or removed automatically[reference:35]. This turns your SSO integration into a full identity governance solution.

13. Additional Learning Resources

Deepen your knowledge with these external Okta learning documents:

• Okta Authenticators – official documentation
• Okta Policies – official guide
• Okta SAML developer documentation
• Salesforce SAML SSO documentation

Also revisit our internal articles: Okta HealthInsight Authenticators and Okta Interview Questions.

---

📋 10 Frequently Asked Questions (FAQ) about Okta SSO Setup with Salesforce

---

Final Words

Implementing a robust Okta SSO Setup with Salesforce reduces password sprawl, strengthens security with centralized authentication, and simplifies user management[reference:47]. Follow the steps above, validate metadata and certificate exchanges carefully, and map users accurately to ensure a smooth rollout. With this complete lab, you now have everything you need to deploy Okta–Salesforce SSO in production.

For ongoing learning, bookmark the CloudKnowledge Okta tag and revisit our Okta HealthInsight and Okta Interview Questions articles.

© 2026 CloudKnowledge — Complete Lab for Okta SSO Setup with Salesforce | SAML 2.0