Plan requirement
| Subscription | Any plan |
| 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
- In Admin Center, click Account in the sidebar, select Security > Single sign-on, click Create SSO configuration and choose JSON Web Token.
- Enter a Configuration name and the Remote Login URL: the address people are sent to when they try to reach your Zendesk. Zendesk appends a
brand_idparameter to it. - Optionally set a Remote logout URL and IP ranges, and decide whether to show the button when users sign in.
- Take the shared secret and give it to whoever builds the endpoint.
- Build the endpoint in your application that signs the token.
- Test with one account, then enable it for end users.
The four claims the token must carry
iat |
Issued At: when the token was generated. |
jti |
A unique id for the token, which Zendesk uses to prevent replay attacks. |
email |
The address of the person signing in. This is what identifies the user record. |
name |
Their name. |
All four are required. jti is the one people leave out or reuse, and reusing it is exactly the case the check exists to catch.
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. Zendesk puts it plainly: if the shared secret is compromised, all the data in your Support account is at risk. It belongs wherever your application keeps its secrets, never in client-side code and never in a repository, and you can generate a new one from the options menu if it ever leaves that place.
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.