Forums/Documentation/User access, login, and security

Setting up single sign-on with JWT (JSON Web Token)

Morten Primdahl
posted this on April 26, 2013 16:12

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. The user is then allowed to access Zendesk without being prompted to enter separate login credentials.

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

Note: Before April 29, 2013, single sign-on was provided by Zendesk Remote Authentication. This has been deprecated and JWT is the new solution for single sign-on (read the announcement here). Plus and Enterprise accounts may also choose to implement single sign-on using SAML (see Introducing SAML for Zendesk). The Zendesk Remote Authentication documentation is archived and is now available here: Setting up single sign-on with Zendesk Remote Authentication (Deprecated) [PDF].

JWT implementation code examples

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

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.

The single sign-on authentication process

Once you enable single sign-on, login requests are routed to a remote login URL (a login page that is external to your Zendesk).

Here are the steps of the single sign-on authentication process:

  1. An unauthenticated user (not already logged in) navigates to your Zendesk URL (for example, https://mycompany.zendesk.com/).
  2. The Zendesk SSO mechanism recognizes that SSO is enabled and that the user is not authenticated.
  3. The user is redirected to the remote login URL configured for the SSO settings (for example, https://mycompany.com/zendesk/sso).
  4. A script on your side authenticates the user using your proprietary login process.
  5. Your script builds a JWT request that contains the relevant user data.
  6. You redirect the customer to the Zendesk endpoint at https://mycompany.zendesk.com/access/jwt with the JWT payload.
  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.

Configuring your JWT implementation

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.

To perform SSO for a user, you need to send several required user attributes to Zendesk as a hash (hash table, dictionary). Most importantly, Zendesk requires an email address to uniquely identify the user. Beyond the required attributes, which are shown in the table below, you may optionally send additional user profile data. This data is synced between your user management system and your Zendesk.

Table 1. Supported attributes
AttributeMandatoryDescription
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 two minutes clock skew, so make sure to configure NNTP 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.
name Yes The name of this user. The user in Zendesk 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, specified as a number.
organization No The name of an organization to add the user to.
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 already exists in Zendesk, the existing role is not changed.
custom_role_id No Applicable only if the role of the user is agent.
user_fields No

A JSON hash of user field key and values to set on the user. The user field must exist in order to set the field value. Each 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 user field key or value is invalid, updating the field will fail silently and the user will still login successfully. For more information about custom user fields, see Adding custom fields to users.

Most JWT implementations take a hash and a secret, and return a plain string payload to send to the other side. For context, here's an example in Ruby:

payload = JWT.encode({ 
   :email => "bob@example.com", :name => "Bob", :iat => Time.now.to_i, :jti => rand(2<<64).to_s 
}, "Our shared secret") 

response.headers["Location"] = "https://example.zendesk.com/access/jwt?jwt=#{payload}"

The return_to URL

When Zendesk redirects a user to your login script, it will also pass a return_to parameter in the URL. This parameter contains the page that Zendesk will return the user to after the authentication succeeds. For example:
  1. A user visits https://mycompany.zendesk.com/tickets/123.
  2. Zendesk recognizes that the user is not authenticated.
  3. Zendesk redirects the user to:
    https://mycompany.com/zendesk/sso?return_to=https://mycompany.zendesk.com/tickets/123
All your script needs to do, is take the return_to value from the invoked URL and pass it back to Zendesk when submitting the JWT token. In other words, upon authentication on your side, your script redirects the user to:
https://mycompany.zendesk.com/access/jwt?jwt=payload&return_to=https://mycompany.zendesk.com/tickets/123

The return_to parameter is an absolute URL for the agent interface and the Web portal, 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 smoothest 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 will report a message that explains what the issue is. If you have a return URL configured for your JWT integration, it will redirect to that and pass a "message" and a "kind" parameter. In case of error, the "kind" parameter will always have the value "error". We recommend having a return URL as well as logging messages from Zendesk alongside the type, most of the errors that can happen are ones that you will want to fix (for example, clock drifts, rate limits being hit, invalid tokens, and so on).

Enabling JWT single sign-on in your Zendesk

To start using JWT single sign-on, you need to enable and configure it in your Zendesk account.

To enable JWT single sign-on

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

    You can enable JWT single sign-on only for end-users, only for agents, or for both groups. You can't enable JWT for one group if the SAML SSO option is enabled for the other group. If you want to use single sign-on for both groups, both must be JWT or both must be SAML.
    If you started using Zendesk 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.

    Zendesk Classic: Select the Single Sign-On tab.
  3. Select the JSON Web Token option.
    Zendesk Classic: Next to the JSON Web Token option, click Edit, and then select Enabled.
  4. Enter the Remote Login URL. This is where your user will be redirected when they attempt to access your Zendesk URL.
  5. Enter the Remote Logout URL. This is the URL that Zendesk will return your users to after they log out.
  6. You can optionally restrict access to users within a range of IP addresses.
  7. If you use external_IDs for your users, you can update these in your Zendesk by selecting Allow update of external ids?.
  8. Finally, you need to generate a shared secret by clicking Generate a new token. Copy the shared secret because you'll need to use it in your JWT implementation.
    Important: You must keep the shared secret safe because if that gets compromised all the data in your Zendesk account is at risk.
  9. When you're done configuring JWT, 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.

 

Comments

User photo
James Dietrich
Zendesk

Though not terribly different than the Django example, here's an implementation for the Flask framework: https://gist.github.com/jbdietrich/5489562

April 30, 2013 08:46
User photo
Daryl Antony

Hey there, I'm looking around for a Javascript implementation... throw us a link good sirs? (Lest google gets me there)

May 06, 2013 20:03
User photo
Daryl Antony

Oh and I did mean node.js!

May 08, 2013 23:32
User photo
Ryan Nguyen
lovestockleaf

I get this error using the php example in github (https://github.com/zendesk/zendesk_jwt_sso_examples/blob/master/php...

"Timestamp invalid. Ensure that your iat parameter is correct."

 

That example is using the time()  to generate current timestamp (iat parameter) .

 

Is that error caused by mismatching server timestamp? If so, what offset do we need to set to iat to make sure Zendesk accept the timestamp?

 

Thank you.

May 09, 2013 22:59
User photo
Morten Primdahl
Zendesk

@Ryan - your time() call should return something that's close to http://www.epochconverter.com/ - if that's not the case, then your server clock may be drifting. The timestamp required is number of seconds since Unix epoch - aka. the time 00:00:00 UTC on 1 January 1970. If your server clock is looking fine, then submit a ticket and we can take a closer look.

@Daryl - we hear you, keep an eye on https://github.com/zendesk/zendesk_jwt_sso_examples

May 10, 2013 08:53
User photo
Morten Primdahl
Zendesk
May 10, 2013 13:25
User photo
Dave Fraleigh
thousandeyes

Not for nothing, but could you maybe have provided a little more time for transition than 3 weeks - or maybe taken a proactive approach and notified customers who were using the redirect method, before turning it off?

-1 for  poor operational account management, Zendesk.

May 17, 2013 10:20
User photo
Brandon K.
Zendesk

Hey Dave,

I just talked with the Product Manager in charge of this transition and he let me know that we are giving our users 90 days to transition to JSON web tokens and not 3 weeks. So if your main concern is that 3 weeks is not enough, I hope this is good news! I'm going to open a ticket with you so we can discuss this transition with you and give you advice on any concerns you have with your specific account. 

Thank you for letting us know about your concerns so we can sort this out!

May 17, 2013 11:15
User photo
Josh Roman
kokofitclub

Brandon et. al -- we have an active open ticket b/c our redirect-based SSO quit working w/o advanced warning. We're dead in the water for our customers.  Was there advance notification? (If so, how?) How do we get this turned back on so we have months (not weeks) to adapt?

May 17, 2013 11:37
User photo
Brandon K.
Zendesk

Hey Josh,

This should definitely not have already been turned off for you. I'll look for your ticket in our queue and escalate it right away if it has not been already. We should be able to work with you to get this turned back on so you can have a full 3 months to set up a smooth transition.

May 17, 2013 11:48
User photo
Dave Fraleigh
thousandeyes

@Josh - we had the same problem this morning - and I'm equally annoyed.

Our problem was that we were expecting the return_to parameter to be returned all the time - some change apparently has made it an optional field, only returned in certain circumstances (ie, when redirecting to a specific article, rather than to the base site).

 

May 17, 2013 11:50
User photo
Josh Roman
kokofitclub

Thanks, Brandon. Our internal Zendesk manager also received some potentially erroneous advice from a Zendesk CSR earlier today in his attempts to resolve (i.e. "turn off SSO") which resulted in Remote Auth disappearing as an option on our account, so that may be complicating things.

BTW, we did receive an email on 8/23/12 w/ the title "Zendesk Remote Authentication Security Enhancements" that referenced a future deprecation of the old approach, but nothing since. 

@Dave -- love it when these things happen on a Friday afternoon! :(

May 17, 2013 11:57
User photo
Josh Roman
kokofitclub

Oh, and our ticket was submitted by Nick Konarski (Koko FitClub)

May 17, 2013 12:29
User photo
Brandon K.
Zendesk

@Josh: It looks like your account was accidentally identified as inactive and we switched remote authentication off. Our development team has circled and re-enabled it on your account. Everything should be working for you right now, but let me know if it isn't. We're really sorry about causing this issue with you.

@Dave: It looks like your issue is being cause by a misunderstanding with the API. I'll follow up in the ticket I have with you.

May 17, 2013 12:30
User photo
Josh Roman
kokofitclub

@Brandon: nope, not working. Let's take this up on the ticket:  403323

May 17, 2013 12:37
User photo
Brandon K.
Zendesk

@Josh: Ok, thanks for letting me know. Our senior technical agent is taking a look at your ticket and should be able to work with you to find a resolution. Lets communicate through that ticket from now on so we don't accidentally miss any information. Thank you so much for your cooperation!

May 17, 2013 12:52
User photo
Josh Roman
kokofitclub

@Brandon & @Dave -- the "return_to" parameter is our issue as well. If we manually add it to the URL, we can get in. How do we get this added back?

 

May 17, 2013 13:05
User photo
Dave Fraleigh
thousandeyes

@Josh - we amended our internal code to make it an optional parameter and it works fine.  @Brandon - this is definitely a change introduced in the last 24 hours - and should be addressed.

May 17, 2013 13:48
User photo
Josh Roman
kokofitclub

@Dave -- thanks. While our devs were working on making the parameter optional, we tried just adding "?return_to=foo" to our Remote Login URL in the Zendesk control panel and it works -- Zendesk passes it back to us and we can get in. 

May 17, 2013 14:26
User photo
TJ Baker
joomlashack

We too found out that things were being deprecated by finding out users could no longer log in to support, and we're now scrambling to implement the JWT method.

May 20, 2013 11:40
User photo
Morten Primdahl
Zendesk

@TJ - for all intents and purposes, standard remote auth should be back to normal, there was a glitch due to mismatched expectations on the return_to parameter and how, specifically, IIS interprets HTTP parameters with no value, that has been fixed. Your case, I believe, is that you are running a very special setup which does not go the supported route, we're happy to help you transition to the proper setup as best we can.

Morten

 

May 20, 2013 11:56
User photo
TJ Baker
joomlashack

Thanks Morten.  Actually, I'd not checked today but it appears that things are back to working.  We will still work to incorporate the JWT method so we'll be up to date.

Sorry for my premature complaint ... we must have been bit by the temporary change as well.

Cheers

May 20, 2013 12:02
User photo
calos
techtorium47

Why return_to always 'https://xxx.zendesk.com/home'  with zendesk login by JWT ? 

May 20, 2013 20:53
User photo
Vasudevan.D
Hello,
I wanted to pass on our code and see if you can help point us in the right direction, please.
This is what we have
   public string SHARED_KEY = "...";
    var payload = new Dictionary<string, object>() {
                { "iat", (new DateTime()).ToLongTimeString() },
                { "jti", System.Guid.NewGuid()},
                 { "name", "Mani" },
                 { "email", "v.s.manivannan@gmail.com" }
                
            };
           
              string token = JWT.JsonWebToken.Encode(payload, SHARED_KEY, JWT.JwtHashAlgorithm.HS256);
string redirectUrl = "https://mygreenedesk.zendesk.com/access/jwt?jwt="+ token;
Response.Redirect(redirectUrl);
this keeps returning us back to our homepage
May 23, 2013 03:01
User photo
Morten Primdahl
Zendesk

Vasudevan, we'll help you out in a ticket - don't ever post your secret anywhere, please update it in your account.

May 23, 2013 09:24
User photo
Samuel Sweet
sweetsquared

So I only JUST set up SSO with Remote Authentication about 4 weeks ago. Had to temporarily disable to transfer ownership between accounts. Going back to re-enable it and the "old" version isn't available to select anymore?!? Am I missing something or is Zendesk now dead for me until I rewrite our SSO module?

 

I sure hope not. That would be seriously lame. 

May 28, 2013 03:50
User photo
Steve Elsner

So, we now have 90 days, but I missed the originating date of this time span. On what date do we absolutely have to have JWT set up?

I just need to prioritize this issue - not looking to do it at the last second. It's obviously no longer a blocker of other tasks *this week*.

May 28, 2013 07:36
User photo
Baptiste PAPINEAU
comptenickel

@Vasudevan :

 

DateTime origin = new DateTime(1970, 1, 1, 0, 0, 0, 0);
TimeSpan diff = DateTime.Now.ToUniversalTime() - origin;
double iat = Math.Floor(diff.TotalSeconds);

var payload = new Dictionary<string, object>() {
{ "iat", iat.ToString()},
{ "jti", System.Guid.NewGuid() },
{ "name", [the name] },
{ "email", [the email] }
};

May 28, 2013 07:43
User photo
Ben Rohrs
Product Manager

@Steve - We haven't made an official announcement yet, but will do this very soon in our forums. Once the announcement is made, you'll have 90 days to make the transition.

May 28, 2013 07:45
User photo
Alex Osipov
Os33

An issue we are having is remote auth allows embedding zendesk in an iframe and it's worked well for a long time.  Using JWT, the X-Frame-Options: SAMEORIGIN header is set and existing functionality has been broken.  

What do we do with this?  All of our customers access an intranet and have gotten pretty used to have an embedded iframe to look at existing tickets, submit new ones.

May 30, 2013 20:46
User photo
Thamara Hettiarachchi

Hi

Anyone try to do with C#

Thanks

June 04, 2013 03:28
User photo
Tadiraman
sasaki

Hi,

I tried this new code by having a generic handler(ashx) using c#. 

I can log in once & can logout, if I try to log in again I get an error message 'message=JWT+format+invalid.&kind=error'. Any ideas??

Any help would be appreciated!

-Thanks

Raj

 

June 04, 2013 14:15
User photo
Minal Gulabdas
sweetspotgroup

Hi, 

 

I am encountering the same issue as Tadiraman .

http://......../logout?message=JWT+format+invalid.&kind=error

 

Was working earlier today, but not any more.

June 05, 2013 01:28
User photo
Tarang

Hello Zendesk Team,

 

I am trying to implement SSO for Joomla, can you please guide me to progress on this.

 

Tarang

June 05, 2013 02:25
User photo
Admin
bintube

Hello Zendesk,

This change is putting a lot of burden on your combined user base for no significant benefit.

Why not just keep the old SSO working in addition to any new method you feel like implementing in the future???

 

 

June 05, 2013 09:27
User photo
Admin
bintube

Not feeling Zen at all about this.

June 05, 2013 09:28
User photo
Morten Primdahl
Zendesk

@Minal, @Tadiraman - most likely your tokens are out of sync, so sanity check that the token you've got in your code is the same as the one in Zendesk, and if not, generate a new one. We have improved the error messaging in this area and will ship that shortly.

@Tarang - maybe our PHP example is a good starting point https://github.com/zendesk/zendesk_jwt_sso_examples/blob/master/php...

@Admin - apologies for the pain, while remote auth has served us well for 5 years, it's time to move on to something that's driven by an actual standard and has wide community support, shoot us a ticket if there's anything we can do to better help you switch implementation.

 

June 05, 2013 10:04
User photo
Ian Weatherhogg
refractiv

Trying out SSO for the first time, and also getting:

 

https://......../logout?message=JWT+format+invalid.&kind=error

June 05, 2013 10:21
User photo
tylerc

Can you please clarify where the payload needs to be sent to?

In the example, it's here:

https://example.zendesk.com/access/jwt?jwt=#{payload}

However, the return_to value passed to our API is:

http://example.zendesk.com/home

The return_to is http, not https and is to /home, not /access/jwt. Where should we send the payload?

June 05, 2013 10:48
User photo
Morten Primdahl
Zendesk

@Ian - check that your tokens are in sync, we're shipping a better error message later today

@Tyler - the return_to parameter merely states where to direct the user being authenticated once authentication passes

June 05, 2013 10:52
User photo
tylerc

@Morten - Thanks for the quick reply. I'll admit, I'm still not quite clear on return_to. Do we just package it along with the payload (to /access/jwt) and Zendesk handles that redirect? Or is that where we send the payload?

It would be great to get this properly documented up top. The only mentions of this are in the comments.

June 05, 2013 12:13
User photo
Tadiraman
sasaki

@Morten: Thanks, it was the key which was out of sync as you were saying!

June 05, 2013 12:25
User photo
Morten Primdahl
Zendesk

@Tyler - you should always send the payload to the /access/jwt?jwt=payload_goes_here end point, and then optionally, also send a return_to parameter value - e.g. /access/jwt?jwt=payload_goes_here&return_to=https://example.zendesk.com/home - we send a return_to value to your script when we redirect there, I recommend just reusing that as a parameter in the URL you redirect the user back to on our end. Will look into clarifying this.

@Tadiraman - glad to hear, we've just shipped the improved error message for this case

June 05, 2013 12:47
User photo
Tadiraman
sasaki

@Morten: So if an error occurs does the message will be part of the url as we see before. Or is there a better logging mechanism you advice? 

 

June 05, 2013 14:23
User photo
Morten Primdahl
Zendesk

@Tadiraman - if Zendesk cannot complete the login, it will redirect back to the logout URL you specify and pass two parameters "message" and "kind". If "kind=error" then there's a problem and the "message" parameter will have a message elaborating the issue, e.g. the new signature verification error message "JWT signature invalid. The signature cannot be verified, check that your tokens match".

I'll get this into the docs ASAP.

June 05, 2013 14:30
User photo
Ian Weatherhogg
refractiv

Actually i think that was because the example redirection code assumes [subdomain].zendesk.com, and we're using a custom domain.

June 06, 2013 04:02
User photo
Emilio Davis

Hi, we are using grails in our site. The implementation is pretty simple and based on the java servlet sample posted on github, but when I try to login I get "Error desconocido al iniciar sesión." (the site is in spanish I guess is something like Unknown error while logging in). Is there a debug flag or something we can use to track down the problem? We used 

compile 'com.nimbusds:nimbus-jose-jwt:2.16'

for the dependencies and the code is:

 

def sso = {

 

JWTClaimsSet jwtClaims = new JWTClaimsSet();

jwtClaims.setIssueTime(new Date())

jwtClaims.setJWTID(UUID.randomUUID().toString())

jwtClaims.setCustomClaim("name", "${fullName}")

jwtClaims.setCustomClaim("email", "${email}")

jwtClaims.setCustomClaim("external_id", "${id}")

jwtClaims.setCustomClaim("remote_photo_url", "${picture_url}")

// Create JWS header with HS256 algorithm

JWSHeader header = new JWSHeader(JWSAlgorithm.HS256);

header.setContentType("text/plain")

 

// Create JWS object

JWSObject jwsObject = new JWSObject(header, new Payload(jwtClaims.toJSONObject()))

 

// Create HMAC signer

String secret = "${grailsApplication.config.zendesk.secret}"

JWSSigner signer = new MACSigner(secret.getBytes())

 

try {

  jwsObject.sign(signer);

} catch(com.nimbusds.jose.JOSEException e) {

  System.err.println("Error signing JWT: " + e.getMessage())

  return;

}

 

// Serialise to JWT compact form

String jwtString = jwsObject.serialize();

 

response.sendRedirect("https://${grailsApplication.config.zendesk.domain}.zendesk.com/access/jwt?jwt=" + jwtString)

}

 

 

June 06, 2013 05:55
User photo
Tadiraman
sasaki

@Morten: Thanks a lot!

June 06, 2013 07:29
User photo
Andrew Webb
statpro

In the request for authentication, you include the following query strings:-

  • locale_id = 1
  • return_to = https://<myhostname>.zendesk.com/home
  • timestamp = 1370528310

I'm currently appending these query strings to the end of the URI I redirect to when I provide you with a JWT (i.e. <blah>/access/jwt?jwt=<token>).

Is that okay?

 

June 06, 2013 07:40
User photo
Morten Primdahl
Zendesk

@Emilio - please submit a ticket and it will get passed to engineering who can help take a look

@Andrew - yep that's fine, strictly you don't need to but it's safe

June 06, 2013 11:01
User photo
Sanchez, Juan
fmb

so looks like my Remote Auth has stopped working before i could setup JWT........ i received an email stating that would work until September.

June 06, 2013 20:36
User photo
Thamara Hettiarachchi

Hi Zendesk,

After i have enable SSO. Now can't access zendesk support page to non logged in users.
https://support.companyname.com/

Thanks

June 07, 2013 00:05
User photo
Craig Reilly

So I tried to do this using the files here: https://github.com/zendesk/zendesk_jwt_sso_examples

I get this error:

Microsoft VBScript runtime error '800a01a8'
Object required: 'aKeys'
/zendesk_auth/classic_asp_jwt_with_ad.asp, line 71

June 10, 2013 11:25
User photo
Morten Primdahl
Zendesk

@Craig - did you use the zipped up bundle? If so, we released a new one just a couple of days ago that you should update to if you haven't already. If you used the file straight from the repository, then submit a ticket and we can help work through the issue.

June 10, 2013 11:36
User photo
Craig Reilly

I commented the DEBUG lines (3 of them) and it is now working.

I have now downlaoded the iPhone app - but can not seem to login. Does htis require a different login?

June 10, 2013 11:37
User photo
Craig Reilly

So - I do have the latest version from github.

 

 

June 10, 2013 11:40
User photo
Beresford Hare
realjourneys

FYI, I downloaded the latest bundle and am having the same error.

June 11, 2013 16:01
User photo
Beresford Hare
realjourneys

I think I found the problem, change

For i = 0 To aKeys.Count-1 to

For i = 0 To dAttributes.Count-1

Patch submitted to Github

June 11, 2013 18:22
User photo
Morten Primdahl
Zendesk

@Beresford - many thanks, merged in and bundle updated

June 11, 2013 18:32
User photo
Bob Gregory

The claim names for everything other than iat and jti ought to be URIs since they're public claims. I'm the maintainer of a JWT package, and my company need to implement JWT-based authentication , but I'm going to to have to change some of the code paths. Irksome.

 

See http://tools.ietf.org/html/draft-jones-json-web-token-10#section-4.2

June 24, 2013 08:11
User photo
Craig Reilly

So I am using this process for my SSO to Zendesk now. However, I notice if I have IE open with several tabs and hit LogOut - that when I come back it does not make me reauthenticate. I must actually close the Browser entirely.

The LogOut is misleading and is actually mroe of a "Home" button as it takes them to our Intranet homepage.

 

June 24, 2013 08:37
User photo
Craig Reilly

Beresford Hare, thanks. That fixed it...

June 24, 2013 08:40
User photo
Steven Davidovitz
Zendesk

@Bob In my opinion, since the JWT authentication is only between Zendesk and our customers we do not have to comply with section 4.2, but rather section 4.3 which allows arbitrary keys. If you'd like to discuss this further, or would like some help modifying your library please feel free to email me directly.

June 24, 2013 11:17
User photo
Shyam Raghuvanshi

Hi Zendesk,

I am trying the Sample for C# and getting redirected back to logout page.

 DateTime origin = new DateTime(1970, 1, 1, 0, 0, 0, 0); //1372246181
        TimeSpan diff = DateTime.Now.ToUniversalTime() - origin;
        double iat = Math.Floor(diff.TotalSeconds);
        var payload = new Dictionary<string, object>() {
                { "iat", iat },
                { "jti", System.Guid.NewGuid() },
                { "name", name },
                { "email", email }
              };

        string token = JWT.JsonWebToken.Encode(payload, SHARED_KEY, JWT.JwtHashAlgorithm.HS256);
        string redirectUrl = "https://" + SUBDOMAIN + ".zendesk.com/access/jwt?jwt=" + token + "&return_to=" + returnTo;
        HttpContext.Current.Response.Redirect(redirectUrl);

Can anybody help in the successful implementation.

Regards

Shyam

 

 

 

 

June 26, 2013 04:53
User photo
Morten Primdahl
Zendesk

Hi Shyam, if you get redirected to the logout URL on your side, then there's also a "message" parameter in that URL which will tell you what went wrong. If you cannot find that, then please submit a ticket and we can dig into our logs and help find the root cause. The message in the URL will typically let you know if your clock is drifting or the JWT format is off.

Best,

Morten

June 26, 2013 05:18
User photo
Shyam Raghuvanshi

Thanks Morten,

I when directly run the redirect url gettting the following message. message=JWT+signature+invalid.+The+signature+cannot+be+verified%2C+check+that+your+tokens+match&kind=error

Let me know where can I open a support ticket.

Regards

Shyam

June 26, 2013 05:51
User photo
Morten Primdahl
Zendesk

Shyam you can send an email to support@zendesk.com and it will get escalated to the appropriate engineers. You should of course sanity check that you use the same token as you have configured in Zendesk like the message suggests.

Morten

 

June 26, 2013 05:55
User photo
Shyam Raghuvanshi

Thanks Morten,

I am contacting support. Yes I am using similar configuration.

Regards

Shyam

June 26, 2013 05:59
User photo
Tadiraman
sasaki

Hi Morten,

After logging in, the username is displayed instead of full name(but the old script  displayed full name). What it does is it overwrites the full name field in the zendesk ui, even if we tried to change it overwrites. 

-Thanks

Raj

June 27, 2013 10:30
User photo
Shyam Raghuvanshi

@Morten It is working now.

Thanks

Regards

Shyam

June 27, 2013 23:46
User photo
Rainer Neumann
secunite

Hi Zendesk,

I face the same problem Shyam described above (signature cannot be verified)  - so I created a support ticket containing the Request. However, since I am only using the basic plan, support kept redirecting me to this forum.

Can anybody please help me with this issue?

Regards

Rainer

July 02, 2013 03:48
User photo
Shyam Raghuvanshi

@Rainer It is working when I set it on production server.

Please try there.

Regards

Shyam

 

July 02, 2013 05:28
User photo
An Yang
pertino

Hi Zendesk, is there any ways that I can encode and decode JWT in javascript (pure client side, without node.js)? 

Couldn't find any resources or examples related. 

July 02, 2013 10:22
User photo
Steven Davidovitz
Zendesk

An, have you tried Mozilla's implementation?

July 02, 2013 10:31
User photo
Rainer Neumann
secunite

@Shyam: Thanks for the quick response, but I already tried that. It still does not work...

July 02, 2013 11:29
User photo
An Yang
pertino

@Steven, that one is also a node.js module I believe. It's not pure client side. What I want to do is to grab the return_to param from Zendesk in my client side script, handle the authentication and then send the information back to Zendesk in JWT. It should be done all on client side. 

July 02, 2013 12:29
User photo
Rainer Neumann
secunite

@Shyam: Finally I got it running - the problem was indeed an invalid token deriving from some encoding/encryption in the key store we used...

 

July 02, 2013 14:07
User photo
Steven Davidovitz
Zendesk

@An, we do not recommend using encrypting JWTs client side as the shared key would then be exposed leading to a possible compromise.

July 02, 2013 14:17
User photo
An Yang
pertino

@Steven, Thanks for your message. We might go ahead and try the other route.

July 02, 2013 14:19
User photo
Ian Weatherhogg
refractiv

When we send a user across using SSO, in the top right there's a Change Password link, which doesn't make any sense - the user doesn't have a password on our Zendesk - only on the site they started out from.

July 03, 2013 04:34
User photo
Vedad KAJTAZ
kigo

Blindly following return_to is IMHO a huge security risk, as sensitive user information (external_id, name, email, tags) may be exposed to a malicious website.

July 08, 2013 10:06
User photo
Jeremy
Zendesk

@Vedad I'm not sure which return_to you're referring to, but neither of these are blind:

1) The user is redirected to the remote login URL configured for the SSO settings (for example, https://mycompany.com/zendesk/sso).
2) You redirect the customer to the Zendesk endpoint at https://mycompany.zendesk.com/access/jwt with the JWT payload.

#1 is configured in Zendesk and user must be an Admin to configure
#2 is configured by the customer on their server and it's written into the script, not passed by a 3rd-party

July 09, 2013 11:07
User photo
Jacob Mattison
technolutions

Is there a way to set the ticket_restriction value for a user (i.e. the setting displayed on the user page as "access") when logging them in via single sign-on? We're creating our end users simply by having them sign in, but we want them all to have ticket_restriction set to "organization".

July 10, 2013 08:11
User photo
Mattias Ljung
Zendesk

@Jacob Unfortunately that value is not an accepted part of the SSO payload, so there is no way to do it within the SSO framework.

You could add something script-wise where you authenticate, and then pause the script before redirecting back to Zendesk, and then run a search for the userID based upon their external ID, and then modify that value for the newly created user, and finally complete the redirect back into Zendesk. This would probably cause a significant delay in your SSO script, and would be an unsupported level of customization, but it is theoretically possible. Another thing to keep in mind is that your SSO cannot create organizations, so this would probably be better managed at the organization level as opposed to the user level.

July 12, 2013 08:21
User photo
Julie Heinrich
edrnet

We are trying to setup JWT for our Zendesk and need some help.  We are using the ASP authentication script for IIS/AD. I have downloaded the script and it looks very similar to the script that we are currently using for Zendesk Authentication.  After modifying the script, do we just need to replace the current script with the new JWT script?  Also, what do we use for the SubDomain entry in the script?  Any help would be greatly appreciated.  I am not very familiar with scripting and am trying to limp my way through setting this up.  Thank you!!

July 31, 2013 06:56
User photo
Forrest

Anyone trying this with ColdFusion?  I need to start tackling this before the final switch is made.  Are there any code examples for CF out there?

July 31, 2013 09:30
User photo
Jeremiah
Zendesk

@Julie,

Thanks for reaching out! We've created a ticket on your behalf using your email address as the requester. Let's continue the conversation in the ticket.

July 31, 2013 11:12
User photo
Wouter Luyten
luyten

Does anyone have a complete code sample for c#? This would be a big help...

July 31, 2013 11:15
User photo
Matt Sirianni
Zendesk

Forest: I'm not aware of any ColdFusion code examples, but hopefully someone from our community can provide one!

Wouter: We do indeed provide a code sample for a C# handler! You can find it here: https://github.com/zendesk/zendesk_jwt_sso_examples/blob/master/c_sharp_handler.cs

August 01, 2013 11:16
User photo
Siddesh S Bhalke

Hello Anton de Young,

I am integrating this using PHP everything is fine,

I just want to ask you one thing, how does we need users to go log into our system and zendesk,

Here is details:

        1.How does process should work, whenever users log into our system its is logging into my system dashboard, but when i add "header redirect url then only it will go to zendesk ", so i have one dout how can we make user to post ticket on zendesk without making him to redirect  , Do we need to give him a button once he logs into our system to redirect him to his zendesk page ?? 

 

August 13, 2013 05:18
User photo
adk

I have a question about how to go about calling the zendesk code block. I am working in c# using 3.5 framework. The code sample from github is in my Help.aspx.cs page.  However, how would I call the Zendesk.JWTLogin routine on my Page_Load event?

August 13, 2013 13:09
User photo
adk

follow up to my previous post, the code on my Page_Load event is:  

JWTLogin jwtLogin = new JWTLogin();
jwtLogin.ProcessRequest(httpContextValue);  

My question would be.... what is the parameter being passed to ProcessRequest function?

August 13, 2013 14:01
User photo
Jeremiah
Zendesk

@Siddesh / @adk - I've created tickets for each of you to help out here - let's continue our conversations there.

August 14, 2013 09:22
User photo
TnSFic Admin
tnsfic

How do we handle users changing email addresses?  I'm passing a unique_id with the login, and I can see their uinque_id when I view the user in zendesk.  But if a user changes their email address on our end, then tries to log into zendesk, they are being passed over to our login page, I'm assuming because the there's an email address mis-match.  I guess I also assumed the point of passing a unique_id would tell zendesk to check that unique_id against users in zendesk and auto update their email address and log them in.  Since that's not happening, do I have to use the API to update the email address in zendesk when the user updates their email address on my side?

August 14, 2013 09:33
User photo
Steve Elsner

I'm using the PHP example, and wind up getting an error "Failed to create user:  Identities is invalid".

I've checked, and double checked, the shared secret. The JWT being generated appears to be valid - I've tested this by eavesdropping on the HTTP request and checking the JWT string against the PyJWT library's decode() function.

What, precisely, could this error message indicate?

August 14, 2013 10:28
User photo
Steve Elsner

Update on my last comment - it seems that we were unnecessarily urlencoding some of the data being assembled into the token before using the JWT encode method.

I suspect the failure was with the data not being the way Zendesk expected it, rather than a failure with the signature. This would explain my good test results with PyJWT.

My question stands, though - what exactly does that error message really mean? Could be documented a bit better, IMO.

August 14, 2013 12:16
User photo
Joey Hedrick

It would be very nice to at least be given the option of having Zendesk redirect the authentication request to a clean URL.  Our rewrite engine is configured to strip query strings for a variety of reasons, and while we can change our engine to preserve these, we really prefer not to modify our setup for a single case.  For example:

August 23, 2013 21:41
User photo
Marci Abraham
nrocnetwork

Anyone want to help me backport the Drupal 7 JSON module to Drupal 6 ??

August 26, 2013 16:30
User photo
Marci Abraham
nrocnetwork

I'm trying to figure out the PHP implementation, and integrate it into the Drupal 6 module here

In the PHP code, the comment says:

Using JWT from PHP requires you to first either install the JWT PEAR package from
http://pear.php.net/pepr/pepr-proposal-show.php?id=688 or get the JWT project
from https://github.com/firebase/php-jwt on GitHub.

But that package has a "rejected" status, and comments make it sound unfinished.

I'm a little hesitant to ask my IT guys to install it ... does anyone have experience with it? 

August 27, 2013 14:15
User photo
Marci Abraham
nrocnetwork

Whoops.....that ol' itchy trigger finger got away from me.

The Drupal mod is here: https://drupal.org/project/zendesk

Specifically the one for Drupal 6, not 7. 

August 27, 2013 14:18