Enabling JWT (JSON Web Token) single sign-on

Fastpath: Admin > Settings > Security

Single sign-on is a mechanism that allows you to authenticate users in your systems and subsequently tell Zendesk that the user has been authenticated. If you use single sign-on with JWT, a user is automatically verified with the identity provider when they sign in. The user is then allowed to access Zendesk Support without being prompted to enter separate sign-in credentials.

At the core of single sign-on is a security mechanism that allows Zendesk to trust the sign-in requests it gets from your systems. Zendesk only grants access to the users who have been authenticated by you. Zendesk SSO relies on a technology called JSON Web Token (JWT) for securing the exchange of user authentication data.

JWT SSO is available on the Team plan and above.

This article contains the following sections:

• How JWT SSO for Zendesk works
• Requirements for enabling JWT SSO
• Enabling JWT SSO
• Additional information about JWT

The IT team in a company is usually responsible for setting up and managing the company's JWT authentication system. Their role is to implement SSO for Zendesk on the system. Refer the team to the following topic in this article:

• Technical implementation worksheet

Related articles:

• Single sign-on (SSO) options in Zendesk
• Using SAML for single sign-on (Professional and Enterprise)

How JWT SSO for Zendesk works

Once you enable SSO, sign-in requests are routed to a sign-in page external to Zendesk Support.

Steps of the JWT SSO authentication process:

1. An unauthenticated user navigates to your Zendesk Support URL. Example: https://your-subdomain.zendesk.com/.
2. The Zendesk SSO mechanism recognizes that SSO is enabled and that the user is not authenticated.
3. Zendesk redirects the user to your organization's remote sign-in page. Example: https://mycompany.com/zendesk/sso.
4. A script on the remote server authenticates the user using your organization's proprietary sign-in process.
5. The authentication system builds a JWT request that contains the relevant user data.
6. The authentication system redirects the user to the following Zendesk endpoint with the JWT payload:

   https://your-subdomain.zendesk.com/access/jwt

7. Zendesk parses the user detail from the JWT payload and then grants the user a session.

As you can see, this process relies on browser redirects and passing signed messages using JWT. The redirects happen entirely in the browser and there is no direct connection between Zendesk and your systems, so you can keep your authentication scripts safely behind your corporate firewall.

Requirements for enabling JWT SSO

Meet with the team in your company responsible for the JWT authentication system (usually a team in the IT department) and request the following information:

• The remote login URL where Zendesk users should be redirected when they attempt to access Zendesk
• (Optional) The remote logout URL where Zendesk can redirect users after they sign out of Zendesk
• (Optional) A list of IP ranges to redirect users to the appropriate sign-in option. Users making requests from the specified IP ranges are routed to the remote JWT authentication sign-in form. Users making requests from IP addresses outside the ranges are routed to the normal Zendesk sign-in form. If you don't specify a range, all users are redirected to the remote authentication sign-in form.

Confirm with the team that any Zendesk-bound traffic is over HTTPS, not HTTP.

Next, enter the information in Support to enable single sign-on. See Enabling JWT SSO.

The IT team may require additional information from Zendesk to configure the SAML implementation. Refer them to the Technical implementation worksheet in this article.

Enabling JWT SSO

You can enable JWT single sign-on only for end users, only for agents, or for both groups. If you're using both JWT and SAML, you need to select one as the primary authentication method. When signing into Zendesk, users will redirected to your primary sign-in page. Users can sign in with the secondary method by going to the secondary sign-in page. For details, see Using different SAML and JWT SSO (single sign-on) for agents and end users.

You must sign in to Zendesk Support as an administrator to enable JWT single sign-on.

To enable JWT single sign-on

1. Click the Admin icon () in the sidebar, then select Settings from the Security category.
2. Select the Admins & Agents or End users tab.

   The End users tab is not available until you activate Help Center. See Getting started with the Help Center.

3. Select the Single sign-on (SSO) option, then click the JSON Web Token checkbox.
4. For Remote Login URL, enter the URL where your user should be redirected when they attempt to access your Zendesk URL.

   Zendesk automatically adds a brand_id parameter to the URL. This is the Zendesk Support brand the user was on when they attempted to sign in.

5. For Remote Logout URL, enter the URL that Zendesk will return your users to after they sign out.

   Zendesk automatically adds email, external_id, and brand_id parameters to the URL. If you prefer not having email and external id information in the URL, specify blank parameters in the logout URL. Example:

   https://www.xyz.com/user/signout/?email=&external_id=

   Note: If you're using an Ember.js application, you need to amend the logout URL to use blanked parameters before the hash. For example, https://somedomain.com/?brand_id=&return_to=&email=#/zendesk-login/.
6. (Optional) For IP ranges, enter a list of IP ranges if you want to redirect users to the appropriate sign-in option.

   Users making requests from the specified IP ranges are routed to the JWT authentication sign-in form. Users making requests from IP addresses outside the ranges are routed to the normal Zendesk sign-in form. Don't specify a range if you want all users to be redirected to the JWT authentication sign-in form.

7. If you use external IDs for your users, you can update these in Zendesk Support by selecting Allow update of external ids?.
8. Generate a shared secret by clicking Generate a new token.

   Provide the shared secret to your IT team. They'll need it in their JWT implementation.

   Important: Keep the shared secret safe. If it's compromised, all the data in your Support account is at risk.
9. If you want all users 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.

10. If you disabled Zendesk passwords, select the menu option that specifies whether only the account owner or admins (which includes the account owner) can be granted access to the account in case the sign-in provider does down.

    

    To gain access, the account owner or an admin requests to receive an email containing an one-time access link. Clicking the link grants the person access to the account. No password is required. See Accessing the account if passwords are disabled.

11. Click Save.

Additional information about JWT

JWT is a recent open standard that is being driven by the international standards body IETF and has top-level backers from the technology sector (for example, Microsoft, Facebook, and Google).

The fundamental building blocks of JWT are very well understood components and the result of this is a fairly simple spec, which is available here http://tools.ietf.org/html/draft-jones-json-web-token-10. There are a lot of open source implementations of the JWT spec that cover most modern technologies. This means that you can get JWT single sign-on set up without much difficulty.

One thing to be aware of is that the JWT payload is merely encoded and signed, not encrypted, so don't put any sensitive data in the hash table. JWT works by serializing the JSON that is being transmitted to a string. It then base 64 encodes that string and then makes an HMAC of the base 64 string which depends on the shared secret. This produces a signature that the recipient side can use to validate the user.

Technical implementation worksheet

This section is for the team in the company responsible for the company's JWT authentication system. It provides details about the Zendesk JWT SSO implementation.

Note: If you're upgrading from an earlier version of Zendesk SSO (referred to as Zendesk Remote Authentication) to JWT, it's okay to have multiple SSO implementations enabled at the same time. Zendesk recognizes if a request is meant for JWT or another type of SSO and will handle the request accordingly. This means that you can enable and test JWT before deactivating your previous SSO implementation.

Topics covered:

• JWT algorithm
• Zendesk JWT endpoint
• JWT attributes
• Remote login URL parameter (return_to)
• Error handling
• JWT implementation code examples

JWT algorithm

Specify HS256 as the JWT algorithm in the header of your JWT payload:

{
  "typ":"JWT",
  "alg":"HS256"
}

HS256 stands for HMAC SHA 256, a 256-bit encryption algorithm designed by the U.S. National Security Agency.

Note: Zendesk does not support the RS256 and ES256 JWT algorithms.

Zendesk JWT endpoint

After successfully authenticating the user, redirect the user along with the JWT payload to the following Zendesk endpoint:

https://your-subdomain.zendesk.com/access/jwt

The payload should be base64-encoded and appended to the URL as a query string.

The JWT payload must be sent to your Zendesk Support subdomain using the https protocol. Example:

https://your-subdmain.zendesk.com/access/jwt?jwt={payload} 

Host-mapped subdomains are not supported.

JWT attributes

Send attributes to Zendesk as a base64-encoded hash (Ruby) or dictionary (Python). Example using Ruby:

payload = JWT.encode({
   :email => "[e-mail]", :name => "Bob", :iat => Time.now.to_i, :jti => rand(2<<64).to_s
}, "Our shared secret")

Zendesk requires an email address to uniquely identify the user. Beyond the required attributes listed in the table below, you may optionally send additional user profile data. This data is synced between your user management system and Zendesk Support.

Table 1. Supported attributes

Attribute	Required	Description
iat	Yes	Issued At. The time the token was generated, this is used to help ensure that a given token gets used shortly after it's generated. The value must be the number of seconds since UNIX epoch. Zendesk allows up to three minutes clock skew, so make sure to configure NTP or similar on your servers.
jti	Yes	JSON Web Token ID. A unique id for the token, used by Zendesk to prevent token replay attacks.
email	Yes	Email of the user being signed in, used to uniquely identify the user record in Zendesk Support.
name	Yes	The name of this user. The user in Zendesk Support will be created or updated in accordance with this.
external_id	No	If your users are uniquely identified by something other than an email address, and their email addresses are subject to change, send the unique id from your system. Specify the id as a string.
locale (for end-users) locale_id (for agents)	No	The locale in Zendesk Support, specified as a number.
organization	No	The name of an organization to add the user to. Note: If the option End-users can belong to multiple organizations is enabled, additional organizations append the original organization, and are considered secondary organizations. This does not delete the existing memberships.
organization_id	No	The organization's external ID in the Zendesk API. If both organization and organization_id are supplied, organization is ignored. Note: If the option End-users can belong to multiple organizations is enabled, additional organizations append the original organization, and are considered secondary organizations. This does not delete the existing memberships.
phone	No	A phone number, specified as a string.
tags	No	This is a JSON array of tags to set on the user. These tags will replace any other tags that may exist in the user's profile.
remote_photo_url	No	URL for a photo to set on the user profile.
role	No	The user's role. Can be set to "user", "agent", or "admin". Default is "user". If the user's role is different than it is in Zendesk Support, the role is changed in Zendesk Support.
custom_role_id	No	Applicable only if the role of the user is agent.
user_fields	No	A JSON hash of custom user field key and values to set on the user. The custom user field must exist in order to set the field value. Each custom user field is identified by its field key found in the user fields admin settings. The format of date values is yyyy-mm-dd. If a custom user field key or value is invalid, updating the field will fail silently and the user will still log in successfully. For more information about custom user fields, see Adding custom fields to users. Note: Sending null values in the the user_fields attribute will remove any existing values in the corresponding fields.

Remote login URL parameter (return_to)

When Zendesk redirects a user to your remote login page, it also passes a return_to URL parameter. The parameter contains the page that Zendesk will return the user after your system has authenticated the user. Append the parameter (name and value) to the Zendesk JWT endpoint.

For example, suppose an agent who is signed out clicks the following link to open a ticket in Support: https://mycompany.zendesk.com/tickets/1232. The flow is as follows:

1. On click, Zendesk redirects the user to your remote login URL and appends the following return_to parameter to the URL:

   https://mycompany.com/zendesk/sso?return_to=https://mycompany.zendesk.com/tickets/123

2. Your authentication system takes the return_to parameter (name and value) from the URL and, after successfully authenticating the user, appends it to the Zendesk JWT endpoint. Example:

   https://mycompany.zendesk.com/access/jwt?jwt=payload&return_to=https://mycompany.zendesk.com/tickets/123

3. Zendesk uses the parameter to open the ticket page for the agent.

The return_to parameter is an absolute URL for the agent interface, and a relative one for Help Center.

Whether you pass in the return_to parameter or not is optional, but we recommend it for the best user experience.

Note: If your return_to address contains its own URL parameters, make sure that your script URI-encodes the entire return_to value when submitting the JWT token.

Error handling

If Zendesk encounters an error while processing a JWT login request, it sends a message that explains the issue. If you specified a remote logout URL when you configured the JWT integration, it redirects to that URL and passes a message and a kind parameter. In case of error, the kind parameter always has the value "error". Zendesk recommends specifying a remote logout URL, as well as logging messages from Zendesk alongside the type. Most of the errors that can happen are ones that you'll want to fix. Examples: clock drifts, rate limits being hit, invalid tokens, and so on.

JWT implementation code examples

The actual JWT implementation is straightforward and most modern languages have libraries that support it. Zendesk provides a series of examples for various stacks in the following JWT SSO GitHub repository:

• https://github.com/zendesk/zendesk_jwt_sso_examples

If you implement JWT in any other stack, we would love to feature an example of that there as well. Add a comment to this article to share what you've implemented.

In case you run IIS/AD and don't want to build your own .NET solution, we provide a full implementation in classic ASP, which requires you to adjust only a couple of variables. Download the ASP authentication script from this page on Github: https://github.com/zendesk/zendesk_jwt_sso_examples/tree/master/bundles.