Okta and Zendesk Single Sign-On
The SAML handshake takes twenty minutes. Getting roles, groups and deprovisioning right is the part that takes a week and actually matters.
What you're wiring together
Okta is the identity provider. Zendesk is the service provider. When someone hits your Zendesk sign-in page, Zendesk bounces them to Okta, Okta authenticates them and posts a signed assertion back, and Zendesk trusts it.
Two decisions come before any configuration. First, are you doing SSO for staff, for end users, or for both? Zendesk treats them separately, and you can point staff at Okta while leaving end users on password or social sign-in. Most teams should. Your customers do not have Okta accounts.
Second, do you want Okta to create Zendesk users, or do you want Zendesk to create them on first login? Those are two different mechanisms and picking both by accident is where the mess starts.
Okta and Zendesk configuration, both sides
Okta ships a Zendesk app in its catalogue. Use it rather than a generic SAML template, because it prefills the ACS and audience URLs against your subdomain and saves you the classic typo.
On the Okta side
Set your Zendesk subdomain, then decide the attribute statements. At minimum you are sending an email and a name. Beyond that, Zendesk accepts a set of named attributes for things like role, organization, tags and external ID. Check the current Zendesk SAML attribute reference before you rely on a specific name, because the accepted list has changed over time and a misspelled attribute fails silently rather than loudly.
On the Zendesk side
Admin Center, then Security, then the single sign-on section. You create a SAML configuration holding the Okta SSO endpoint URL, the certificate fingerprint, and optionally a remote logout URL. Then you assign that configuration to staff members, to end users, or to both, in the authentication settings for each group.
That assignment step is separate from creating the config. People create a perfect SAML configuration, never assign it, and then spend an hour wondering why the login page still shows a password box.
JIT provisioning, and what it does not do
With just-in-time provisioning, the first successful assertion for an unknown email creates the Zendesk user from the attributes in that assertion. No pre-sync, no import. Subsequent logins update the user from the same attributes.
It's genuinely convenient and it has one large gap: JIT creates and updates, it doesn't delete. Remove somebody from Okta and their Zendesk account sits there, still holding a licence, still assigned to open tickets, just unable to log in.
That is fine for end users and not fine for agents, since agent seats cost money. If you need real lifecycle management, use Okta's provisioning integration rather than JIT alone, so a deactivation in Okta pushes a suspension into Zendesk. Confirm what the current Okta Zendesk app supports for provisioning before you promise it to anyone.
Groups to roles
This is the piece everyone wants and the piece that behaves least intuitively.
Build the mapping in Okta group rules rather than in per-user profile attributes. Per-user works until the twelfth user, then it becomes somebody weekly chore forever.
The four things that go wrong
Locking yourself out. Enable SAML for staff, get one thing wrong, and no admin can sign in. Zendesk keeps a bypass path for admins on a dedicated URL. Find it, note it, and test it in a sandbox before you touch production. Also keep one admin on password authentication permanently as a break-glass account.
Certificate expiry. The Okta signing certificate has an end date, and when it passes, every login fails at once with a message nobody finds informative. Put the expiry in a calendar the year you set it up.
Clock skew. SAML assertions carry a validity window measured in minutes. A server with a drifting clock produces intermittent failures that look like a network fault.
Email as the identifier. Zendesk matches on email address. Change someone email in Okta without changing it in Zendesk and JIT will happily create a second Zendesk user, leaving their old tickets attached to the old identity. Decide up front which system owns the email address.
Test all of it in a Zendesk sandbox first. This is one of the few configurations where a bad Friday afternoon means nobody works on Monday.
Frequently asked questions
What does the Okta Zendesk integration cover?
Okta Zendesk SSO handles sign-in through SAML, and the Zendesk Okta integration adds SCIM provisioning if you want accounts created and deactivated automatically.
Does Zendesk support SAML with Okta?
Yes. Zendesk supports SAML single sign-on and Okta ships a prebuilt Zendesk app, so you mostly supply the subdomain, the SSO endpoint and the certificate fingerprint.
Can I use Okta SSO for agents but not customers?
Yes, and usually you should. Zendesk assigns authentication settings separately for staff and end users, so agents can go through Okta while customers keep password or social sign-in.
Does JIT provisioning remove users?
No. JIT creates and updates users on login but never deletes or suspends them. For real lifecycle management you need a provisioning integration, otherwise deactivated staff keep their Zendesk seat.
How do I map Okta groups to Zendesk roles?
Send a role attribute in the SAML assertion, driven by Okta group rules. Check the current Zendesk SAML attribute reference for the exact attribute names and accepted values.
What happens if the SAML config is wrong?
Everyone is locked out. Zendesk provides an admin bypass sign-in path, so locate it before enabling SSO and keep one break-glass admin on password authentication.
Clean identity, cleaner queue
One person with two accounts files the same problem more than once. Ticket Merger catches the duplicates that identity drift creates.
Start free trial14-day free trial. No credit card required.