I am extremely confused as to what kind of sign in flow should be used by an auth0-powered application using React Native, or really any mobile app at all.
I have my application working fine with the password realm
However, the “grant types” settings of my app say that “Using Password or MFA grant types with public clients is not recommended”. Since my app seem to be a “Public App”, I had to turn that off.
The recommended solution instead seems to be a PKCE flow
The PKCE flow is super confusing and while I have it semi-implemented, it appears to always require showing a webview for the user/password form
Is this really how it should be? Can I not use send a user/password to get a token, or at least the code so I can get a token?
Auth0’s own React Native library uses password realm. If it’s not recommend, why is it used by the library and in the only login example?
A JS example of PKCE implementation posted in a previous discussion conveniently leaves our the function on how an Auth URL produces a code, not making it clear what needs to be done and if there’s an alternative to a separate window/frame
I have so many questions and the more I read the more confused I get. Previous discussions on the subject don’t seem to help much as they only repeat things already said with no practical examples or reasonings.
What is the correct login flow for a public React Native application that wants to have its own login form?
Can I not use send a user/password to get a token?
You can, it’s not enabled by default for new clients and is also not the recommended approach for native applications, but it’s supported so the libraries also have support for it.
What is the correct login flow for a public React Native application that wants to have its own login form?
If you want the login form to be located in the client application itself it’s not so much asking what’s the correct approach, but more what’s the available one which would be the resource owner password credentials grant. Using PKCE implies that authentication is performed through a centralized location outside of the client application itself.
You have requirements that exclude the use of PKCE and imply the use of approaches which are not the current recommendation; there’s no silver bullet for this situation. You’ll need to decide what’s best for your exact scenario and if you’re okay with having credentials pass through the client application itself which carries additional responsibility for the client application and also signals to users that it’s kind of okay to provide their credentials at multiple places (may simplify phishing attempts to your end-users).
there’s no silver bullet for this situation
You make it sound like this situation is uncommon, whereas to me it seems like pretty basic functionality. From my perspective, it doesn’t feel like react-native is actually supported (which react-native-auth0 examples contribute to – opening the browser is not what I’d call a native app experience).
It would be really helpful to have a better, canonical example of a react-native login that doesn’t open a webview (even if it involves a server component). (Or if there is one, please point it out.)
The situation is common and I would even say that opening some sort of browser (maybe not the full-browser) but a version of it optimized for this sort of integration is actually becoming very common. What I meant to say is that if you want login form completely in-app then you should go with resource owner password, but that has its implications. Going with the recommendation (PKCE+external user agent) means not being completely in-app.