Enabling social and business single sign-on (SSO) Follow

all plans

You can provide you users with more options for signing in to Zendesk Support by allowing them to sign in using their existing social and business accounts (often referred to as social login or social sign-in). These include Google, Microsoft, Facebook, and Twitter.

When you enable these in your Zendesk Support account, they are added as sign-in options on your sign-in page.

The advantage of enabling these, for your users, is that they don't need to remember yet another user name and password to sign in to Zendesk Support. These are one type of single sign-on available in Zendesk Support. For more information about the other types of single sign-on options, see Configuring how end-users access and sign in to your Zendesk.

Your users are still able to sign in to your Zendesk Support account if they have an account user name and password. They can use both their Zendesk Support sign-in credentials and the social and business sign-ins.

How single sign-in works in Zendesk Support

The first time a user chooses to sign in to Zendesk Support using one of their social or business accounts, they're prompted to authorize that account to be used with Zendesk Support. After that one-time authorization is completed, the user is seamlessly signed in to Zendesk Support. On subsequent visits, the user clicks the social or business sign-in button and, if they're already signed in to the account, they're immediately signed in to Zendesk Support. If they aren't already signed in with the social or business account, they'll be prompted to do so. Your users' social and business account sign-in credentials (user name and password) are never shared with Zendesk. What is shared is the primary email address contained in the social and business account. As mentioned above, Zendesk needs this so you can communicate with the user via email.

So far, all of this has been very straightforward. Where it gets a little more complex is if a user already has an account in Zendesk Support or if you've restricted or closed your Zendesk Support instance (in other words, you don't allow everyone access).

As an example, imagine that you already have users in Zendesk Support and you then add a social sign-in (let's use Facebook in this example). An existing user sees the new Facebook sign-in button and decides to log in using that rather than using their existing Zendesk Support user name and password. The Facebook authorization and log-in is as easy as described above. However, unless the primary email address in their Facebook account is also included in their Zendesk Support user account, a new, duplicate user account will be created. This is because Zendesk receives a new email address from Facebook that does not already exist in Zendesk Support and assumes that it is a new user. You can merge the duplicate user account into the user's existing account.

The effects of using social and business sign-ins in Zendesk Support accounts that are open, restricted, or closed are described in detail below.

Since each user must sign in to their social or business account to authorize their use with Zendesk Support, your support staff cannot add these on your users' behalf.

Enabling sign-in providers

The following options are available for end-users: Twitter, Facebook, Google, and Microsoft. Agents and admin have two options: Google and Microsoft. No custom configuration of these is necessary. You just enable them. When your users click to sign in to Zendesk Support using one of these providers and enter their sign-in credentials (for their Facebook account, for example), they are authenticated by that provider and then redirected back to Zendesk Support and automatically signed in.

To enable sign-in providers

  1. Click the Admin icon () in the sidebar, then select Security in the Settings category.
  2. Click the Admins & Agents or End-users tab. You can set one sign-in provider for end-users, and a different one for admins and agents.

    If you started using Zendesk Support on or after August 21, 2013, the End-users tab is not available until you activate the Help Center. See Getting started with the Help Center.

  3. Select each of the sign-in providers you want to enable.
  4. If you want everybody to only use the single sign-on method, select the option to disable Zendesk passwords. Any Zendesk passwords will be permanently deleted from the account within 24 hours.

    If you disable Zendesk passwords and your sign-in provider goes down, admins can still access the account. You can further restrict this option to the account owner. See Accessing the account if SSO is down and Zendesk passwords are disabled.

    If you leave Zendesk passwords enabled and your sign-in provider goes down, agents and admins with a Zendesk username and password can still access the account by browsing to a specific URL. See Accessing the account if SSO is down and Zendesk passwords are enabled.

  5. Click Save.

After you enable your sign-in providers, the sign-in links appear on your Help Center sign-in page (as shown at the beginning of this article). Your users are required to authorize the use of their sign-in credentials the first time they attempt to sign in to Zendesk Support.

On subsequent visits to Zendesk Support, your users can quickly sign in with their user social or business sign-in ID and password. If they're already signed in to those services, they aren't prompted for their ID and password; they're immediately signed in to Zendesk Support.

Social and business sign-ins in an open Zendesk Support instance

If Zendesk Support is configured as an open instance (see Setting up an open Zendesk), meaning that anyone can register and submit support requests, and a user signs in to Zendesk Support with a social or business sign-in for the first time, two things can happen. If the user already exists in Zendesk Support and the social or business sign-in has already been added to their user profile as an additional contact, then the user will be associated with their existing account.

If however the user is either new (no account in Zendesk Support yet) or an existing user's social or business account hasn't already been added to their user profile, then a new user account is created. For existing users, you can merge the new user account with their existing account. See Merging a user's duplicate account.

Note: When a new user account is created under these conditions, the new user verification email is not sent. This is because the social or business account has already verified the user's email address.

Social and business sign-ins in a closed or restricted Zendesk Support instance

If Zendesk Support is closed or restricted (see Setting up a closed Zendesk Support instance and Setting up a restricted Zendesk Support instance), meaning that access to Zendesk Support is granted only to specific users, then social and business sign-ins behave a little differently.

In a closed Zendesk Support instance, the only way for an approved user to access Zendesk Support using a social or business sign-in is if the account has already been added to their user profile. If it hasn't already been added, no new user account is created (as it would be in an open instance). Instead, the sign in attempt is rejected. If a new user (someone not already added to Zendesk Support) attempts to sign in via a social or business sign-in, the same thing happens--the request is rejected.

If your Zendesk Support instance is restricted, meaning that you allow anybody to submit requests but then accept or reject those requests based on the email domains you add to the whitelist or blacklist (see Using the whitelist and blacklist to control access to Zendesk Support), the behavior is the same as a closed instance. If the social or business account hasn't already been added to the user's profile, then the attempt to sign in will be rejected. The whitelist and blacklist have nothing to do with signing in to Zendesk Support; they're are only used to accept or reject support requests. As an example, even if you added gmail.com to your whitelist, attempts by users to sign in to Zendesk Support using the Google sign-in would still be rejected if their Google account hasn't already been added to their user profile.

Accessing the account if your SSO service goes down

If your SSO service goes down, you can still access your account. The method depends on whether you disabled Zendesk passwords or not.

Accessing the account if SSO is down and Zendesk passwords are disabled

If you disabled Zendesk password access (see Enabling sign-in providers above), admins or the account owner can still access the account by requesting a one-time email link that gives them access to the account. No password is required.

To get a one-time email link

  1. Browse to https://your_subdomain.zendesk.com/access/sso-bypass, where your_subdomain is your account name.
  2. Enter and submit your email address associated with your Zendesk user profile.
  3. Check your email inbox, then click the link in the email to sign in.

    The link works only once and times out after 5 minutes.

Accessing the account if SSO is down and Zendesk passwords are enabled

If Zendesk password are still enabled (see Enabling sign-in providers above), agents and admins with a Zendesk username and password can still access the account by browsing to a specific URL.

To sign in

  1. Browse to https://your_subdomain.zendesk.com/access/normal, where your_subdomain is your account name.
  2. Enter the username and password associated with your Zendesk account.

Additional information about Microsoft

Microsoft sign-in is not supported in the iPad version of the Zendesk Support for Mobile app.

Additional information about 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.

If two-factor authentication is enabled by the user or for the Google Apps domain (Google Authenticator), this functionality is supported by this authentication process.

 

Have more questions? Submit a request

Please sign in to leave a comment.

Powered by Zendesk