We’re planning to use Resource Owner Resource Grant as explained here https://auth0.com/docs/api-auth/tutorials/password-grant#optional-customize-the-tokens, to implement Authentication in our mobile app.
We prefer this instead of Proof Key for Code Exchange (PKCE) OAuth 2.0 grant. https://auth0.com/docs/api-auth/grant/authorization-code-pkce because we want to provide a simple login form for our users to login instead of having them to redirect to Auth0.
In the Resource Owner Resource Grant, the client secret must be passed during authentication and hence must be stored in the client. What are the risks if the secret is compromised? As far as I know if the secret is compromised, there should be little damage if client is only allowed access to a specific API only.
Here is how I will setup the app:
Api
-. Create an API called mobile API using Signing is using algorithm HS256.
-. No custom scope is provided.
Create a Non Interactive client that have access to that API only.
Or is there a simple and secure way to authenticate using username and password form in mobile apps?
You should configure your client application with the Native client type and enable the appropriate grants for the resource owner password credentials grant. If you do this then the token endpoint authentication method should be automatically set to none which means that the client application won’t have to provide a client secret; you should not include the client secret in the mobile application, if it’s a public client then it’s unable to maintain it then you should correctly configure the application as a public client so that the secret is not required.
Doing the above means that the mobile application will be able to exchange the credentials the user provided for an access token suitable to call the mobile API (you would pass the audience parameter during the exchange or configure a default audience). With this flow there should be no need for a non-interactive client application to be introduced in the system so your mention to one is a bit confusing. If this does not completely clarify your situation you should provide more details about why do you believe a non-interactive client application is required for your use case.
As an additional note, more for other users that may be contemplating a similar decision between centralized login through browser versus directly in the application the following reference documentation may be useful:
https://auth0.com/docs/tutorials/browser-based-vs-native-experience-on-mobile