## TL;DR
A SAML login loop means authentication succeeds at the identity provider but Zendesk rejects the session and sends the agent back, usually because the NameID or email in the assertion does not match a Zendesk user, or the ACS URL the IdP posts to is wrong. Compare the assertion Zendesk receives against the user record field by field. The loop is a mismatch, not a mystery.

## The query

```text
zendesk "saml sso login loop" agents redirected after auth
```

## Use this when

- Agents authenticate at the IdP then return to the login page
- SSO logins loop without an error message
- SSO worked and broke after a config change
- You are debugging Zendesk agent SSO

## Not for

- Password-based agent logins
- End-user (help center) SSO
- Setting up an IdP from scratch
- Social login configuration

## Steps

### 1. Capture the SAML assertion Zendesk receives

Use the IdP's sign-in logs or a SAML tracer to capture the assertion. Check the NameID format and value, the email attribute, and the audience and recipient fields. The loop hides in one of these.

Expected output: the full assertion with NameID, email, audience, and recipient visible.

### 2. Match the NameID to the Zendesk user

Zendesk matches the assertion to a user by the configured identifier, usually email. If the NameID is a persistent opaque id but Zendesk expects email, no user matches and the login bounces. Align the NameID format with what Zendesk is configured to match on.

Expected output: NameID format aligned with the Zendesk user-matching field.

### 3. Verify the ACS URL and entity ID

The IdP must post the response to Zendesk's exact ACS URL, and the entity ID must match. A trailing slash or http versus https difference breaks the handshake silently. Copy both values from Zendesk's SSO settings into the IdP.

Expected output: ACS URL and entity ID byte-identical on both sides.

### 4. Check the signing certificate

An expired or rotated IdP certificate makes Zendesk reject the assertion. Confirm the certificate in Zendesk matches the IdP's current signing certificate, and note the expiry date.

Expected output: current valid certificate installed on both sides.

### 5. Test IdP-initiated versus SP-initiated separately

One flow may work while the other loops. Test both, and standardize on the working one while you fix the other. RelayState handling differs between the flows and is a common loop source.

Expected output: both flows tested, working flow identified.

## Template: the checklist

```text
Zendesk SAML login loop:
[ ] Assertion captured: NameID, email, audience, recipient checked
[ ] NameID format matches Zendesk user-matching configuration
[ ] ACS URL and entity ID byte-identical on both sides
[ ] Signing certificate current and matching
[ ] IdP-initiated and SP-initiated flows tested separately
```

## Variant phrasings

### zendesk sso keeps redirecting to login

Steps 1 and 2. Capture the assertion, match the user.

### saml assertion rejected zendesk

Steps 3 and 4. ACS URL and certificate.

### zendesk sso worked then broke

Step 4 first. Certificate rotation is the usual suspect.

## Why it happens

SAML is a multi-party handshake where every field must agree: IdP configuration, Zendesk configuration, and the user record. A change on any side (cert rotation, email change, IdP upgrade) breaks the agreement, and the failure mode is a redirect loop rather than an error page because each side thinks the other should proceed.

## Edge cases

- Email changes: a user whose email changed at the IdP no longer matches their Zendesk record. Update one side.
- Multiple Zendesk instances: the IdP app must target the right instance's ACS URL. Staging and production configs get swapped.
- Clock skew: assertions have a validity window. Severe skew between IdP and Zendesk rejects valid assertions.
- Just-in-time provisioning: if enabled, a mismatch creates a new user instead of looping. Decide which behavior you want.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-CkPZxoiD37V29xJRHbkeg