I am working on creating a SAML connection. My tenant uses a custom domain. When I test the connection the test is initiated on the non-custom domain. Then, the idP redirects back to the custom domain. This causes the request to look like it was initiated by the iDP and generates the error
invalid_request : IdP-Initiated login is not enabled for connection “KOLLECTIVE-SAML”.
If I instead use an application to test the connection, i do not get this error.
The expected behavior would be testing the connection would use the tenant’s custom domain.
e.g.
if my custom domain was login..com
and my default domain was auth0..com
I would expect testing a connection to use login..com
You’re correct that this is a known bug. If IdP-initiated logins were enabled for your connection, you would get a slightly different error, as described here:
I call it “changing horses in midstream”, and it’s probably encountered most frequently when folks use the “try” button in the dashboard when the connection was configured with a custom domain. I’m glad you were able to find the cause of the problem, and I’m sorry the dashboard isn’t able to handle this situation more gracefully.
As far as I know this is still not prioritized. My best guess (I can’t speak for the product team) is since there is a pretty straightforward workaround, the priority won’t change in the near future.
For folks who haven’t run into this before, the workaround is to right-click and copy the link from the “try” button, and then edit the link to use the custom domain.
.com
.com