Skip to main content
People who can’t sign in see only a short message, so start with the connection test: on Settings > Single sign-on, choose Test connection, or run 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 connect with your connection’s protocol, issuer and single sign-on URL and --certificate-file twice, 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 email attribute with the person’s address, or a name ID that is that address. In Okta, the attribute’s value is user.profile.email; user.email doesn’t work. For OIDC, grant the email scope.
  • 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-verification there. 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 a ref 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.

​
SCIM provisioning failures

Start with your IdP’s provisioning log: Okta lists failed tasks under the app’s provisioning errors, and Entra ID shows them in its provisioning logs. Each failure has a status code and, for most, a scimType. Find them in the table below, fix the cause, then retry the person from your IdP. Every SCIM error uses the SCIM error schema (urn:ietf:params:scim:api:messages:2.0:Error), with a scimType where SCIM defines one and a detail that names the problem.

​
Status codes

409, 403 and 400 mutability refusals that owners need to act on also email every owner. See SCIM provisioning.

​
What SCIM requests Sazabi supports

A User’s writable attributes are userName, name, displayName, emails and active, and externalId on create. PATCH supports add and replace. In a PATCH, active may be a boolean or the string "True" or "False"; in a POST or PUT it must be a boolean. Sazabi ignores emails in a PATCH: a changed email never changes a person’s Sazabi account address. An externalId in a PUT or PATCH replaces a record’s userName stand-in, when it was created without one, and is otherwise ignored. The person’s address is their primary email, or their only email, or else userName. Unknown is never success: if Sazabi can’t read the token, the domain or the membership, it answers 503 so your IdP retries.

​
Verify the SCIM fix

Retry the person from your IdP: in Okta, retry the failed task; in Entra ID, use Provision on demand. The person appears on Settings > Members, or their change shows there, and Last change received in the SCIM provisioning section of Settings > Single sign-on updates. If the same error comes back and none of the causes fits, send the person’s userName and the time of the failure to Sazabi support.

​
Verify

Run Test connection again. It reports a successful sign-in.