JWT not working?
John,
I'm going to move this post to a more appropriate topic so it can get the appropriate attention. Thanks
Dan
Hi John,
There must be something different between the two calls for one to fail and the other to succeed. Can you check the payload from a user authenticating from the white label version and make sure that this is a fresh browser session so there aren't any cookies shared from your dev version?
Hey Bob,
To be clear all of the testing is happening in development, not production. So if I go to default.dev.testnotice.com (local development, non-whitelabel) and click "Support" then click "Login" in Zendesk it redirects back to default.dev.testnotice.com, which checks the cookies, sets the session ID, etc. and then confirms authentication. If auth succeeds, we construct the JWT and redirect back and Zendesk responds accordingly and we log in
The *exact* same process being done from a white-label (local development) and we execute the exact same code. This time however the cookie and session set a different context on our end. When we redirect to Zendesk we are greeted with an infinite refresh on unauthenticated that eventually blocks all auth (too many auth attempts). I've attached a screenshot of the screen we see.
The only things that are different in our JWT between the two portals is external-id (which is a json string that contains pieces that include the context and user ID for that context), organization name.
I'll try to log our end really verbosely and see if I can see anything weird or fishy.
I figured it out, finally. And it was a stupid thing.
Basically the issue was the actual user being used to sign in and not JWT at all. In my non-whitelabel portal I was using something like john@example.com as a username. In my whitelabel portal I was using admin@testnotice.com.
The problem is that my Zendesk is set up to using Google Authentication for @testnotice.com domains it seems. So auth would fail but we'd keep trying. Adding a line of code to check the domain of the e-mail address (and redirecting the user to the Google SSO with Zendesk if that was the case) seems to have solved the problem.
Login to the community
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Hello,
First let me say that I understand Zendesk has a multibrand add-on. While we are a multi-brand software package we aren't interested necessarily in having each portal have their own branded support channel. It's a good thing(tm) for us to handle support across all brands even if each portal gets their own white label.
We have a whitelabel product we would like to do SSO for, because each of our customers can access the Zendesk help portal from each white-label portal. I.e.
demo.testnotice.com <- White label
www.testnotice.com <- "Our" version
We are trying to implement SSO in development and it works great for "our" version:
default.dev.testnotice.com (local dev, works great)
bcprobation.dev.testntoice.com (doesn't work)
The way we've implemented this is as follows:
1) We store an encrypted cookie for *.testnotice.com on the user's computer that indicates which portal they last visited. I.e. bcprobation.dev.testnotice.com as well as the session ID of their session in that portal.
2) When the user goes to support and Zendesk sends them to us for SSO (always to "our" endpoint) and to get the JWT. We decrypt this cookie, set the proper context on our end, and determine if the session is authenticated or not. If it isn't we redirect them to the portal's login page -- otherwise we construct the JWT token and send the user back to Zendesk with it.
For "our" version in dev (default.dev.testnotice.com) this works great and the user is logged in. For a whitelabel version (bcprobation.dev.testnotice.com) Zendesk seems to get stuck in an infinite redirect loop where authentication always fails. As far as I can tell Zendesk shouldn't even be aware there is any difference because all of the communication happens through a single endpoint.
Is there some restriction here I'm missing or some other explanation why this wouldn't be working?
John