sazabi sso connection test. A test passes only when the sign-in completes. When it doesn’t, your IdP shows its own error or the sign-in ends on the SSO error page, and sazabi sso connection test stops waiting when the test link expires. Check the causes below. If none fits, send the error page’s full address to Sazabi support.
Certificate errors
The response’s signature didn’t match a signing certificate on the connection.- Copy the IdP’s current signing certificate into the connection again, in PEM form. Use the signing certificate, not an encryption certificate or a thumbprint. In Entra, that’s Certificate (Base64).
- Check the IdP signs the assertions. Signing only the response isn’t enough.
- To rotate, keep both certificates while your IdP switches. Saving a certificate in the dashboard replaces the saved certificates, so use the CLI: run
sazabi sso connectwith your connection’s protocol, issuer and single sign-on URL and--certificate-filetwice, once for the current certificate and once for the new one, before your IdP starts using the new one. Then run it again with only the new one. With a Metadata URL, Sazabi re-reads the IdP’s certificates for you. Google Workspace has no metadata URL, so add Google’s new certificate before the old one expires.
Clock skew
The response was outside its validity window, which usually means the IdP’s clock is wrong. Check the IdP’s time settings, then test again.Audience mismatch
The response was made for a different service provider. Set your IdP’s audience or entity ID to exactly the SAML entity ID from Service provider details. In Okta, check the ACS URL and the entity ID aren’t swapped between Single sign-on URL and Audience URI (SP Entity ID). For OIDC, check that Client ID matches the application.Issuer mismatch
The issuer in the response differs from Identity provider entity ID (SAML) or Issuer URL (OIDC). Copy the issuer from the IdP exactly, including any trailing slash.A person can’t sign in
- Not assigned at the IdP. Assign the person to the Sazabi application. Google Workspace turns new custom apps off by default; turn it on for the person’s organizational unit or group.
- No email on a verified domain. For SAML, send an
emailattribute with the person’s address, or a name ID that is that address. In Okta, the attribute’s value isuser.profile.email;user.emaildoesn’t work. For OIDC, grant theemailscope. - Domain not verified. The person’s email domain must be verified by your organization. See Add SSO domains.
- Removed members. People an admin removed aren’t added back by SSO. Invite them again from Settings > Members.
- New people refused. If Add people on their first sign-in is off on the connection, or Just-in-time member provisioning is off on Settings > Organization, only existing members can sign in. Turn both on or invite them.
- The tile fails. A tile that posts a SAML response, such as Okta’s own tile for a SAML app, is refused. Point the tile at the Initiate login URL; see Configure SSO.
Domain verification failures
- Record not found. Check the record’s name is
_sazabi-verification.followed by the domain, and its value is the full value from the domain’s row. Some DNS providers add the domain to the name for you, so enter only_sazabi-verificationthere. Then wait for DNS to update. - DNS error. The lookup failed, which doesn’t change the domain’s status. Try again later.
- Lapsed. The record was removed. Publish it again.
- Can’t claim the domain. It’s a shared email domain, or another organization has verified it. Contact support about a contested domain.
The SSO error page
When an SSO sign-in is refused, the person lands on an error page with one action, Sign in again. The page never says why, so it doesn’t reveal how your connection is set up.The reference on the error page
The SSO error page’s address carries aref reference. Ask the person for the full address of the page, and include it in a request to Sazabi support so support can find the cause. See The SSO error page for what each message means.