Setting up SSO with OpenID Connect

The other standard for connecting an identity provider. Same purpose as SAML, and the same two things go wrong.

The other standard for connecting an identity provider. Same purpose as SAML, and the same two things go wrong.

Set it up

1. Register Zendesk as an application with your provider, using the callback URL https://yoursubdomain.zendesk.com/access/oidc/callback.
2. In Admin Center, click Account in the sidebar, then select Security > Single sign-on and create an OIDC configuration.
3. Fill in Configuration name, Client ID, Client secret if your provider requires one, Issuer URL, UserInfo URL, JWKs URL, Authorization URL and Access URL.
4. Set Scopes to at least openid email, separated by spaces and not commas.
5. Choose the Authentication Mode: PKCE or the authorization code flow.
6. Test with one account in a private window.

You can also set IP ranges and how the sign-in button is displayed. Only administrators can configure this.

SAML or OpenID Connect

Both do the same job. Use whichever your identity provider supports best, and if it supports both, use the one your organisation already uses elsewhere.

Running both at once is a configuration nobody will remember the reasons for.

Scopes decide what arrives

The minimum is openid and email. Without the email scope Zendesk receives no address and cannot identify the person, which is the most common setup failure and presents as a confusing error.

The separator matters too: spaces, not commas. profile, address and phone are available as well, along with any custom scope your provider defines, but ask for what you use rather than everything on offer.

The callback URL must match exactly

It is https://yoursubdomain.zendesk.com/access/oidc/callback, with your own subdomain. Providers reject anything that does not match what was registered, down to the trailing slash, so copy it rather than typing it.

The signing algorithm has to match

Zendesk decodes tokens with RSA256 by default. If your provider signs with something else, such as ES256, declare it in that provider's discovery endpoint; otherwise the token arrives and is not accepted.

This one is worth checking before you test, because the symptom is a sign-in that fails without saying why.

Test with a session still open

Private window, ordinary admin session untouched. If it goes wrong you can still reach the settings.

Then close the old route

Disable Zendesk passwords for team members once it works. Otherwise the account is still reachable by a path your provider does not govern, and the offboarding benefit is theoretical.

Watch the credentials

Client secrets can expire or be rotated. When one is, sign-in stops for everybody, so note the date wherever your team tracks such things.

See also

• Enabling SAML single sign-on
• Managing your SSO configurations
• My agent cannot sign in: what to check