Enabling JWT single sign-on

Return to top


  • Nara
    Zendesk Customer Care
    Hi Raphael, if you're looking for general information on creating light agents within an account, you can find that information within the Setting Roles and Access in Zendesk article here. Otherwise, if you are looking to pass a light agent role via JWT, note that you can do so by passing the role parameter as agent while also passing the custom_role_id parameter to the id of your light agent role in the Admin Center. Cheers!
  • Naresh Aavula

    Hi Team,

    I working on replacing  https://myoldcompany.zendesk.com/api/v2/ api with  https://mynewcompany.zendesk.com/api/v2/

    the old api works with a specific zendesk login id and password being passed with basic authentication as an encypted format. To work with the new https://mynewcompany.zendesk.com/api/v2/,

    the same old login and password does not work for me, Should I need to change something here?

  • 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. 
  • 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,

  • 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 
  • 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).

  • 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.

  • 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!

  • 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?

  • 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:


    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? 

  • 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.

  • 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.
  • Yohan Aloka


    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,


  • 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.

  • 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.
  • user1001


    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.



Please sign in to leave a comment.

Powered by Zendesk