We noticed in our logs that we are getting some errors with a Type “Failed Login”. When we look at the description it reads “invalid distance too far back” and the Application is N/A, which is different than all of our other messages (which have an application).
Does anyone have any idea of what this message means?
Hey there 
I probably know what it’s about. We call it impossible travel. So let’s say that a user wants to login in point A (Boston for example) and ten minutes later he wants to login in point B (Spain Europe) which is impossible as they’re not there. Might it be like that? Is it about your user?
I don’t feel that this is the case. When I do a search for these messages, including “invalid bit length repeat” and other messages showing up like this, they seem to all come back to ZIP compression. What scenarios would cause these or where they originate from (Auth0 or something in between) is my primary concern.
Ok gotchya! Let me perform some research then and get back to you soon with the news!
Hey there @amckendrick!
It seems like I need additional data. Do you have any extensions configured? If so which ones?
@konrad.sopala We have delegated admin and user import/export, although, we are not using either of them at the moment - we plan to, but we aren’t using them actively.
Thank you for providing that context! I just opened an internal ticket for you so our engineering team should provide me with more info soon!
So we were able to partially decipher that error message…
These errors might be generated attempting to decode invalid SAML requests. We’re confirming it with our protocols team.
Yep assumption confirmed. The issue is indeed due to an invalid SAML request.
It seems that there are a number of tenants with those invalid SAML requests (not only you):
Are you able to provide any reproduction steps so we can determine whether this could potentially be a bug on our side or possibly misconfiguration on the your side?
Hi Konrad, I am unsure how to reproduce it. It is just something that I noticed in the logs and I generally don’t ignore logs, which is why I raised it. I guess understanding that it is an invalid SAML request, I could reach out to the third-party vendor and ask them as well, it is difficult because we are in the middle between Auth0 and the third-party company that we are using.
Gotchya! Totally understand that! Let me take that information back to the engineering team!
Hey there!
Sorry for such long delay in response but it seems it got stuck in our engineering department.
They found 2 possible cases to why this is failing.
Case 1: HTTP Redirect binding (GET /samlp/client )
They investigated a bit further and found the source of the problem. According to SAML specification, when using HTTP Redirect binding (like in this situation) the SAML Request (xml) is built with these steps:
DEFLATED => base64 => url encoded => set to SAMLRequest parameter
(See section “3.4.4.1 DEFLATE Encoding“ on https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf ).
It seems the case we have here is caused because the SAML Request was not url encoded before sending it to Auth0. That creates a problem: + character is transformed to (whitespace), that makes the request parsing fail.
Solution: Ask the Identity Provider that created the request to url encode the SAMLRequest.
Case 2: HTTP POST binding (POST /samlp/client )
They also found that the Request itself, once parsed, contains POST binding. When POST binding is used the caller does not need to url-encode the base64 data, that would explain why it is not url-encoded.
Solution: Ask the Identity Provider to send the request using POST binding.