Plan requirement
| Subscription | Any plan |
| Access | Admin |
The Okta side of a SAML setup, and the two settings that cause most of the failures: which address is sent, and who the application is assigned to.
Set it up
- In Okta, add the Zendesk application and give it a name and your Zendesk subdomain. If your URL is mycompany.zendesk.com, the subdomain is mycompany.
- Under sign-on options, select SAML 2.0.
- Take three values from that screen: the SAML SSO URL, the Remote logout URL and the Certificate fingerprint (SHA2).
- Assign the application to the right group of people.
- In Admin Center, click Account in the sidebar, select Security > Single sign-on, click Create SSO configuration and choose SAML. Enter the three values.
- Decide whether this applies to team members, to end users, or to both.
- Test with one account in a private window.
The logout URL is the one people forget. Without it, signing out of Zendesk leaves the Okta session intact, so the next click signs them straight back in and it looks like sign-out is broken.
Who it applies to, and how many you may have
SAML can be enabled for end users only, for team members only (including light agents and contributors), or for both. You can create multiple SAML and JWT configurations, assigned to different collections of users. Zendesk capped this at two of each until September 2026 and no longer names a limit, so a plan built around that old ceiling can be widened.
That is what makes a staged rollout possible: one configuration for the team while end users carry on as they were.
Failure one: the email attribute
Zendesk identifies people by email address. If Okta sends a username, an identifier or a different address, the sign-in either fails or creates a new user.
Check what is being sent, not what you configured.
Failure two: assignment
An application configured perfectly and assigned to nobody produces an error for everybody. It is the first thing to check when it works for you and not for the team.
Assign by group
Not individually. Then a new colleague added to the group in Okta has Zendesk access automatically, and somebody removed loses it, which is the point of doing this at all.
Test in a private window
With your ordinary session still open elsewhere. If the configuration is wrong you can still reach the settings and fix it.
Certificates expire
And when one does, nobody can sign in, with no warning beforehand. Note the expiry date somewhere your team will see it, because this is a scheduled outage nobody scheduled.
Then disable Zendesk passwords
Once it works for everybody. Leaving them enabled keeps a second route in that Okta does not control.
Comments
0 comments
Article is closed for comments.