blak3r

You literally have to be kidding me right? ADD THIS.

It appears the jwt token is stored in an object in ```Session Storage.z2_sunco_widget_auth.jwt```

So, in the requests to our server we could include the users email, jwt, and the JTI.  The server would take the JTI and resign the payload.  If that payload matched the jwt supplied with the request then we could assume that the user was in fact the email provided to the request.

In terms of how to get the JTI, there are two approaches I see... 
1. Store the JTI in our user table each time a request is built... Con here is possible synchronization issues. For example, we were planning on having links in our product just include the jwt to avoid any perceived glitchy redirect behavior from enduser standpoint.  For example to go to /hc/article/103 our link would be https://subdomain.zendesk.com/jwt?jwt=&return_to=https://subdomain.zendesk.com/hc/article/103

2. Pass the JTI as a GET param in the return_to and store that to a cookie with custom Javascript code on each page template.  CON here is long urls look gross and add potential for user to bookmark a link with a JTI in it... Probably could mitigate this by updating the url.  

3. Get our helpdesk working on a subdomain of our domain.  Use https://support.mydomain.com instead of https://.zendesk.com and have our webapp set a cookie to root domain that the zendesk code could also see. Probably the best option.

Questions for you... is this z2_sunco_widget_auth a reliable key for the JWT token?  That sunco part is throwing me off.  Also, I'm not a JWT security specialist, I can't see why having the JTI exposed would be that insecure... given you can't sign a payload without the shared secret but maybe i'm missing something.  Feel free to DM me personally if you prefer.

Thanks Greg. Appreciate the link and the quick response. Maybe I can get a value that is set by the login to uniquely identify the session or something. I’ll hack around. I could provide a token in the return_to portion of the jwt flow. Then modify every page template to store that token in a cookie. And pass that along with server Ajax calls and of course have that same token stored in the user db for checking against. Or maybe just the primary entry point page and have it only work if they redirected there. I’ll sleep on it.

Greg Katechis - thanks for giving it some thought.  I suppose this would need to be accomplished with custom javascript to call an api endpoint we'd host that would then use the REST api and return the data back.  Blockers here: 1) simple documentation showing how to add javascript that invokes web requests to a third party server 2) Any tips on how we could authenticate on our server code that the user account is in fact authenticated... like if we had /api/getTickets?user= we need to verify the user is in fact logged into zendesk somehow so they couldn't exploit the api to get other peoples tickets. 

My Activities has `{{requests}}` template variable on it.  The Home Page does not.  Is there a simple way to expose the `{{requests}}` to the home page for signed in users?

I'd like to show them their 5 most recent requests on the homepage so it's more visible.

If that cannot be done, could a Custom Page do this?  Essentially I want a landing page from our product for support that has both their requests and then knowledge base shown under it.  One stop landing page from my product.  We use SSO so our users are already authenticated when going there from the app.