Okta + Zendesk integration
Set up Okta as the identity provider for Zendesk via OIDC + SCIM — using Zendesk's OIDC + SCIM endpoints (Enterprise plan).
- Okta admin role
- Zendesk Enterprise plan (for SCIM)
- Zendesk admin role
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 Zendesk 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 Zendesk's SSO configuration. Alternatively, download the metadata XML if Zendesk doesn't support URL-based metadata.
3. Configure SSO in Zendesk
In Zendesk's admin → security → SSO settings, paste the Okta metadata URL (or upload the XML). Zendesk will display the ACS URL + Entity ID it expects — copy these.
4. Return to Okta + complete the SAML app config
Paste Zendesk'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 Zendesk 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 Zendesk via the IdP-initiated link (from Okta dashboard) AND via SP-initiated (direct Zendesk login URL). Both should work. Check the SAML Tracer browser extension or SAML decoder to inspect the assertion if anything fails.
8. Generate a SCIM API token in Zendesk
In Zendesk's admin → SCIM provisioning section, generate an API token. Copy it — it's shown only once. Note the SCIM endpoint URL (typically https://<tenant>.zendesk.com/scim/v2).
9. Add SCIM provisioning in Okta
In the Okta app's provisioning tab, enable provisioning. Enter the SCIM endpoint URL + paste the API token. Test the connection — Okta should report a successful handshake.
10. Configure provisioning operations
Enable the operations you need: Create Users (on assignment), Update User Attributes (when source attributes change), Deactivate Users (on app unassignment), and optionally Group Push. Most production deployments enable all four.
11. Map attributes
Configure attribute mapping. Defaults usually cover userName + email + name + active. Map any custom attributes the app expects (department, manager, employee number) from the corresponding source.
12. Push existing users + groups
Initiate a sync to push existing assigned users. Watch the provisioning log for errors — common issues are duplicate users (already exists in target) or missing required attributes.
13. Verify deprovisioning works
Test deprovisioning by unassigning a test user. The user should be deactivated (not deleted) in Zendesk within minutes. Check the provisioning log + the user's active status.
What flows from where.
| Source (Okta) | Target (Zendesk) | Note |
|---|---|---|
| user.email | — | |
| user.firstName + lastName | name | — |
| user.role | role | agent | admin | end-user |
- Clock skew: Okta and Zendesk clocks must be within ~5 minutes. NTP-sync both. SAML's NotBefore + NotOnOrAfter are strict.
- NameID format mismatches are the most common failure. Zendesk 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: Zendesk'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.
- Zendesk's SCIM endpoint may not be RFC-7644 compliant in some edge cases. Test PATCH operations carefully — that's where the most diverging behavior shows up.
- Soft delete vs hard delete: SCIM standard is soft-delete (active=false). Some apps interpret deprovisioning as hard delete, losing user history. Verify against the app's docs.
- Custom attributes: Okta typically supports the SCIM Enterprise User extension. If Zendesk needs custom attributes outside that extension, you may need to extend the SCIM schema.
- Group provisioning is messier than user provisioning. Group push, group reconciliation, and nested groups behave inconsistently across SCIM implementations.
- API token rotation: SCIM tokens are long-lived but should be rotated. Build a rotation runbook.
- Zendesk roles (agent vs admin vs end-user) must be mapped explicitly — Zendesk does not infer role from group membership.
- End-user accounts (customers filing tickets) are typically NOT in SCIM scope. SCIM manages agents + admins.
- IdP-initiated SSO works (sign in from the IdP dashboard)
- SP-initiated SSO works (visit Zendesk 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)
- Provisioning: new user assigned → account created in Zendesk within 5 minutes
- Update: source attribute change (e.g. department) propagates to the target
- Deprovisioning: user unassigned → marked active=false in Zendesk (not deleted)
- Reactivation: re-assignment reactivates the existing account (no duplicate created)
- Provisioning log shows zero errors over a 24-hour window
- Manual sync (force re-push) completes without unexpected diffs
For the latest vendor-side configuration changes, refer to:
Zendesk SSO + SCIM →