Troubleshooting SSO Errors


SSO issues usually come down to a small number of configuration problems. Below are the five most common causes we see, along with what they mean and how to fix them. Matching these with your error screenshots will help you quickly identify the root cause.

1. An internal server error occurred

This is a broad error but can occur for two reasons:

A. Incorrect SSO Configuration Details

If the values entered in your identity provider don’t match what Datapeople expects, the login flow will fail. The most common mismatches are the:

  • Entity ID
  • SSO/ACS URL
  • Certificate information

Even small differences (extra characters, missing paths, old certificates) can block authentication. Double-check each field against the configuration provided by Datapeople.

B. Certificate Expiration

If your identity provider’s signing certificate has expired, or if its system time is out of sync, Datapeople will reject the authentication request. Updating certificates and ensuring your IdP time settings are current resolves the issue.


2. Email Domain Not Allowed

Datapeople limits access to approved company email domains. If a user tries to sign in with an unlisted domain (including common cases like contractors or subsidiaries), authentication may succeed in your identity provider but still be blocked by Datapeople. Please reach out to our team to add any legitimate domains your organization uses.

3. Could not get email, firstName or lastName from IDP

This is a case where the attributes have been mapped incorrectly.

Datapeople requires three core user attributes to complete SSO:

  • first name
  • last name
  • email.

If your identity provider sends different attribute names, an unexpected NameID format, or leaves fields blank, users won’t be able to sign in. Verifying the attribute mappings is often the quickest fix.


In Entra, your Attributes & Claims page should include the SOAP XML Schema http://schemas.xmlsoap.org/ws/2005/05/identity/claims  in the claim name as it does below.

Attributes & Claims Page

If your instance doesn't populate these by default, then you will need to edit each attribute and ensure the Namespace field is populated with the schema http://schemas.xmlsoap.org/ws/2005/05/identity/claims  

Edit claim page

4. User Not Assigned or Lacking Access

If a user isn’t assigned to the Datapeople app in your identity provider, is disabled, or doesn’t have the right permissions, the SSO flow can’t pass the user through. You will need to ask your IT administrator to confirm that the user has been added to the Datapeople application in your IdP and that their access is active.

Still stuck?

If you’ve checked each of these items and continue to see errors, our support team is happy to help you get SSO working correctly. Please reach out to Datapeople Support with the error message or screenshot you’re seeing, and we’ll guide you through the next steps.

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.