Should I use the password grant or the Login API when building a mobile application and not using a webview?

dan

Should I use the password grant or the Login API when building a mobile application and not using a webview? I want to build my own UI for login/forgot password, etc.

dan

First, we recommend a webview or system browser. They have different strengths. The system browser is recommended by the security BCP and is preferred if the mobile app is not built by the same development organization as is running the identity provider (FusionAuth).

However, if both mobile app and IdP are owned by the same organization, a webview is fine too, and can offer more control over the user experience.

That said, some folks, as mentioned in the question, don't want a webview. They want to build the login experience out of native UI components. This gives them full control:

In that case, there are a few consequences:

the Authorization Code grant is not possible to implement, because it requires the user authenticate at FusionAuth.
You will be re-implementing all of the "hosted login pages" logic and flow using the API. See https://fusionauth.io/docs/v1/tech/core-concepts/integration-points/#hosted-login-pages for the list of functionality you should be prepared to re-implement.
Your mobile app will see username and passwords. Prepare for that from a security perspective.
You will need to choose between the password grant and the login API

These are functionally equivalent. Arguments in favor of the Login API:

Richer response (you get different status codes for things like MFA required or "user not registered to this application")
Can be protected with a tightly limited API key. You could actually provision an API key per mobile device if needed, using the API key API and some custom code: https://fusionauth.io/docs/v1/tech/apis/api-keys/

Against:

You must embed an API key in your application or relax certain security settings
Tightly couples your application to FusionAuth

Arguments for the password grant:

It's an OAuth grant, so code written against it is more portable.
No API key needed.
No security requirements need to be loosened.

Arguments against:

You'll have to be prepared to parse JSON in the response if you are in any exceptional cases (MFA enabled, etc).

HTH.