Auth0 Home Blog Docs

React Native Login without WebAuth


I want to use Auth0 for login but i do not want to use the webauth client. I want a seamless, popup-less experience. This is my employer’s requirement and is not negotiable.

I installed auth0 to my project and used react-native-link to link it, the shell said it was successful.

I’m following the code on the readme for the auth0 github repo and i get this message:

Error: Grant type '' not allowed for the client.

I configured the auth0 object with my domain and client id and then i tried this call:

          .passwordRealm({username: "usernamethatexists", password: "correctpw", realm: "Username-Password-Authentication"})

The “Username-Password-Authentication” realm name came from my client settings / connections page.

Can anyone point me in the right direction? How can I send an api request to auth0 and get a token as a user, from my mobile app?


You most likely haven’t enabled the password grant for your client. Please refer to this guide which will show you how to enable the grant type on your client.

That said, we strongly recommend using authorization code grant with PKCE for mobile applications. You should only use the password grant as a last resort, for example, in a legacy application where a redirect-based flow would not be possible. It’s not secure and exposes you to man-in-the-middle attacks.


Richard, thanks a lot for your quick reply!

I’m going to try to enable that grant type now. I did see the authorization with PKCE article and was considering following it but it seems like it also requires popups and web browser use. Is this not the case?

I just want my users to put in their username and password and sign in. I understand that oauth flows using other identity providers require multiple steps but I don’t understand why the database sign-in should. Is there a way to handle the oauth flow for PKCE with code only?

Thanks again!


It’s true that authorization code with PKCE requires using the browser, but it brings a number of benefits beyond security (which should be your primary concern):

  • It’s simple to implement.
  • You don’t need to build your user interface from scratch.
  • Easier to maintain. If you wish to later introduce features such as multi-factor authentication, you don’t need to modify your application.
  • You can still customise the universal login to make it feel like you’re still in the application.
  • Better support for SSO.

I should also point out that the password grant was never intended as a primary means of authorizing clients. It was created as a bridge for legacy clients that use older authentication schemes such as HTTP Basic or Digest.


I’m definitely interested in best practices and security, of course. If there isn’t a way to handle the PKCE flow with code only, then can i use public key pinning to reduce the risk of MITM?

For an app that just tracks your meals and takes no personal info or payment info, sending my users to a web view is just not acceptable. Security is a primary concern but so is UX.

I got everything working great with the password grant, by the way so thanks a lot for that. I still don’t understand how there is a need for any of this complex auth flow though. From what I’ve read, PKCE helps you in the case your traffic is intercepted while logging in. If I’m using https and public key pinning, how do I benefit from this? They can intercept the traffic all day and will not be able to decrypt it, and they ca try to get the user to install a fake certificate but if they’ve logged in with the real one before it will be pinned. Are you aware of any resource discussing what exactly PKCE has that goes a step beyond the standard https handshake?

Thanks for all your help and comments!


This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.