Applications (as IdP)
Integration Guides
Zendesk

Zendesk SSO with MojoAuth

Connect Zendesk to MojoAuth using SAML 2.0 so both support agents (team members) and end-users sign in to your Zendesk subdomain with their MojoAuth-managed identity. MojoAuth is the Identity Provider (IdP); Zendesk is the Service Provider (SP).

How it works

Zendesk can also start the flow the other way (IdP-initiated) using the connection's Test SSO button or a bookmarked IdP-initiated link.

Prerequisites

  • A MojoAuth project (test or live) with access to Developers → Applications.
  • Admin access to Zendesk Admin Center (Account owner or an admin role that can manage Security settings).
  • SAML single sign-on in Zendesk requires the Enterprise (or higher) plan for full flexibility — in particular, per-role/multiple SSO configurations and enforcing SSO for all agents are Enterprise features. Lower plans can still configure a single SAML SSO integration for end-users and agents, but check your current Zendesk plan if options described below are greyed out.

Step 1 — Create the MojoAuth SAML connection

  1. In the MojoAuth dashboard, go to Developers → Applications → New Application → SAML 2.0 SSO.
  2. Enter a connection name (e.g. Zendesk) and click Create connection. This creates a draft connection and auto-issues a signing certificate.
  3. Leave the connection page open — you'll need the IdP values below and will come back to enter Zendesk's SP details.

See SAML SSO Connections for the general concept if you haven't created a connection before.

Step 2 — Configure Zendesk

  1. Sign in to Zendesk and go to Admin Center (the gear/wrench icon) → Account → Security → Single sign-on.

  2. Click Create SSO configuration (or Add SSO configuration if one already exists) and choose SAML as the type.

  3. Fill in the SAML configuration form with the MojoAuth IdP values:

    Zendesk fieldValue
    SAML SSO URL{BASE}/saml/{projectId}/sps/{spId}/sso
    Certificate fingerprintSHA-256 fingerprint of the MojoAuth signing certificate (see below)
    Remote logout URL (optional){BASE}/saml/{projectId}/sps/{spId}/slo

    Some Zendesk accounts show a Certificate field instead of (or in addition to) Certificate fingerprint — in that case, download the MojoAuth signing certificate from the connection page (Download .crt) and upload the full .crt/.pem file rather than computing a fingerprint.

  4. To compute the SHA-256 fingerprint from the downloaded certificate:

    openssl x509 -noout -fingerprint -sha256 -in cert.crt

    Zendesk expects the fingerprint value only (strip the SHA256 Fingerprint= prefix and any colons if the field rejects them — some versions of the form accept the colon-separated form as-is; if validation fails, try both formats).

  5. Give the configuration a name, e.g. MojoAuth, and Save.

Zendesk applies SSO separately to two audiences: team members (agents/admins) and end-users (customers). After saving the SAML configuration, go to Admin Center → Account → Security → Team members and/or End users, and under the SSO section select MojoAuth as the configuration each audience should use. You can enable SSO for end-users only, agents only, or both, and configurations are independent per audience.

Step 3 — Give Zendesk's SP details back to MojoAuth

Zendesk's SP values are fixed based on your subdomain — there's nothing to look up in the Zendesk UI beyond your subdomain itself:

ValueZendesk value
ACS / Assertion Consumer Service URLhttps://<subdomain>.zendesk.com/access/saml
SP Entity ID / Audiencehttps://<subdomain>.zendesk.com

On the MojoAuth connection page, use Manual configuration (or Import from metadata if you'd rather host a metadata document that returns these values) and enter:

  • SP Entity ID: https://<subdomain>.zendesk.com
  • ACS URL: https://<subdomain>.zendesk.com/access/saml

Then click Save.

⚠️

Replace <subdomain> with your actual Zendesk subdomain (the part before .zendesk.com in your Zendesk URL). The SP Entity ID and ACS URL must match your subdomain exactly — a mismatch is the most common cause of SAML errors during testing.

Step 4 — Attribute mapping

Zendesk identifies users by NameID = email address. Set the connection's NameID format to emailAddress so the assertion's NameID carries the user's email.

Zendesk can also read a display name from the assertion if you send one. A typical mapping:

saml_namesourcename_format
emailemailunspecified
name(constant, e.g. firstName + lastName concatenation not supported — send firstName)unspecified

In practice, most Zendesk SAML setups only require the NameID (email) to work — additional attributes are optional and Zendesk does not require a strict attribute-name contract the way some SPs do. Keep the mapping minimal unless you need to drive additional Zendesk profile fields.

Step 5 — Test

  1. On the MojoAuth connection page, click Test SSO to run an IdP-initiated login against Zendesk. You should land on your Zendesk subdomain, already signed in.
  2. Test the SP-initiated flow: open https://<subdomain>.zendesk.com in a private/incognito window. If SSO is enabled for end-users or agents, you should be redirected to MojoAuth's SSO URL, authenticate, and be bounced back to Zendesk as a logged-in user.
  3. Confirm both audiences you configured (team members and/or end-users) route correctly — test with an agent account and, separately, an end-user account if both are enabled.

Troubleshooting

Certificate fingerprint mismatch Zendesk rejects the assertion with a signature/certificate error. Recompute the fingerprint with openssl x509 -noout -fingerprint -sha256 -in cert.crt against the exact .crt downloaded from the MojoAuth connection page, and re-paste it with no extra whitespace. If MojoAuth's signing certificate was ever rotated, re-download it and update Zendesk's SSO configuration.

Audience / Entity ID mismatch Zendesk shows a generic SAML login failure and the assertion is rejected before reaching a user. On the MojoAuth connection, confirm the SP Entity ID is exactly https://<subdomain>.zendesk.com (no trailing slash, correct subdomain, correct protocol).

ACS URL mismatch Similar failure mode to the above — verify the ACS URL on the MojoAuth connection is exactly https://<subdomain>.zendesk.com/access/saml.

Users aren't routed to MojoAuth SSO If users still see the normal Zendesk email/password login instead of being redirected, check that the SSO configuration is actually assigned under Team members and/or End users in Admin Center → Account → Security — creating the SAML configuration alone does not enforce it for either audience.

NameID / email doesn't match an existing Zendesk user Zendesk matches SSO logins to existing users by email. If the NameID format isn't emailAddress, or the source mapped to the NameID isn't the user's email field in MojoAuth, users may fail to log in or get created as unexpected duplicate accounts. Set NameID format to emailAddress and confirm the source field on the connection.

Locked out of SSO / need to bypass If a misconfiguration locks out admins, Zendesk provides a bypass login at https://<subdomain>.zendesk.com/access/normal, which routes around SSO and prompts for a normal Zendesk email/password login (useful for admins with a standard Zendesk password to fix the SAML configuration without being caught in a redirect loop).

Remote logout URL not terminating the MojoAuth session If the optional Remote logout URL is set but users remain signed in to MojoAuth after logging out of Zendesk, confirm it points at {BASE}/saml/{projectId}/sps/{spId}/slo and that the connection's SLO endpoint is enabled.

See also