Auth module response handler expects .json keys presence when it is not returned in successful request

[higgins]

Description

Auth module response handler expects .json key that does not exist on status 200 response.

Reproduction

const makeAuth0Client = () => (new Auth0({
  domain: REDACTED,
  clientId: REDACTED,
}));

try {
  const { idToken, refreshToken } = await makeAuth0Client().webAuth.authorize({
    prompt: 'login',
    scope: 'openid offline_access',
  });
} catch (e) {
  console.log(e);
}

see the following error

a0.response.invalid

Inspecting what src/auth/index.js#responseHandler receives, we see no .json key present, hence the throw.
{status: 200, ok: true, headers: REDACTED, text: "OK"}

Environment

react-native-auth0: 2.3.1
iOS: 11.0
react-native: 0.62.2
osx: 10.14.6

[lbalmaceda]

Can you describe the steps you follow to log in? i.e. "launch web auth, click on twitter connection, type my credentials, the browser closes and my app shows this error"

[higgins]

Can you describe the steps you follow to log in? i.e. "launch web auth, click on twitter connection, type my credentials, the browser closes and my app shows this error"

1. Launch web auth
2. We are presented with email, password form
3. Enter valid credentials
4. Tap "log in"
5. The form submits credentials
6. The response includes keys [status, ok, headers, text] but no json
7. The view/modal the web form is in disappears (slide-down)
8. We catch the error and throw invariant displayed in

The Auth0 dashboard shows a successful login (under the user's history tab).

We expect to see idToken somewhere in payload (assumedly in the .json property), but it isn't in the response body either.

[lbalmaceda]

Thanks for that.
Actually, there's a PR we recently merged that changed how we handle the responses (#285). Could you please try If this still happens with the version immediately prior to that? That would be 2.3.0. See if you are able to log in or if you get a different error message.

[higgins]

Could you please try If this still happens with the version immediately prior to that? That would be 2.3.0

hmmm, we rebuilt on 2.3.0 and see the same error

[lbalmaceda]

@higgins I've tried to reproduce this following the steps you shared above and I did not run into any issues. Neither with iOS nor Android, using version 2.3.1. Please, check your lock file and be sure the version you're using is the latest. If not, you'll have to share with us more details like logging the network requests to understand what URLs are being called and what the server is responding.

[higgins]

@higgins I've tried to reproduce this following the steps you shared above and I did not run into any issues. Neither with iOS nor Android, using version 2.3.1. Please, check your lock file and be sure the version you're using is the latest. If not, you'll have to share with us more details like logging the network requests to understand what URLs are being called and what the server is responding.

@lbalmaceda thank you for your patience and trying to reproduce! yes, we are using version 2.3.1 (confirmed with lock file and installed node_module).

independently, we decided to move back to our earlier integration with the auth0 rest endpoints

thank you again for your research here!

[lbalmaceda]

@higgins I'm sorry you had to make that regression. It would be nice if you could provide us with any additional context that can help us debug this even further. You already shared the code snippet and the versions you were using. What about the networking logs? Stripping any sensitive data that could be included.

@Widcket can you come up with anything that can go wrong in this iOS setup?

[higgins]

without setting up a network proxy (safari simulator bridge won't let you persist network requests as far as i can tell), here's what we see from tracing via console.log:

1. We show the password form here: https://github.com/auth0/react-native-auth0/blob/master/src/webauth/index.js#L74
2. Receive a valid redirectUrl as per this condition: https://github.com/auth0/react-native-auth0/blob/master/src/webauth/index.js#L76
3. Receive a payload that does not include an error code (and does include code and resultState fields) upon parsing as per here: https://github.com/auth0/react-native-auth0/blob/master/src/webauth/index.js#L85-L86
4. Then pass a payload that includes the keyscode, code_verifier, redirect_uri along with a client_id as specified here: https://github.com/auth0/react-native-auth0/blob/master/src/auth/index.js#L114-L115
5. Then we error due the response not include a .json key as required here: https://github.com/auth0/react-native-auth0/blob/master/src/auth/index.js#L8

I hope that helps!

FWIW, we wonder if it USER dependent and not environment dependent. We've cleared as many caches as we can think of and still see the issue BUT this works fine for a different developer on our team. Same code, different credentials, returns response client expects. 🤷‍♂️

[lbalmaceda]

FWIW, we wonder if it USER dependent and not environment dependent.

Do you mean that it works fine with a different Auth0 client_id / domain? That would make a lot of sense. It could be a configuration issue on the application (auth0 dashboard). I'll wait to hear from you if that's the case to help you out.

[higgins]

Do you mean that it works fine with a different Auth0 client_id / domain? That would make a lot of sense. It could be a configuration issue on the application (auth0 dashboard). I'll wait to hear from you if that's the case to help you out.

Sorry for the delay @lbalmaceda ( i was out last week )

No, we weren't able to reproduce for different user+password (with the same client_id and domain).

[lbalmaceda]

I'm still a bit confused. The developer on your team has tested this using the same code with the same client_id and domain as you but using a different username + password, and they are being able to log in and you are not. Did I get that right?

If so, it would be really helpful to see those network logs (e.g. https://github.com/jhen0409/react-native-debugger). Or knowing for example if the user has MFA enabled, or if your app has any Rule that could change their particular user object.

[higgins]

I'm still a bit confused. The developer on your team has tested this using the same code with the same client_id and domain as you but using a different username + password, and they are being able to log in and you are not. Did I get that right?

correct.

it'll be a while till we can give the network logs as we're midway through a big upgrade and we've already removed this dependency. FWIW, the react-native-debugger network logs were not informative as the login flow redirects us to a webview (where the auth0 response is captured) before directing back to the app. Safari does allow a bridge mode to inspect the requests of a simulated device in that webview, but it won't record those requests (dang).

The summary pasted above is the best detail we can give as to the shape of the response at this time! 🙇

[llaver]

Hello, I am having almost the same issue on 2.7.0.

Same exact process, but instead of username/password, we are using social login: connection: 'google-oauth2',.

All signs point toward a successful login (webauth closes, logs show successful auth and exchange, etc.) but the error is thrown due to no json. Comparing the social login user account to a username and password user account (/authorize, so no issues there) in the auth0 dashboard, there is nothing to indicate that there are any differences or issues with the social login user account.

Edit:
I removed the connection to attempt to login with username and password through webauth (using the account that previously worked with /authorize), and still receive the error, so for some reason, no json property is coming back from the webauth (perhaps due to the deep link?), or maybe some kind of configuration issue.

[Mr-Fraser]

I don't understand why this issue is closed, is the solution to revert to rest apis??

I am having the same issue with social signin on Android only, error we get though is "network request failed"..

Shows successful login in auth0 user history but crashes the app after returning from webview to the app.

I have a separate issue created on the following link and have reached out to support audi but with no fix yet either..

#379

[higgins]

I'm not in an environment to reproduce this bug anymore, but reopening as it appears to still be affecting folks

[llaver]

I've done some further research into my case and found an interesting detail. Note, I have only tested this on android.

The bug only seems to occur while the application is in debug mode. When I turned off remote js debugging (just debug/stop debugging on android), and debug only through the output console, I was able to get the login flow to complete and receive a valid token.

So far, stopping debugging is the only workaround I have found, but for now it's workable.
I have not looked more into the react-native-auth0 source for details as to why this is happening.

Environment

react-native-auth0: tested on 2.7.0 and 2.8.3
android: 10
react-native: 0.63.3

Note to other developers, not specifically related to this issue:
We were having a hard time debugging due to this issue, but we found out after getting past this that, in our case, .webauth.authorize({}) needed the audience parameter as well, even when only used for social login.

[lbalmaceda]

@vishnuchd @Mr-Fraser @llaver Apologies for the delayed response. Can you reproduce this consistently every time you run the app?

I downloaded the sample app (from here) and changed it to send a scope, connection, and audience value when doing web auth.

Still, I cannot reproduce the error you are showing. Look at the videos for both scenarios with and without a specific connection requirement:

-- without specifying connection

Harlequin.Hawk.-.ULP.mp4

-- specifying google-oauth2

Cyan.Lynx.-.Google.mp4

I've tested these using a google social account, as was claimed here that a DB connection works fine.

I believe the best way for us to debug this, given that there's a second issue for a similar bug report, is for you to give us a small sample app that when we run we can see this same issue you describe above. You can do as I did and take the sample app and copy the code changes you make here.

[ANIBIT14]

@lbalmaceda Hi facing the same issue keeps getting this in the catch part of the code [TypeError: Network request failed]
using this as code
const socialLogin = (connection: string = 'google-oauth2') => {
auth0.webAuth
.authorize({ scope: 'openid profile email', connection })
.then(credentials => {

    console.log(credentials);
  })
  .catch(error => {
    console.log('error social LogIn', error);
  });

};
not much is different from the code you posted above, and the thing is this error only happens on android, it works completely fine on iOS, checked the documentation again and again, checked the native setup, checked the sample app, everything is exact as described setup wise

[lbalmaceda]

@ANIBIT14 Is this for every run of just random ones? Maybe relates to a proxy or DNS issue on your device side. Are you able to check if the JWKS URL is accessible?

[ANIBIT14]

@lbalmaceda this is for every run on android. JWKS URL is accessible on my device browser I checked.

[lbalmaceda]

@ANIBIT14 I'm afraid that without new debugging info, different from what the rest provided above and that I used to attempt to reproduce the issue, I cannot help.

It seems like it's failing to fetch the JWKS, which is then used to verify the received ID token. Have you tried with a physical device or a different android emulator? Perhaps you can debug the network request using the approach described here to understand why that request is failing.

[ANIBIT14]

@lbalmaceda I am trying on physical devices, I even made an apk and tried. Will try debugging the network request

[ANIBIT14]

@lbalmaceda for me the issue was happening because of this; react-native issue facebook/react-native#27250
after adding the updated implementation of okhttp, all social logins works great

[Widcket]

Closing as @ANIBIT14 was able to solve the issue.