Auth0 Home Blog Docs

How to use Username-Password-Authentication with custom UI on React Native



After reading through the docs, it appears I need to use the Proof Key for Code Exchange (PKCE) flow to use Auth0’s authentication API for authentication in react native on a custom UI.

I am confused as to how exactly this process incorporates Username-Password-Authentication. Where does it require the email or password and actually verify it to see if it’s a valid user?

The PKCE process seems to allow you to use Auth0’s Authentication API and the API itself does not have endpoints related to taking in username/password for mobile login.

If this is not the process I should use for authentication in react native with a custom UI, then what should I use?


The PKCE flow implies that the client application redirects the end-user to an identity provider/authorization server where the authentication and any applicable authorization is completed. For a database connection this means that the end-user inputs his credentials at the identity provider and not directly through the client application.

The client application will then just receive an assertion/token that can be used to know who is the user that just completed an authentication. This works, because a trust relationship is established between the client application and the identity provider and the assertion/token allows to validate that the token is indeed coming from the trusted party.

This flow has the great benefit that the client application does not need to directly process user credentials and as such does not need to worry in doing it in an incorrect way. However, this does mean that active authentication is performed outside of the client application, in this case, it happens as part of your account hosted login page (the /authorize endpoint part of the PKCE flow).

You can completely customize the hosted login page, however, if what you’re aiming for was a custom user interface within the client application itself then for database connections you could consider the use of the resource owner password credentials grant. Have in mind that the use of this grant is not available by default for new clients so you’ll have to make the necessary configurations in your client grant types in order to allow it. In addition, the recommendation is indeed to use PKCE because the client application will not have to process user credentials, but if you understand the implications and you are okay with them for you particular scenario then this would be an alternative that would allow direct exchange of a username and password for tokens.


this explanation is invaluable. adding it to the docs at and the mobile quickstarts would be really helpful.