Last Updated: Oct 2, 2024
Overview
This article provides details on how to implement native login with React Native and Expo.
Applies To
- Native login
- React Native
- Expo
Solution
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 the 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 it will be more common in the future.
In the event of only doing database authentication (no social logins), there’s the ability to ask for credentials directly in the app (see this doc 20 for a comparison between the browser-based approach and the embedded approach).
Now, the first recommendation with this approach is “don’t do it”, especially don’t in a new application:
- The OAuth 2.0 spec 12 describes the “resource owner password grant” as the last resort when the other flows are not available (it was mainly designed to ease the migration of legacy applications that can’t show a browser).
- The OAuth 2.0 Threat Model and Security Considerations, on the Resource Owner Password Grant, 13 mentions 6 different possible threats and recommends that “Except for migration reasons, minimize use of this grant type”.
It’s encouraged to read Why the Resource Owner Password Credentials Grant Type is not Authentication nor Suitable for Modern Applications 27 for an explanation of the possible threats.
If the decision is still to choose a native login experience, the next step would be to implement the Resource Owner Password Credentials flow in the application by making a request the /oauth/token (see the API docs 19) for authentication (the endpoint will give a token response in exchange for the user credentials). This will require to manually turn the “Password” grant type for the application because it’s not enabled by default. There’s a public signup endpoint as well, Authentication API Explorer 28, which is the same endpoint used by Lock and other native SDKs.