Enabling JWT single sign-on

Return to top

68 Comments

  • Dane
    Zendesk Engineering
    Hi Naresh,
     
    I'll create a ticket for you to directly look into this one. Please wait for my update via email and let's continue from there. 
    0
  • Antoine Marjault

    Hello, can you provide documentation on errors? Like the list of possible errors and what they mean. For context, I'm having a lot of errors saying that the unique user identifier has been reused or that the user creation didn't work but I don't really know what to do with this information.

     

    Thank you,

    0
  • Cheeny Aban
    Zendesk Customer Care
    Hi Antoine M, 

    I created a ticket for you so we can further look into the issue that you have encountered with SSO. I'll wait for your reply 
    0
  • OllieJC

    I was having issues with new SSO users signing in and being redirected to the sign-out receiving an error message of "Users with the email address ... are not allowed to sign up for this help desk".

    The issue turned out to be the blocklist in the Admin > People > End users section.

    It'll be good to add a note here that the blocklist applies to new user accounts accessing via JWT as this wasn't intuitive (and the blocklist help text only mentions ticket creation).

    1
  • Kristie Sweeney
    Zendesk Documentation Team

    Thank you OllieJC for calling this out. I'll discuss with the product team and add a note to the documentation.

    0
  • Kristin Lisson

    Does the SSO process invoke when a user attempts to sign in (e.g., clicks "Sign in"), or does it invoke upon any visit to one of your pages (e.g., https://yoursubdomain.zendesk.com)?

    The documentation says, "Once you enable SSO, sign-in requests are routed to a sign-in page external to Zendesk Support." I assume the request here means that the user clicks "Sign In."

    However, the documentation also says, "1. An unauthenticated user navigates to your Zendesk Support URL. Example: https://yoursubdomain.zendesk.com/. The Zendesk SSO mechanism recognizes that SSO is enabled and that the user is not authenticated."

    I just wanted to make sure that articles can still be publicly accessible (no sign in required) if we enable enterprise SSO (JWT). Thanks!

    0
  • Brandon

    Hi there,

    Reading through this doc, I have a couple of questions.

    1) If I want to set up two SSO JWT configurations in a single zendesk instance, it sounds like ALL end users must use the same configuration. Is this correct? For example, if we have two authentication systems, one for a legacy app and one for a newer version of the same app, with each one producing a different authentication JWT, only one of the groups will be able to login?

    2) It is not clear to me how this system works. We authenticate users with an OIDC provider that produces a JWT that we use throughout our app. From this doc, it seems like that same JWT must support zendesk-required attributes in addition to the attributes we already have on our JWT for our own purposes. Is this correct?

    0
  • Anton Korotkov

    Hello Zendesk Support!

    I have an issue on your side that prevents me from implementing SSO on React app with HashRouter.

    I have URL like this: `https://localhost:3000/#/sso/zendesk` for both SSO Login and SSO Logout.

    Everything works fine until an error appears. Let's say JWT is wrong. In this case Zendesk redirects me to the SSO Logout URL. Here the thing - when it does it, for some reason it URLEncodes my hash route and redirects the user to something like:

    `https://localhost:3000/?kind=error&message=JWT+signature+invalid.+The+signature+cannot+be+verified%2C+check+that+your+tokens+match%23%2Fsso%2Fzendesk`

    So no more hash route in the URL so the app does not recognize the route. This is only happening when kind=error.

    Seems like a bug? Any thoughts? 

    0
  • Martin Carew

    is there any reason why it is not possible to update a users iana_time_zone at login by including it in the JWT? This is really frustrating as we hold all this info in our own databases but all users are placed in the same one as the company which is not great when your users/customers are in over 150 countries worldwide.

    1
  • Nara
    Zendesk Customer Care
    Hi Martin, if you would like to pass user info related to timezone, you could pass a locale value in the payload, or, if you are trying to pass a different attribute, you would need to pass it as a custom user field. In case it can help, more info on the payloads themselves can be found here.
    0
  • Yohan Aloka

    Hi,

    I'm currently working on a SSO setup with firebase authentication.

    I'm getting an error when going to the login page via the "Continue with SSO" button.

    If I change the "End user authentication" > "How end users sign in" to "Redirect to SSO" option. everything works fine.

     

    Thank you,

    Yohan

    0
  • Dipti Deshpande

    Hi Zendesk support,

    On SSOing to Zendesk as an Agent, Zendesk creates a Team member as "Legacy Agent" by default and then there is a need to assign a specific custom Role by Admin. Legacy Agent is treated by Zendesk just like an Admin, except role management. 

    Is there a way, that instead of Legacy Agent, Zendesk assigns it as Light Agent or a custom Role by default, any config to do this?

    Thanks for your help.

    0
  • abhishek sen

    Hi team, is it safe to send JWT token in the parameter like that? Why not allow the JWT token to be part of the header instead.

    Google Bard on sharing JWT token as HTTP parameter:

    JWT tokens are designed to be secure, but they can be vulnerable if they are not transmitted securely. When a JWT token is sent as an HTTP parameter, it is exposed to the following risks:

    • Interception: The token could be intercepted by a malicious actor who is monitoring the network traffic.
    • Replay: The token could be replayed by an attacker to gain unauthorized access to the system.
    • Caching: The token could be cached by a proxy server or a web browser, which could allow an attacker to access it later.
    0
  • user1001

    Hi,

    I would like to suggest to make the required JWT attribute "name" to be optional.

    The reason is that I got a complaint from a customer that when he changes an agent user name and the agent does a SSO login the name changes back to the original once since we are using an outdated name from our side (but actually, having the name out of sync between zendesk and us is not relevant for us).

    To avoid this problem I am planning to change our SSO login processing to fetch the current user name by calling the Zendesk API and search by user email. But I would like to avoid this http request if possible. Also, there is a risk I get an old user name in case there is delay in the sync of the Zendesk DB.

    Alternatively I am considering setting a webhook to be notified of user name changes.

    But as you can see, all this could be avoided by having the JWT attribute "name" to be optional.

    Since the user could be unequivocally identified by the email, I think there would be no impact if this change is done.

    Or maybe you have some other suggestion.

     

    0
  • Brandon Noad

    Hi, I just received an email that the JWT SSO is switching from GET to POST

    Starting May 1, 2024, you will be required to use HTTP POST requests instead of HTTP GET requests to avoid problems signing in to Zendesk.

    This article does not have a lot of details about this new POST request. What is the expected response? Are any cookies required to be sent in the request?

    I have a feeling this change is not going to be compatible with our implementation.

    If you are worried about security, why not switch to an OIDC approach?

    0
  • Marco

    What??? We're not aware of any change in the SSO authentication method.. and we're NOT ready to change its implementation.

    Basically, our backends redirect the user to this URL:

    https://<subdomain>.zendesk.com/access/jwt?jwt=...&return_to=<target-url>

    where ... = encoded payload..

    If this stops to work next year then we'll be lost!

    1
  • Javier DM
    Zendesk Customer Care
    Hi there Brandon and Marco, hope you are doing great and had nice holidays.
     
    This change is in relation to the redirect, after successfuly authenticating the end-user. It's this portion here: 
    POST request
     

    Zendesk JWT endpoint

    After successfully authenticating the user, redirect the user using a POST request that contains the JWT payload, sent to the following Zendesk endpoint...

     
    Instead of making a GET request, like it was before this announcement, this request should be changed to a POST request. Nothing else should be modified, but if you need to follow up on this please create a ticket with our Support team, or let me know and I'll create one on your behafl.
     
    And Marco, what you describe should not affect you, only the type of request that is made after user authentication. And like just mentioned, let us know if you need more assistance with this and I'll create a ticket with the Support team.
     
    Best regards and wish you folks a great start of 2024.
    0
  • Marco

    Javier-DM

    I did a try the new procedure based on the (updated) examples you posted on the github. I was able to get it to work... however something is not quite right in my understanding...

    With the deprecated method (valid until May 2024).. I could run all code on backend side in order to:
    1. generate jwt string
    2. build sso redirect url including return_to url
    3. finally redirect to Zendesk

    eg. (in Python/Flask)

    jwt_string = jwt.encode(payload, ZENDESK_JWT_SSO_SECRET)
    sso_url = "https://SUBDOMAIN.zendesk.com/access/jwt?jwt=" + jwt_string + "&return_to=..."
    return redirect(sso_url)

    With the new method, all code have to be run inside the user’s browser as html/javascript code, including the Ajax call that is needed to get the jwt string from our backend (BTW: how to authenticate that ajax call?!?)

    I think something is still not clear to me... where is the value added?

    --- EDIT (2024 Jan 8th)

    in order to avoid the ajax call from the browser.. i think all the javascript code can be dynamically generated from the back-end as follows:

    jwt_string = jwt.encode(payload, ZENDESK_JWT_SSO_SECRET, algorithm="HS256", headers={"typ": "JWT"})
    action_url = "https://SUBDOMAIN.zendesk.com/access/jwt?return_to=..."

    sso_page = (
        '<form id="jwtForm" method="POST" action="'
        + action_url
        + '">'
        + '<input id="jwtInput" type="hidden" name="jwt" value="'
        + jwt_string
        + '" />'
        + "</form>"
        + '<script>window.onload = () => { document.forms["jwtForm"].submit(); };</script>'
    )

    return sso_page

     

    As I stated earlier, I don't like this solution.. but it works without a great impact.  Also, I added one javascript line to automatically submit the FORM data as soon as the page is fully loaded.. Hope this helps.

     

    5
  • Javier DM
    Zendesk Customer Care
    Hi there Marco, happy new year!
     
    Thanks for your follow up and the information provided. I've created a ticket on your behalf and will be assigning to the proper team so this gets revised.
     
    You will be notified about this ticket, so you can add more comments in case you have them.
    Best regards and wish you a great year ahead.
     
     
    0
  • Brandon Noad

    Javier-DM can you please create a ticket on my behalf as well. Thanks.

    0
  • Javier DM
    Zendesk Customer Care
    Hey Brandon, good day!

    I created a ticket for you already, please provide as much information as you can about your queries.
    Best regards.
    0
  • Tim Hurd

    Marco, you are not wrong. 

    What I can see from the examples on github is that they expect us to redirect to some page we create with a form that will then issue a POST request through an automated JavaScript submit. As far as I know this is a bit of a hack.

    Javier-DM  May I suggest you visit with your devs and talk to them about redirects through the HTTP status 307 and have them update the documents to talk about this. I think this might be a cleaner solution than using a form. However, the one drawback to this of course is that I think most browsers will pop up a dialog to confirm that they wish to resubmit their post to the new URL (I haven't confirmed this). Logging in this way could be a pain seeing the dialog every time. 

    Just to let you know, I am not a huge fan of this change and I think the hacky solution of needing a form submitted through JavaScript is not very good in my opinion. 

    3
  • k evintest

    I have the same concerns as Marco, Brandon, and Tim.  This will require an architecture change to our applications as the old method was a simple redirect, now we'd have to do the hack that Tim mentioned.  Is it possible to have an exception on a customer-level to this change, so that those that require GET can still use it, acknowledging the security concerns presented?  Or perhaps making a legacy endpoint that can still be used GET against?

    For reference, we are using the method as outlined in your examples on github for c_sharp_handler.cs, that have since been deleted: https://github.com/zendesk/zendesk_jwt_sso_examples/commit/3339d075bd4cf867fec143c92b4171f5895dbb90#diff-c287878c2272ec624c5287766edcb5c035c856bad1d361363ad87340e57cf388

     

    5
  • @perkhidmatantempatanservers.com

    thanks,now my account in github not access because my sms opt no not run

    -2
  • Jordan Shirkey

    Also weighing in here with the same concerns as Marco, Brandon, Tim, and k evintest above.  Ditto 100% for what k evintest has just commented; we are also using the method outlined in the now deleted c_sharp_handler.cs example, and are not excited about the prospect of having to refactor to use the client side Javascript form post hack.  We will be watching this comment thread in the hopes that Zendesk reconsiders this change based on the feedback here.  Thanks!

    0
  • Simran Khosla

    Just wanted to add to the chorus that we are also currently making this call through a server side GET so -- changing this to a front end javascript post is a pretty annoying addition for us. It's doable but keeping the legacy endpoint around would be a preferable solution for us as well. 

    1
  • Chandan

    Hi Team,

    I am trying to implement the new POST method way suggested in JAVA.
    But I have a question,

    1. What will be the response body and http status of the successful POST request

    2. https://SUBDOMAIN.zendesk.com/access/jwt without request body is giving http status 200. Is this correct?

    3. Is there any sample code for JAVA implementation

    1
  • Caroline Kello
    Zendesk Product Manager

    Hey folks, 

    I'm Caroline and my team's responsible for this change. Thanks for taking the time to leave your thoughts and feedback - unfortunately we're not going to grant exceptions or keep a legacy version of this implementation available. However, the team's going to look into what other solutions are available that'll result a smoother migration for customers that are impacted. I'll be back with an update once our investigation is completed which should be in a couple of weeks.

    Additionally, documentation and examples still exist here and here in Github, we just moved some folders around which is why the method appears to have been deleted. 

    -3
  • Chandan

    Hi Caroline,

    Can you please share a POSTMAN request for the updated POST request?

    1
  • Bogdan Wojcieszyk

    Any chance you could show a code sample with C# and HttpWebRequest object? I tried to make a call passing data in object which looked like this:

    { jwtInput = "token", return_to = "return to url"}

    but it did not work.

    1

Please sign in to leave a comment.

Powered by Zendesk