Unfortunately I am not able to reproduce it anymore in my debug environment but the problem is still present in the field for some users.
I suspect that it could be related to the iOS 12 update.
Are you sure you haven’t enabled it? Are you trying to authenticate yourself or is it some external user of yours (brute force protection)? Let me know if such thing happened to you before or is it the first time and most importantly if you’re trying to authenticate with proper credentials.
I can confirm that we are using the brute-force protection but not the breached-password protection
and it is set in this way since long time ago but the issue starts to happen just from a week.
I see that the error is related to “Anomaly Detection”.
but the error looks different from the “blocked user” error and we do not see any issue notified on the users account involved on this login problem
How can the 403 error “invalid state” be related to the Anomaly Detection system?
How can I unlock the users that are experimenting this kind of error?
Hi @konrad.sopala, I agree that the name is AnomalyDetected but the description is “description”: “Invalid state”. Now, I can’t really understand what’s wrong with the state, since it is generated internally by the swift library. I don’t know what auth0 is doing internally with it, but it seems it is checked like a session. Error 403 is generated by the server so somehow it checks its content.
Also, notice that all expected errors from Anomaly Detection are reported with a specific and understandable error.
Got it, totally understand your case now. We’ve started digging into that and I’ll provide you with more info as soon as we figure out the core problem. Thanks for patience! Will keep you updated!
It seems like there can be a few causes of this error but the most common one is that this process fails is is when the callback URL is cached on the server. Remove caching from all the URLs listed in the “Allowed Callback URLs” field for your Application in the Auth0 dashboard and test again.
Thanks for taking some time investigating this. I don’t understand which cache or server you are referring to. In auth0 management page we’ve set up our mobile application entry with the following callback URLs:
Those settings are required by the Android/iOS auth0 SDKs. Obviously their value is not a real page hosted on any server, they are protocol handlers specific values for our android/ios app.
Hi @bragma.
The Invalid state error is thrown when the server can’t correlate the POST of the user credentials (username/password) with an existing authorization transaction.
In a regular flow, things go like this:
The app requests a token (using /authorize). In the mobile app, that means opening the browser and doing the webAuth....start that you mentioned.
A session is generated if one didn’t exist, along with a session cookie. An internal “state” representing the ongoing transaction is added to the current session.
User types username/password in the hosted login page. A POST to /usernamepassword/login is done, sending the session cookie AND the internal state generated for this authorization transaction.
In step 3, if the cookie is missing or if the state is invalid (non existing, incorrect, or no longer active) then this error is generated. The reasons for this might be:
User has cookies disabled for the site (very unlikely)
User uses the back button or double-posts the credentials.
User bookmarks the login page (unlikely in a mobile app)
The hosted login page is not correctly passing the config.internalOptions when creating Auth0.js or Lock (as shown in the default templates).
This shouldn’t be affected by iOS 12, at least we haven’t seen issues on this particular flow so far. Can you check the above to see if you can reproduce?
Hi,
the flow is not documented but it is more or less how I expected it to be from some trials and errors I did. Thanks for confirming how it works.
Additional info is that the same hosted page works for most other customers and also customers reporting problems with mobile can login on the same devices using our web app leveraging the exact same login page.
Regarding the possible clauses:
I’ve manually disabled cookies from Safari’s settings, ad did not have any problems loggin in. I was not expecting it to not work but I’ve been able to complete login without errors. I can’t explain, maybe the main safari setting is not affecting web views? I don’t really know.
User pressing the back button: not sure about this, but I’ve been able to speak with the users and they didn’t mention it. I somewhat trust them on this aspect. Regarding double posting, I am expecting to happen only if the user somehow presses the button twice, but I don’t think it’s possible since the button becomes disabled when pressed.
Last reason seems to be the most probable to me but my setup is practically based on the default template:
Currently this issue is happening only on a couple of devices. If it is related to a wrong configuration of the login page then my expectation is that it should happen every time and on every device.
I did some experiments disabling or enabling cookies but they do not produce any results whether to fix or replicate the issue.
I know that it’s a tough one cause there are plenty options to check but can you spot a set of shared characteristics for those devices, so we can investigate those specific options?
Hi,
thank you for offering to help but as you say it is a bit difficult to debug this case. When I originally posted I expected to have some more options to debug from some internal logs or iOS SDK since when the server fails with 403 nothing is reported in our dashboard logs, not even a failed login attempt.
We’ve been able to see the problem once in our labs and got the logs we posted above using an USB cable connected to our iPhone but we’ve not been able to reproduce the problem since then, so we initially thought it was a transitory problem on Auth0’s servers. A few days after the customer reported the problem to be still present.
In any case, the only common factor at the moment is iOS 12 (but notice we also have iOS 12 in our labs and they show no problems). We asked the users to check Safari’s options (cookies, security, etc.) as we suggested and reinstall the app. They said the problem persisted but we don’t know much more.
Notice that we have lots of other customers logging in every day with different OS and phones so it must be something really specific to those users.
At the moment we are on a stall. What’s worst is that since we have no evidence of the problem in the dashboard logs, we don’t know how much widespread the problem really is, even if we expect it to be rare.
Totally got it. We’re investigating it with our developer support engineers. Please give us a few more days and I’ll get back to you with what we found.
Thanks. It happened once again in our labs, but while trying to understand what was happening we’ve somehow “fixed” it. Basically, while our app was not logging in, we logged in with Safari in our web app just to test if we had the same problem using web login. Both mobile app and our web SPA share the same hosted universal login page. After logging in with Safari, the app login started to work. I am suspectin that there is some interaction between Safari’s cookies and the browser embedded in the view opened by the swift library. It is also not clear how cookie settings in Safari interact with the app web view itself.
Currently experiencing a similar issue for a user account. The user can login correctly from Chrome (iOS12) from his iPad, but trying to login from Safari fails with the message “We’re sorry, something went wrong when attempting to log in.”