"You may have pressed the back button" but I really didn't

sebastien.arbogast1 · April 12, 2019, 9:17am

I’m trying to finalize a somewhat complicated setup involving Auth0, AzureAD-B2C and ActiveDirectory, but I’m having this weird error I can’t interpret, and thus it’s hard to tell the guys managing identity providers what is wrong.
I’m connecting an iOS native app with an Auth0 enterprise connection plugged into an AzureAD-B2C identity provider. When my users authenticate with AzureAD-B2C directly, everything works fine, the session goes through and they are able to log in to the app. But there is one more bit of complexity: because we have 2 kinds of users:

B2C customers stored in AzureAD-B2C itself
employees stored in a separate Active Directory
So the guys managing both of these identity providers are trying to configure their security policy so that on the login page, in addition to the Azure B2C login form and sign up button, there is also a “Connect with AD” button for employees, that redirects them again vers the Active Directory login.
And that’s where things go bad, because after the user logs in to his Active Directory account, he is somehow redirected to Auth0, but he gets the following error message:

“Oops!, something went wrong. You may have pressed the back button, refreshed during login, opened too many login dialogs, or there is some issue with cookies, since we couldn’t find your session. Try logging in again from the application and if the problem persists, please contact the administrator”

And indeed, in the Auth0 logs of my environment I see this:

{
  "date": "2019-04-12T08:54:19.617Z",
  "type": "f",
  "description": "You may have pressed the back button, refreshed during login, opened too many login dialogs, or there is some issue with cookies, since we couldn't find your session. Try logging in again from the application and if the problem persists please contact the administrator.",
  "connection_id": "",
  "ip": "49.217.187.25",
  "user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 12_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.1 Mobile/15E148 Safari/604.1",
  "details": {
    "body": {},
    "qs": {
      "error": "server_error",
      "error_description": "AADB2C90289: We encountered an error connecting to the identity provider. Please try again later.\r\nCorrelation ID: f5e440b1-2b2b-4e55-a318-ef82df67691e\r\nTimestamp: 2019-04-12 08:54:18Z\r\n",
      "state": "RKN7XYDGT_xag4Kr4TbQEDy6v2mMJ9IE"
    },
    "error": {
      "message": "You may have pressed the back button, refreshed during login, opened too many login dialogs, or there is some issue with cookies, since we couldn't find your session. Try logging in again from the application and if the problem persists please contact the administrator.",
      "oauthError": "invalid_request",
      "type": "request-error"
    }
  },
  "hostname": "derbigum-qa.eu.auth0.com",
  "log_id": "90020190412085419617963219260888643271217201812678377474"
}

My problem is that I don’t have information in there to help me figure out what’s wrong with the redirection I receive back from AzureAD-B2C or Active Directory itself, and I don’t know how to help them.

Any idea?

jmangelo · April 12, 2019, 11:22am

Side note: Loved the question title; but to be fair that error message continues with a few other possibilities…

In relation to the issue, the best way to approach that particular error scenario would be to have an HTTP trace that includes all the requests since the initial /authorize request from the client application until the back button screen of death request.

There’s information here (Generate and Analyze HAR Files) on capturing an HAR in Chrome which may be sufficient although Chrome has the nasty habit of discarding response bodies on their network tools (likely the only feature in Chrome that tries to be space/memory conscious).

If you can do the above, be sure to redact any sensitive information before sharing (passwords, session cookies, etc). Just redact each value consistently so that the same real value is consistently replaced with the same new (redacted) value as that way less probability of impacting useful troubleshooting information.

sebastien.arbogast1 · April 18, 2019, 5:58am

Is there any similar procedure to troubleshoot the authentication process with a native iOS app? Because right now, the authorization request starts from this SDK call in my app:

Auth0
                .webAuth(clientId: clientId, domain: domain)
                .connection(Session.connectionName)
                .scope("openid profile email")
                .audience("https://\(domain)/userinfo")
                .start { result in ... }

And I’m not sure how I can access the logs of the browser window opened by the SDK to perform that auth0 request

jmangelo · April 18, 2019, 10:57am

It should be possible using tools like Fiddler or Charles Proxy and with the necessary configuration on the native side you would then be able to proxy web traffic through the tool and as such capture it. However, this is not as simple as the option to just open a browser network tools.

Have you confirmed that this is specific to iOS? For example, the code snippet you show in the general case translates to:

open an in-app browser window and navigate it to /authorize with these specific set of parameters.

In other words, some problem can be troubleshooted in the browser by just faking the authorization URL used by the mobile application. Having said that some problems are indeed specific to the exact native-land flow so those would indeed require the proxy-based tool to try to capture some additional information.

eoa.dev · June 24, 2019, 10:13am

Hi i am having the same problem.

In our Android app it works just fine.
In our iOS app sometimes it works and others it generates the same error as above. Usually it fails on the first attempt to login via Facebook and on the second time it works.

Do you have any news on this problem?

eoa.dev · June 28, 2019, 9:05am

How do i fake the authorization URL?

jmangelo · June 28, 2019, 2:48pm

I have no news about this particular issue; in terms of faking the URL is basically starting with the Authentication API endpoint (Authentication API Explorer) that is responsible for the start of an authentication transaction and then manually add the query string parameters that the native mobile code does.

For example, if the native app does .scope("openid profile email") then you would have /authorize?scope=openid+profile+email as the equivalent in terms of manually creating the URL. Just have in mind that since you’re building the URL by hand you may need to encode some values yourself, for example, in the scope example, I’m manually encoding the spaces to + as a + can represent a space.

eoa.dev · July 1, 2019, 12:24pm

Thank you for the reply.

We are using react-native-auth0 like this:

In that case how do i use openid, email and audience to fake the url?

Also i found https://openidconnect.net/ , i configured “Auth0 domain”, “OIDC Client ID”, “OIDC Client Secret” and used the “USE AUTH0 DISCOVERY DOCUMENT” to generate the token fields. I tested in on iPhone Xs, iPhone Xs Max and it works. It generates a valid token.

jmangelo · July 1, 2019, 1:24pm

For that usage, you would have something like:

https://[YOUR_TENANT]/authorize?client_id=[YOUR_CLIENT_ID]&redirect_uri=[CLIENT_CALLBACK]&scope=openid+email&response_type=code&audience=https%3A%2F%2F[YOUR_TENANT]%2Fuserinfo

The above would allow to start the authentication transaction in a similar fashion to the application itself; in this way you would be able to complete all the steps until a response is sent to the application in the redirect URI. For the purpose of this error which happens before that redirect then just using the URL could allow to more quickly troubleshoot the situation.

rahul.bisht · July 1, 2019, 4:02pm

I am also facing the same issue but i am facing this issue when i use the sample WPF application it fails for ADFS login but when i am using the normal browser workflow it works.

the error is →
You may have pressed the back button, refreshed during login, opened too many login dialogs, or there is some issue with cookies, since we couldn’t find your session. Try logging in again from the application and if the problem persists please contact the administrator

PFB the link for HAR file HAR link

jmangelo · July 2, 2019, 1:29pm

In the case illustrated by that HAR the issue seems to be that when ADFS responds to /login/callback there’s no Auth0 cookie available so the error is triggered. However, why that cookie is unavailable cannot be explained from the HAR because the expectation would be that before going to ADFS there was a request to the tenant that would setup the cookie and redirect to ADFS, but the HAR does not include it.

rahul.bisht · July 2, 2019, 1:40pm

we are deciding on the auth0 hosted page based on domain whether this is an ADFS connection or normal username-Password connection.

So the Flow is

WPF Sample Application We choose username-password connection.
2.We are redirected to Auth0 login page.
3.We enter emailID with domain Name having ADFS support
4.User redirected to ADFS login page
5.After successfull login in ADFS page it is rediecting to Error page instead of sending the token back to sample WPF application.

The same thing works if i login with normal user having username-password connection in step 3.

jmangelo · July 2, 2019, 2:01pm

With that flow the cookie that is apparently missing in the /login/callback request should had been set at step two when you are directed to Auth0 login page. Can you attempt to capture an HTTP trace that shows that entire flow?

rahul.bisht · July 2, 2019, 2:40pm

I could capture this much only thanks.

jmangelo · July 2, 2019, 4:13pm

From that HAR I can see that the authentication request starts at:

https://[TENANT].eu.auth0.com/authorize

but then ADFS redirects to:

https://[CUSTOM_DOMAIN]/login/callback

A single login transaction needs to be started and completed in a consistent authority; in other words, it is not supported to start a transaction with the tenant domain and have a connection (upstream identity provider) send a response to the custom domain or vice-versa.

rahul.bisht · July 2, 2019, 5:23pm

Thanks a lot..

bneigher · July 15, 2019, 4:57am

I’m seeing this issue as well with react-native-auth0.
Consistently fails social sign-on the first time with the above error, and then on the next attempt it works.

return auth0instance.webAuth.authorize({
    scope: "openid offline_access profile email",
    audience: https://<my_api>,
    device: DeviceInfo.getUniqueID(),
    connection: <SET>,
    prompt: "login"

});

lehuydit · September 19, 2019, 8:27am

Also happened on my react native app.
I double-clicked on Button Login, It would show google login popup, click on Google login and show that Error Message

This issue only happen when build release with react native. Could not produce on Debug mode.

Any advices on this?
Thanks

junichi · March 23, 2020, 7:52am

I’m seeing this issue and it happen due to time drift in client device.
After fixing NTP settings of client device, the issue has been solved in my case.

dan.doyon · April 7, 2022, 4:21pm

We just started using custom domain in order to hopefully get around the ITP issue with safari. Once we went back to auth0 domain it works so it seems like its a cookie thing we need to dig into. Or this Custom domain not working react-native