Plan requirement
| Subscription | Suite Professional or higher, Support Professional or higher |
| Access | Admin |
Sign-in driven by your own application. Mostly for customers, where your product already knows who they are.
What it is for
A customer signed in to your product clicks Help and arrives in the help centre already signed in. No second account, no second password, no drop-off.
That is the case JWT handles well, and it is usually about customers rather than staff.
Set it up
- Enable JWT authentication in Zendesk and take the shared secret.
- Build the endpoint in your application that signs the token.
- Include the email address and name.
- Test with one account.
- Enable it for end users.
It is development work
Your application has to generate and sign tokens correctly. This is not a configuration task, and it needs whoever owns that application.
The shared secret is a credential
Anybody holding it can assert who a user is. It belongs wherever your application keeps its secrets, never in client-side code and never in a repository.
Email decides identity
Same rule as everywhere. If your application sends a different address from the one on the ticket history, the customer arrives as a new user with none of their tickets.
Plan what happens outside your product
Somebody arriving at the help centre from a search engine is not signed in to your application. Decide whether they can sign in another way or are sent to your product first.
For staff, use SAML instead
JWT works, and SAML integrates with the identity provider that already governs joining and leaving. For agents that is the better arrangement.
Comments
0 comments
Article is closed for comments.