In addition to the user authentication provided by Zendesk, you can also use single sign-on (SSO) to authenticate your users outside of Zendesk. There are three types of SSO: social account, business account, and enterprise.
This article covers the following topics:
Essential facts for SSO
Below are some essential facts about the available SSO options. These are explained in greater detail in this article.
- Admins and agents can sign in with either their Google, Microsoft, or Zendesk accounts, or can sign in directly by going to their Zendesk URL and entering their username and password. End users can sign in with all social and business accounts and their Zendesk accounts.
- If your Zendesk account is closed or restricted and a user tries to sign in with a different email than the one registered in Zendesk Support, their request will be rejected.
- You can define up to two active JWT and two active SAML authentication configurations.
- If you have more than one SSO configuration assigned to end users or team members, you must specify one as the primary authentication method for those users.
- No matter what authentication method you choose, Zendesk stores all users in the same database.
- If you're using a third-party identity provider to authenticate, you must configure the Zendesk app with the identity provider.
- It is not possible to apply different SSO options to individual brands, unless you use a custom script for JWT.
- If you place a wildcard (*) in the blocklist, users will no longer be able to authenticate or create an account with SSO. See Using the allowlist and blocklist to control access to your Zendesk.
Social and business account SSO
Social and business account SSO are additional sign-in options you can provide for your users' convenience. You can make these logins available on your Help Center sign-in page, so users can authenticate with their Zendesk Support account or a social or business account. Team members can only use business accounts to authenticate, but end users can authenticate with both.
Social accounts include Facebook and Twitter. Business accounts include Google and Microsoft.
- Google: The Google sign-in supports both Gmail and Google Apps. The Federated Login Service is disabled by default for Google Apps Business and Education accounts. The domain admin can enable it from the Control Panel at http://www.google.com/a/cpanel/yourdomain/SetupIdp, where yourdomain is replaced with your domain. Business account authentication supports two-factor authentication enabled by the user or for the Google Apps domain (Google Authenticator).
- Microsoft: Microsoft sign-in is not supported in the iPad version of Zendesk Support for Mobile app.
To add social and business account SSO to your login page, see Enabling social and business account single sign-on.
You can require users to sign in using enterprise SSO, or you can activate multiple sign-in options (for example, enterprise SSO and Zendesk authentication) and let users decide how they want to sign in. (The word "enterprise" in this context doesn't refer to Zendesk Enterprise plans.) See Providing multiple sign-in options for team members and end users.
About enterprise SSO
When you direct users to enterprise SSO, you're bypassing Zendesk and authenticating your users externally. When users navigate to your Zendesk sign-in page or click a link to access your Zendesk account, they can authenticate by signing into a corporate server or a third-party identity provider, such as OneLogin or Okta. Enabling enterprise SSO also affects the iOS and Android versions of the Zendesk mobile app.
- Users navigate to a Zendesk page or subdomain.
- If not already authenticated, users are redirected to your corporate server or third-party identity provider login page, depending on the enterprise SSO option you selected.
- Users enter their sign-in credentials.
- If valid, users are redirected back to the original Zendesk page.
Both your end users and team members can sign in to your Zendesk using enterprise SSO. You can configure enterprise SSO only for end users, team members, or a mix of both.
The advantage of using enterprise SSO is that you have complete control over your users behind your firewall. You authenticate your users once, against your own user authentication system, and then grant them access to many other resources both inside and outside of your firewall. Your user management is performed outside of Zendesk, but your corporate user authentication system is still synced with Zendesk. When you add a user account for a new employee, they will have immediate access to Zendesk, or if you delete a user account, that employee will no longer have access to Zendesk.
By default, the only data that Zendesk stores for each user is their name and email address, but it's possible to sync more user data to Zendesk, like the user's organization.
You have the option of keeping Zendesk authentication with your enterprise SSO authentication. If you decide to disable Zendesk authentication, all Zendesk user passwords will be permanently deleted within 24 hours.
If your SSO service is temporarily unavailable, you can still access your Zendesk account. See Accessing your Zendesk account when your SSO service is down.
Enterprise SSO options
- JSON Web Token (JWT): Credentials and user information is sent in JSON format encrypted using a Zendesk Shared Secret. For information on configuring JWT SSO, see Enabling JWT single sign-on.
- Secure Assertion Markup Language (SAML): SAML is supported by many identity provider services, such as Okta, OneLogin, Active Directory, and LDAP. For information on configuring SAML SSO, see Enabling SAML single sign-on.
You can use the same option for all users or different options for different collections of users. This is ideal if you have separate sets of users, existing in different locations that you don't want to merge. If you use more than one enterprise SSO configuration, you must set one configuration as the primary authentication method. When signing in to Zendesk, users will be redirected to your primary method login page. Users can sign in with alternative methods by going to the secondary method login page. See Using different SAML and JWT SSO (single sign-on) configurations.
If I deploy Enterprise SSO after some of my end-users already have ZenDesk accounts, will those accounts be deleted or synced when they sign in with the new Enterprise SSO option?
It will mostly depend on SSO settings on IdP's side (is provisioning enabled or not, and if enabled - which values are pushed to Zendesk upon log on etc), but in general - no user can be deleted by SSO or any other auth. process.
SSO can do one/all of the following: demote/promote users (by passing role attribute in your xml payload) and change their name, organisations and so on.
Users will be synched at the most. At the least 0 simply allowed to enter your Help Center as is, without any changes to their profile/role/etc
We have a mobile panel and were wondering, whether we can also set up SSO with mobile phone numbers instead of email addresses.
That would unfortunately not be possible since it is not supported within the SSO integration.
Sorry for that.
Have a great day and stay safe!
We just purchased Zendesk and want to use Guide as our knowledge center.
Our product is built as single tenant, means each customer (a business) will have its own instance in our cloud. We would like to connect our Zendesk Guide instance with SSO to all of our tenants (product docs are similar for all). Each business/customer has its own SSO of course.
Couldn't find a solution for that setup in the articles above. Is there a way to do this?
In our Zendesk instance, we’re concerned with whether unsigned-in/anonymous users will still see articles--that don’t require signing in--after enabling Enterprise SSO.
Our Zendesk instance is “closed”, meaning users can view articles (depending on permissions) in the Help Center anonymously or after signing in. (Only signed-in users can submit tickets.)
Using Enterprise SSO, users that do not sign in SHOULD still be able to view the articles that are set for anonymous viewing. Right?
It looks like you'll want to use custom JWT script and Multibranding as outlined in this article -Multibrand - Using multiple JWT single sign-on URLs.
Aside from that, you might also want to check Choosing the best authentication option for my account for more information about what kind of authentication you should use based on your account.
End-users should still be able to view your Articles as long as the visibility is set to everyone, even without signing in. For more information about visibility settings, see Setting view permissions on articles with user segments
I am wondering if it is possible to set up SSO but with different redirect links for different environments, such as one url for prod and another for dev?
As of the moment, there is no native way to do that in Support.
I asked that question a few months ago but still have no solution and we are thinking to probably switch to another tool because we have no resolution. Here is the question again:
We have multiple customers around the world that are authenticated to our app using their internal SSO.
We would like to have one Guide instance because there is no change in content between our customers help. So we do not want to use multi brand.
A user connecting to Guide should be authenticated, no matter if they come from inside our app (went through authentication) or just click a link (or bookmark of Guide page).
We couldn't find a solution that support that beside multi brand which is a lot of hustle maintaining multiple help centers instead of one master. Also multi brands are limited in number.
Any help is appreciated. If you know any customer that implemented such a solution it can be helpful too.
We don't want our customers to have/manage a separate login to submit and view their tickets via Zendesk. Instead, we want to require customers to sign in and authenticate to their account with us. Does Zendesk support this?
Currently, we encourage customers to submit a request by going to https://help.acme.com/hc/en-us/requests/new (I anonymized the link). But ideally, we want customers to sign in to Zendesk using their account with us before they can submit their request. That way, we know who they are and which subscription plan they're on.
It is possible indeed.
This article explains how SAML works and how to set it up to have the authentication for Zendesk happening on your system.
Enabling SAML single sign-on
Please share this documentation with your IT, so they can follow these steps.
Thanks for your question,
I am not sure what is the authorization flow that Zendesk is using for OAuth SSO?
Is it Authorization code or implicit or PKCE?
right now it is throwing below error back to me.
In the event like today, there are issues with Microsoft in logging into Zendesk, there is a workaround given. What would the behavior be if you turned off the external authentication after previously having external authentication enabled? And once the issue is resolved turning it back on again?
If External Authentication is turned off then Zendesk Auth will be used when logging into Zendesk and turning it on again will set it (SSO) as the default once more. If SSO is enabled, it will always be the primary authentication used.
How can we enable SSO for Login with Amazon? I am not able to evaluate if the mechanism for Login with Amazon is SAML or JWT? Can anyone help here?
Developer Guide: https://developer.amazon.com/docs/login-with-amazon/web-docs.html
It will be better if we check with their Support to determine what kind of SSO type they are using. Whichever it is, there's an available guide on how to set it up.
Enabling JWT (JSON Web Token) single sign-on.
Enabling SAML single sign-on
We would like to use SSO only for our own employees, regardless if they're agents or signed in end-users.
All others (partners, customers) should login through the normal ZD login methods.
Is this something ZD supports?
Not supported yet.
If one of our users uses social single sign on, are we able to see which users by email viewed a particular article?
Hi Tres Moore!
It might be worth looking into using Google Analytics for your goal. At the moment Explore does have the functionality of tracking page views but this is limited to user roles such as end-users, staff members, or visitors who are not signed-in (anonymous) users. It won't be able to display specifically who.
A good feature to have though! I highly encourage you to post this our Feedback - Reporting and analytics (Explore) topic.
Our product teams review these posts regularly and those with high engagements ultimately gets flagged and possibly gets added as a feature update in the future!
Hi F. Keijmes
I am a product manager leading Zendesk Authentication experience, I'll send you a direct email to know more about your use case.
Did you find what you were looking for? If amazon supports SAML / JWT based signing in as an IDP, you can checkout these 2 links
Enabling JWT (JSON Web Token) single sign-on.
Enabling SAML single sign-on
We want to use Google as our IdP with SSO for our agents.
I'm having an issue where Zendesk won't accept the SSO-URL provided by Google (https://accounts.google.com/o/saml2/idp?idpid=xxxxxxxx). Which SAML SSO-adres needs to be used?
Barkha Bhatia - we are in the process of designing our community and want to provide links to Jira, aha! and several other applications that require authentication. Can Zendesk accomodate this or do we require a third party application? Most of the articles I have read pertain to signing into Zenesk from another application but not to another application from Zendesk.
We are using Azure AD and cannot get custom role mappings to work meaning all of our users end up as end-users and will need to be manually updated. MS wrote a guide for this (https://learn.microsoft.com/en-us/azure/active-directory/saas-apps/zendesk-provisioning-tutorial) but it doesn't state exactly how to map the custom roles through. Has anybody else done this?
What effect does enabling Enterprise single sign-on have in regard to authenticating API requests? Are JWT tokens able to be passed in place of existing API authentication methods?
To have an Azure user be created as an Agent or Admin you would need to pass the "role" attribute, and the custom_role_id if you want them to be any of the custom roles you make in your account.
There are some details on this article about the attributes that can be sent and the naming conventions:
Enabling SAML single sign-on
Hi Carl McDowell
Sorry I didn't reply sooner, I missed your response!
Just to update that we got this sorted - it was an issue with our Azure AD configuration and a mis-understanding on our end. All working now.
I am using SSO to allow users to log into their account in Zendesk, and sometimes the authentication fails, and the user is logged out with this message in the URI: ?kind=error&message=“Invalid user. E-mail: email@example.com is already used”.
I had this issue for a while now, but I still don’t understand what exactly triggers it. The most plausible theory I have for now is that this happens when a user changes their email in my application and those changes aren’t reflected into their zendesk account which still has the old email. But I have found instances where it happened for users who have the same email in both accounts.
Can you give me more context as to when this error is raised? Do you have any ideas of the source of my issue or any possible solutions?
Please sign in to leave a comment.