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 JSON Web Token (JWT), a user is automatically verified with the identity provider when they sign in. The user is then allowed to access Zendesk without being prompted to enter separate sign-in credentials.
As a Zendesk admin, your role consists of enabling the SSO options. This article describes how to enable multiple JWT single sign-on configurations that can be used to authenticate team members (admins and agents, including light agents and contributors), end users, or both.
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 JWT to secure the exchange of user authentication data.
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:
Related articles:
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:
- 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.
- Zendesk tries to determine whether the unauthenticated user is an end user or team member and redirects the user to your organization's appropriate remote sign-in page. Example: https://mycompany.com/zendesk/sso.
- A script on the remote server authenticates the user using your organization's proprietary sign-in process.
- The authentication system builds a JWT request that contains the relevant user data.
- The authentication system redirects the user to the following Zendesk endpoint with
the JWT payload:
https://yoursubdomain.zendesk.com/access/jwt
- Zendesk verifies the token and then parses the user details from the JWT payload and 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 the IT team) to make sure that Zendesk-bound traffic is over HTTPS, not HTTP.
- 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.
The IT team may require additional information from Zendesk to configure the JWT implementation. Refer them to the Technical implementation worksheet in this article.
After you've confirmed that you meet the requirements and have all of the necessary information, you're ready to enable JWT SSO.
Enabling JWT SSO
Admins can enable JWT single sign-on only for end users, only for team members (including light agents and contributors), or for both groups. You can create multiple JWT SSO configurations. Before you start, obtain the required information from your company's IT team. See Requirements for enabling JWT SSO.
To enable JWT single sign-on
- In Admin Center, click
Account in the sidebar, then select Security > Single sign-on.
- Click Create SSO configuration then select JSON Web Token.
- Enter a unique Configuration name.
- For Remote Login URL, enter the URL where your users 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.
- (Optional) For Remote Logout URL, a logout URL where users should be redirected
after they sign out of Zendesk.
Zendesk automatically adds email, external_id, and brand_id parameters to the logout URL. If you prefer not to have 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 must amend the logout URL to use blank parameters before the hash. For example,https://somedomain.com/?brand_id=&return_to=&email=#/zendesk-login/
. - (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.
- If you use external IDs for your users, you can update these in Zendesk Support by selecting On for Update of external ids?.
- Provide the Shared secret to your IT team. They'll need it for their JWT
implementation. Important: Keep the shared secret safe. If it's compromised, all the data in your Support account is at risk.
- Select Show button when users sign in to add a Continue with SSO button
to the Zendesk sign-in page.
You can customize the button label by entering a value in the Button name field. Custom button labels are useful if you add multiple SSO buttons to the sign-in page. See Adding "Continue with SSO" buttons to the Zendesk sign-in page for more information.
- Click Save.
By default, enterprise SSO configurations are inactive. You must assign the SSO configuration to users to activate it.
Assigning JWT SSO to users
After creating your JWT SSO configuration, you must activate it by assigning it to end users, team members, or both.
To assign an SSO configuration to team members or end users
- Open the Security settings for team members or end users.
- In Admin Center, click
Account in the sidebar, then select Security > Team member authentication.
- In Admin Center, click
Account in the sidebar, then select Security > End user authentication.
- In Admin Center, click
- Select External authentication to show the authentication options.
- Select the name(s) of the SSO configuration(s) you want to use.
Single sign-on might not cover all use cases, so Zendesk authentication remains active by default.
- Select how you'd like to allow users to sign in.
Let them choose allows users to sign in using any active authentication method. See Giving users different ways to sign into Zendesk.
Redirect to SSO only allows users to authenticate using the primary SSO configuration. Users don’t see additional sign-in options, even if those authentication options are active. When you select Redirect to SSO, the Primary SSO field appears for you to select the primary SSO configuration.
- Click Save.
Managing users in Zendesk after enabling JWT SSO
After enabling JWT single sign-on in Zendesk, changes made to users outside Zendesk don't automatically sync to your Zendesk account. Users are updated in Zendesk at the point of authentication. For example, if a user is added to your internal system, the user is added to your Zendesk account when they sign in to Zendesk. If a user is deleted from your internal system, the user will no longer be able to sign in to Zendesk. However, their account will still exist in Zendesk.
By default, the only user data stored in Zendesk when single sign-on is enabled is the user's name and email address. Zendesk does not store passwords. As a result, you should turn off any automated email notifications from Zendesk about passwords.
To provide a better customer experience, you might want to store more than just the user's name and email address in Zendesk. You can do this using additional JWT attributes.
Turning off password notification emails from Zendesk
A Zendesk user profile is created for any new user who accesses your Zendesk account through SAML, JWT, or OpenID Connect (OIDC) single sign-on. Because users are authenticated through an IdP with a non-Zendesk password, the profile is created without a password because they don't need to sign in to Zendesk directly.
Because new users who sign in to Zendesk through SSO are verified through an IdP, they don't receive email notifications to verify their account. However, it is still recommended to turn off these automated email notifications to prevent them from being sent if the IdP does not successfully verify the user. In the case of SSO, user verification must always occur through the IdP.
To turn off password notification emails
- In Admin Center, click
People in the sidebar, then select Configuration > End users.
- In the Account emails section, deselect Also send a welcome email when a new user is created by an agent or administrator.
- In Allow users to change their password, deselect this option.
Generating a new shared secret
In some cases, like if your secret is compromised, you may need to issue a new JWT shared secret and provide it to your IT team or external identity provider. You can generate a new JWT shared secret from Zendesk Admin Center. This action will create a new secret and invalidate the old one. You'll need to inform your IT team or external identify provider of your new shared secret to keep Zendesk SSO account authentication working.
To generate a new shared secret
- In Admin Center, click
Account in the sidebar, then select Security > Single sign-on.
- Hover over the JWT configuration you want to create a new shared secret for, then click
the option menu icon (
) and select Edit.
- Scroll to Shared secret at the bottom of the configuration page and click
Reset secret.
A confirmation message appears.
- Click Reset secret to confirm the reset.
You should see a new Shared secret in plain text.
- Click Copy to make a copy of the new shared secret and give it to your IT team or your external identity provider.
- Save your changes.
Switching authentication methods
If you use a third-party SSO method to create and authenticate users in Zendesk and then switch to Zendesk authentication, these users will not have a password available for login. To gain access, ask these users to reset their passwords from the Zendesk sign-in page.
Additional information about JWT
JWT is an 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. The string is Base64 encoded and then JWT makes an HMAC of the Base64 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.
Topics covered:
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.
Zendesk JWT endpoint
After successfully authenticating the user, create the JWT payload and submit a POST request that contains the JWT payload to the following Zendesk endpoint:
https://yoursubdomain.zendesk.com/access/jwt
The payload must be base64-encoded and submitted via a form submission from a client. Submitting the payload with a client-side AJAX, fetch, or axios request won't work because the request will be blocked by the client's same-origin policy. Making a POST request from your server won't work either because it won't correctly set cookies used for authentication on the user's browser.
The JWT payload must be sent to your Zendesk Support subdomain using the https protocol. Example:
https://yoursubdomain.zendesk.com/access/jwt
Host-mapped subdomains are not supported.
JWT attributes
Send JWT attributes using a hash (Ruby) or dictionary (Python). The JWT must be encoded as base64. Example using Ruby:
payload = JWT.encode({
:email => "bob@example.com", :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.
Attribute | Data type | Description |
---|---|---|
iat | Numeric date | 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 | string | JSON Web Token ID. A unique id for the token, used by Zendesk to prevent token replay attacks. |
string | Email of the user being signed in, used to uniquely identify the user record in Zendesk Support. | |
name | string | The name of this user. The user in Zendesk Support will be created or updated in accordance with this. |
Attribute | Data type | Description |
---|---|---|
external_id | string | 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) |
integer | The locale in Zendesk Support, specified as a number. |
organization | string | The name of an organization to add the user to. If the option Allow users to belong to multiple organizations is enabled, additional organizations append the original organization, and are considered secondary organizations. This does not delete the existing memberships. If you'd like to pass multiple organization names at the same time, use the organizations attribute instead. The organization names must be passed in a string, separated by commas. |
organization_id | integer | The organization's external ID in the Zendesk API. If both
organization and organization_id are supplied, organization is ignored. If the option Allow users to belong to multiple organizations is enabled, additional organizations append the original organization, and are considered secondary organizations. This does not delete the existing memberships. If you'd like to pass multiple organization IDs at the same time, use the organization_ids attribute instead. The organization IDs must be passed in a string, separated by commas. |
phone | string | A phone number, specified as a string. The phone number should comply with the E.164 international telephone numbering plan. Example: +15551234567. E164 numbers are international numbers with a country dial prefix, usually an area code and a subscriber number. A valid E.164 phone number must include a country calling code. |
tags | array | 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 | string | URL for a photo to set on the user profile. |
role | string | The user's role. This value can be set to end_user, agent, or admin. The default is end_user. If the user's role differs from the one in Zendesk Support, the role is changed in Zendesk Support. |
custom_role_id | integer | Applicable only if the role of the user is agent. |
user_fields | object |
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)
Whether you pass in the return_to
parameter or not is optional, but we
recommend it for the best user experience. When Zendesk redirects a user to your remote
login page, it can pass 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:
- 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
- Your authentication system takes the
return_to
parameter from the URL and, after successfully authenticating the user, appends it to the Zendesk JWT endpoint or adds it to the body of the request. Example:https://mycompany.zendesk.com/access/jwt?&return_to=https://mycompany.zendesk.com/tickets/123
- 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 URL for Help Center.
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 include clock drifts, rate limits being hit, and invalid tokens.
Form submission examples
The JWT payload must be submitted using a form submission from a browser to the following Zendesk endpoint:
https://yoursubdomain.zendesk.com/access/jwt
Zendesk provides a series of examples for various technology stacks in the Zendesk JWT SSO repository on GitHub. You must submit the JWT payload using a form submission from a browser to ensure cookies can be set correctly on the browser and that the request isn’t blocked by CORS.
Response
The response should be HTML with a 200 OK
status. The response format is
as follows:
<html><body>You are being <a href="">redirected</a>.</body></html>
If the href
matches your return_to
value, then the user
was successfully authenticated and cookies should be set. If the href
begins with https://SUBDOMAIN.zendesk.com/access/unauthenticated
, then
Zendesk was unable to authenticate the user.
JWT generation examples
The actual JWT encoding is straightforward and most modern languages have libraries that support it. Zendesk provides a series of examples for various stacks in the JWT SSO GitHub repository:
The JWT generation code is for your server implementation. You can pass the generated JWT back to your login page and then initiate the form submission from the browser.
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 Github.
82 comments
Dane
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
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
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
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:
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
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:
where ... = encoded payload..
If this stops to work next year then we'll be lost!
1
Javier DM
This change is in relation to the redirect, after successfuly authenticating the end-user. It's this portion here:
POST request
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)
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:
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
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
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.
2
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
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