iOS swift "We're sorry, something went wrong when attempting to log in." error 403 Invalid State

Help
, , ,
1

On my iOS app that is using Auth0.swift library

I see this error trying to authenticate the user.
“We’re sorry, something went wrong when attempting to log in.”

The application is asking the authentication in the following way

        Auth0
            .webAuth()
            .scope("openid profile email offline_access")
            .audience("https://api.xxx.xxx")
            .start

Debugging the Safary login page when the request is performed

Request :method: POST :scheme: https :authority: XXX.eu.auth0.com :path: /usernamepassword/login Content-Type: application/json Accept: / Host: XXX.eu.auth0.com Accept-Language: en-us Accept-Encoding: br, gzip, deflate Origin: https://XXX.eu.auth0.com Referer: https://XXX.eu.auth0.com/login?state=IqUcaKz8oL43BPVflsm84gUET1cDrnaN&client=XXXmyclientIDXXX&protocol=oauth2&response_type=code&redirect_uri=xxx.XXX%3A%2F%2FXXX.eu.auth0.com%2Fios%2Fxxx.XXX%2Fcallback&audience=https%3A%2F%2Fapi.XXX.xxx&code_challenge=U89LGQB5BSIi5ilLyQqSTVqjrqYDwn9O700SrC-70tk&code_challenge_method=S256&scope=openid%20profile%20email%20offline_access&auth0Client=xxx User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 12_0_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0 Mobile/15E148 Safari/604.1 DNT: 1 Connection: keep-alive Content-Length: 722 Auth0-Client: xxx

I see the following error response

{ "statusCode": 403, "description": "Invalid state", "name": "AnomalyDetected", "code": "access_denied" }

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.

3

Hey there @nerocristallo !

The error clearly says that it’s an anomaly kind of issue. Here’s more on Anomaly Detection:

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.

4

Hi @konrad.sopala

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?

5

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.

6

Hey Folks!

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!

1 Like
7

Thanks, a lot, let me know if there is something we can do on our part.

1 Like
8

Hey Folks!

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.

Let me know if that works for you guys!

9

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:

fit.xxx://xxx.eu.auth0.com/ios/fit.xxx/callback,
xxxapp://xxx.eu.auth0.com/android/fit.xxx.xxxapp/callback

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.

Can you please clarify?
Thanks a lot!

10

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:

  1. The app requests a token (using /authorize). In the mobile app, that means opening the browser and doing the webAuth....start that you mentioned.
  2. 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.
  3. 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?

1 Like
11

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:

...

var config = JSON.parse(decodeURIComponent(escape(window.atob('@@config@@'))));
config.extraParams = config.extraParams || {};
var connection = config.connection;
var prompt = config.prompt;

...

var lock = new Auth0Lock(config.clientID, config.auth0Domain, {
	auth: {
		redirectUrl: config.callbackURL,
		responseType: (config.internalOptions || {}).response_type || (config.callbackOnLocationHash ? 'token' : 'code'),
		params: config.internalOptions
	},

	allowedConnections: connection ? [connection] : null,
	allowShowPassword: true,
	rememberLastLogin: !prompt,
	avatar: null,
	language: language,
	languageDictionary: languageDictionaries[language],
	mustAcceptTerms: true,
	assetsUrl: config.assetsUrl,
	theme: {
		labeledSubmitButton: false,
		primaryColor: "#ea712a"
	},
	prefill: loginHint ? { email: loginHint, username: loginHint } : null,
	closable: false
});

lock.show();

...

Can you please double check if you spot something wrong there? It seems fine to me.

Thanks a lot,
Marco

12

Hi

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.

1 Like
13

Hey ,

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?

Thanks for help!

14

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.

Thanks!

15

Hey @bragma!

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 a lot for understanding!

16

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.

17

Got it. Thanks a lot for sharing that! We’ll circle back once we define like a final solution.

18

Hi, is there any update? Thanks!

19

Hey bragma, lately I’ve been having the same problem, and it probably has to do with this: Microsoft Security Advisory: iOS12 breaks social, WSFed and OIDC logins · Issue #4647 · dotnet/aspnetcore · GitHub. I also use Auth0 Universal login, I am looking up to some solutions. Answer me if you find out something!

20

Hi, is there any way to fix this issue? We currently have one user who has experienced this issue on his device, iPhone X running iOS 12.

We have tried to create the account on a different device, which works, but he is still not able to log in using his own device.

We are only getting “We’re sorry, something went wrong when attempting to log in.” during login.

This is a user of the app and we dont have access to his phone for further debugging.

We have tried to delete the user in auth0 and recreate it, same issue.

2 Likes
21

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.”