Hi,
I am trying to authenticate the user using google authentication in my React Native Expo app. After I hit the /authorize endpoint I get the the google login page which I display in a Web-view to proceed with the authentication. But this leads to a 403 (dissalowed_useragent) after the user signs in with their google credentials. This is due to Google’s policy change.
What would be a better/correct way to implement auth0-google-authentication in an Expo React native App?
Cheers!
Hey there @Adonandal! Google started blocking embedded login flows that utilize web views. You should be able to work around the issue with this information:
We also have this React Native Quickstart, I totally recommend giving it a look if you haven’t already:
Hi @James.Morrison !
Thank you for your reply!
I have already gone through the documentation you mentioned and as for the react native SDK in the quickstart it requires the modification of some Android and IOS files. I am using EXPO which is a tool chain/framework for react native and I can’t have direct access to these files in order to modify them. And I would like to use my own in app design for the initial sign up and login, instead of a web-view. So using the Auth0 Authentication API is the best choice for my scenario.
I have built my own sign up screen which uses the Auth0 authentication API, everything works just fine both database sign up, logins, and API calls. But the social authentication is a hassle with Auth0!
Is there a away to use the native google or facebook apps which are already installed on the mobile for authentication instead of the html page return from the auth0 authentication api? Or should one just forget about implementing social authentication with auth0 in these scenarios?
The google and facebook html returned from the auth0 authentication api look sketchy anyway and could be mistaken by the users for a phishing attempt. The users shouldn’t have to re-enter their username and password while they already are logged in on either google or facebook on their mobile I think.
Cheers!
After confirming with one of our TSE leads they were able to confirm you will most likely need to use a browser based flow instead of an embedded login flow since Google is blocking the request when it is in a web view. Please let me know if you have any additional questions.
Thanks @James.Morrison!
I managed to make social login work for some other providers than Google, but the redirect_uri for mobile apps (https://YOUR_AUTH0_DOMAIN/mobile) redirects to a white blank page with the word “Ok” on it for a second or two before proceeding.
Do you have any idea if it is possible to customize the content of (https://YOUR_AUTH0_DOMAIN/mobile) to show something else than a blank page with “Ok”?
Cheers!
Hey @Adonandal, when you see this message take place is it within the browser based work flow or is this still leveraging the embedded flow? Thanks.
Hey @James.Morrison!
This happens in the browser (Webview) flow when I authenticated using Facebook. after successful authentication I get redirected to https://YOUR_AUTH0_DOMAIN/mobile which shows a white page with the word “Ok” on it. I was wondering if I could customize the page’s look to make it fit my app design or to have a silent redirect instead, without showing the page, just getting a redirect success code instead?
Thanks!
Hi @Adonandal.
The https://your_auth0_domain/mobile endpoint is a legacy endpoint. It was used back in the days where mobile apps could use a WebView embedded in the application (i.e. a browser controlled by the app). Auth0 would perform all the interactive authorization steps (login, MFA and son on) through the WebView and send the final authorization response to that https://your_auth0_domain/mobile endpoint (in the URL). Applications were supposed to inspect the resulting URL, grab the response, and continue with the login flow.
Nowadays, for interactive login/authorization flows (browser-based), applications are supposed to use the device’s native browser for enhanced security (Google, for instance, does not allow WebViews anymore for authentication). By using the device browser users can be certain that the app is not spying credentials or giving consent to a prompt without the user intervening.
The authorization result is now provided by a redirection to a custom scheme (e.g. {PRODUCT_BUNDLE_IDENTIFIER}://YOUR_AUTH0_DOMAIN/ios/{PRODUCT_BUNDLE_IDENTIFIER}/callback in iOS or {YOUR_APP_PACKAGE_NAME}://YOUR_AUTH0_DOMAIN/android/{YOUR_APP_PACKAGE_NAME}/callback in Android, as explained in the React Native quickstart). These custom schemes are handled by the application itself, so that it can receive the authorization response and continue the flow.
The authentication API allows you to obtains tokens directly from your application in exchange for the user credentials (email/password) when the user is authenticated directly by Auth0 (i.e. a database connection) by using the Resource Owner Grant. This flow is generally discouraged in favor of a browser-based flow because of the increased security and SSO benefits, and should be usually reserved for applications that can’t use browsers.
But social logins cannot use the Resource Owner grant (no social provider would allow an external application to collect the user credentials). Note that we don’t support using the native Google or Facebook apps to log users in, so if you want to authenticate users using social providers you will have to use the proper browser-based flow with the device’s native browser (as shown in the quickstart).
You could, if you are so inclined, use some sort of hybrid approach where you let users type their credentials directly in the app (using the Resource Owner grant) when they want the email/password authentication, or open a device browser when the user wants social logins.
Hope that helps.
Hi @nicolas_sabena!
Thanks a lot for your detailed answer. I wasn’t aware that https://your_auth0_domain/mobile endpoint was a legacy endpoint.
I will try redirecting to the custom schemes as suggested, and get back to you if I have any further questions.
Cheers!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.