twentyhq/twenty · error · Error

No SingleSignOnService with HTTP-Redirect or HTTP-POST bindi

Error message

No SingleSignOnService with HTTP-Redirect or HTTP-POST binding was found

What it means

Thrown after IDPSSODescriptor is parsed: none of its <SingleSignOnService> entries carry a Binding attribute equal to the SAML HTTP-Redirect or HTTP-POST binding URN. Twenty only accepts these two standard SSO bindings for the authn request.

Source

Thrown at packages/twenty-front/src/modules/settings/security/utils/parseSAMLMetadataFromXMLFile.ts:115

    const singleSignOnServices = getAllByPrefixAndKey(
      IDPSSODescriptor,
      'SingleSignOnService',
    ).map((service) => ({
      binding: service.getAttribute('Binding'),
      location: service.getAttribute('Location'),
    }));

    // Prefer HTTP-Redirect (the default authnRequestBinding on the SP side),
    // fall back to HTTP-POST since both are valid SAML 2.0 bindings and many
    // IdPs (e.g. JumpCloud) only advertise HTTP-POST.
    const ssoUrl =
      singleSignOnServices.find((s) => s.binding === HTTP_REDIRECT_BINDING)
        ?.location ??
      singleSignOnServices.find((s) => s.binding === HTTP_POST_BINDING)
        ?.location;

    if (!ssoUrl) {
      throw new Error(
        'No SingleSignOnService with HTTP-Redirect or HTTP-POST binding was found',
      );
    }

    const result = {
      ssoUrl,
      certificate: x509Certificate,
      entityID: entityDescriptor?.getAttribute('entityID'),
    };

    return { success: true, data: validator.parse(result) };
  } catch (error) {
    return { success: false, reason: formatErrorReason(error) };
  }
};

View on GitHub (pinned to 1f5dd2bbd2)

Solutions

Open the XML and list all SingleSignOnService Binding values.
Reconfigure the IdP to advertise at least one HTTP-Redirect or HTTP-POST SSO endpoint.
If the binding URN is subtly different (e.g., wrong version string), correct it to urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect or HTTP-POST.

Example fix

// before: <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="..."/>
// after:  <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="..."/>

Defensive patterns

Strategy: validation

Validate before calling

const SSO_BINDINGS = new Set([
  'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect',
  'urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST',
]);
const listSsoBindings = (xml: string): string[] => {
  const doc = new DOMParser().parseFromString(xml, 'application/xml');
  return Array.from(doc.getElementsByTagName('SingleSignOnService'))
    .map((el) => el.getAttribute('Binding') ?? '');
};
// guard: if (!listSsoBindings(xml).some((b) => SSO_BINDINGS.has(b))) showError(...);

Type guard

const metadataHasUsableSsoBinding = (xml: string): boolean =>
  listSsoBindings(xml).some((b) => SSO_BINDINGS.has(b));

Try / catch

const res = parseSAMLMetadataFromXMLFile(xml);
if (!res.success && res.reason.includes('SingleSignOnService')) {
  notifyUser('IdP must advertise an HTTP-Redirect or HTTP-POST SSO endpoint');
}

Prevention

Before upload, confirm the IdP exposes HTTP-POST (the most widely supported binding).
If only SOAP/Artifact is available, reconfigure the IdP to add HTTP-POST.

When it happens

Trigger: IdP advertises only SOAP/Artifact/PAOS bindings for SingleSignOnService. The Binding attribute is missing or mistyped on every service entry. Bindings use a different (non-2.0) URI string.

Common situations: Testing IdP (e.g., a stub) that lacks HTTP-Redirect/POST endpoints. Enterprise IdP locked to SOAP-Artifact. Metadata generated by a misconfigured tool that drops Binding attributes.

Related errors

AI-assisted analysis of twentyhq/twenty@1f5dd2bbd2 (2026-08-12). Data as JSON: /api/errors/48cae393da23bede. Report an issue: GitHub.