Plan requirement
| Subscription | Any plan |
| Access | Admin |
How people get in: passwords, social accounts, or your own identity provider. Different answers for staff and customers.
The options
- Zendesk passwords, managed here, with two-factor available.
- A business or social account. Google and Microsoft for team members; Facebook, Google and Microsoft for end users.
- Enterprise single sign-on, where your identity provider decides. It comes in three types: SAML, OIDC and JSON Web Token.
They are configured separately for team members and for end users, which is the distinction to hold on to. In Admin Center that is Account > Security, where Team member authentication and End user authentication are two separate pages, with Single sign-on beside them holding the configurations themselves.
None of this is gated behind a large plan. Enterprise single sign-on is available on every Suite and Support plan, so if you have an identity provider you can use it from the first day.
For staff: single sign-on if you have it
One account to disable when somebody leaves, one place for policy, no separate password to manage. It is the highest-value security change most organisations can make here.
Where you do not have it, Zendesk passwords plus mandatory two-factor is the alternative.
For customers: as little as possible
Every sign-in requirement loses people who wanted an answer. If most of your help centre does not need to be restricted, most of your customers should not need an account.
Where they do, a Google, Microsoft or Facebook account removes another password.
Do not mix without deciding
Zendesk lets you keep its own authentication alongside enterprise single sign-on, and there is a setting that decides what that means in practice. Under How team members sign in, Let them choose puts every active method on the sign-in screen; Redirect to SSO sends them straight to the identity provider and allows nothing else. End users have the same setting of their own, under How end users sign in.
Leaving Zendesk passwords enabled means an account can still be reached the old way, which quietly undoes the offboarding benefit. Sending everybody straight to the provider closes that door without destroying anything.
Switching Zendesk authentication off is not a toggle you flick back. Disable it and every Zendesk user password is permanently deleted within 24 hours. Turning it on again gives you the option, not the passwords: everybody has to set a new one.
Plan the recovery path
Whatever you choose, know what happens when somebody cannot get in: a lost phone, a provider outage, a colleague who left. Deciding that in advance avoids an urgent workaround that weakens the whole arrangement.
If you have switched Zendesk authentication off, the answer cannot be to fall back on passwords, because there are none left to fall back on. That is the case for redirecting to your provider rather than deleting the alternative.
Comments
0 comments
Article is closed for comments.