IdP-Initiated login is not enabled for connection error when SP-Initiated flow configured

We have IdP-Initiated logins disabled on purpose so getting the error is fine. The problem we are trying to solve is why we are getting the error in the first place.

We are configured with an SP-Initiated flow and Auth0 documentation says we can get the “IdP-Initiated login is not enabled for connection” error when in SP-Initiated flow if 1) the RelayState is missing or empty or 2) the InResponseTo attribute in the SAML Response is missing or empty.

I checked the Auth0 log entry and see both the RelayState and the InResponseTo attribute in the SAML Response. Neither are missing or empty, so the SP-Initiated flow should be fine.

Does anyone know why an SP-Initiated flow with both RelayState and InResponseTo attributes set, would cause the “IdP-Initiated login is not enabled” warning?

2 Likes

I’m having this same issue working with Azure AD as the IdP. Were you able to resolve this issue?

Were you able to resolve?

I am having this problem as well.

There’s an older thread here which I think may be the same issue: False IdP-Initiated login when Testing SAML Connection with Custom Domain

Unfortunately, it looks like its a bug for Auth0, but not a high-priority fix.

Edit: Found another thread about this issue:

1 Like

I believe people are encountering this issue because, if you are using a Custom Domain, then Auth0’s guide for setting up SAML (HERE) will mislead you into getting this error.

So to clarify on the docs:
If you are using a Custom Domain, when you copy the AssertionConsumerService/Location out of your tenant’s metadata, you must replace the domain there with your Custom Domain. Then copy that into the Application Callback URL field of the IdP Tenant in the next step.

1 Like

The answers here do not fully answer the question posed, as the OP does not mention using a custom domain.

We are NOT using a custom domain and use SP-initiated login, but are receiving this error for one particular SAML client when they test their connection during self-service setup (others work fine). I have checked the log and the required attribute and parameter are present with a value.

The docs suggest simply enabling IdP-initiated logins but, given the big security warning in the admin, I don’t want to compromise security enabling a feature we don’t use.

Is there something on the IdP side that could be incorrectly setup to cause this issue?