We are using Auth0 in our React Native app and we’d like to support a native login page. We have tried using the hosted login page and it’s just too crumb-some.
We are not able to use Auth0 iOS/Android/React Native SDKs because Expo doesn’t officially support those and using those SDKs would force us to eject from Expo, which we do not want to do.
The best approach we have come up with in this situation is to use a hidden webview that we submit using the information we collect from the user for both account creation and login. We are not planning to support SSO at this point, so FB connect etc is not an issue.
We want to know if this is the best approach we can take in this situation and if there are any potential pitfalls. Also if there’s some other Javascript api that we can use instead, for a more direct way of transmitting auth information to Auth0.
Authentication in mobile applications can take two basic approaches:
Browser-based authentication, where a browser is used to redirect the user to the authorization server’s domain to perform all the necessary steps (enter username password, MFA, consent and so on).
Ask the users for credentials directly in the application (the “resource owner password grant” in OAuth2/OIDC parlance).
Browser-based is the recommended approach. In this case, the application must use the device native browser (most platforms offer a good way to do this, even helping with session cookies to get SSO) and not a WebView. WebViews are controlled by the application themselves, and that makes it terribly insecure for users, especially when your application requests authentication from an independent identity provider, as nothing stops the application from doing things like eavesdropping what the user types or approving consent prompts without the user interaction. Some identity providers (like Google) explicitly don’t allow WebViews, and you can expect to be more common in the future.
If you are only going to do database authentication (no social logins), you can ask for credentials directly in your app (see this doc for a comparison between the browser-based approach and the “native” approach, as it is called in the document).
Now, the first recommendation with this approach is “don’t do it”, especially don’t in a new application:
The OAuth 2.0 spec describes the “resource owner password grant” as a last resource when the other flows are not available (it was mainly designed to ease the migration of legacy applications that can’t show a browser).
If I still can’t convince you, you can implement the Resource Owner Password Credentials flow in your application by making a request the /oauth/token (see the API docs) for authentication (the endpoint will give you a token response in exchange for the user credentials). You will have to manually turn the “Password” grant type for the application because it’s not enabled by default (hopefully you see a motif here). There’s a public signup endpoint as well, Authentication API Explorer, which is the same endpoint used by Lock and other native SDKs.