I have a public-facing application that uses ASP.NET Core Identity to store first-party logins, and no intention of using third-party IdPs like Facebook or Google. I want to build the front-end in React, and the application comprises an API fronting a couple of back-end services to which I'll need to forward JWTs for authorisation.
The plan so far is to use Identity Server 4 as the IdP for the project, backing it into the ASP.NET Core Identity data stores.
Current guidance is to use Authorization Code Flow with PKCE, which would require redirection to the IdP, two sets of styling etc.
In this scenario, where there is no possibility of a third-party IdP, is Resource Owner Password Grant still highly discouraged? On the face of it, it gives a neater experience:
What issues will I introduce by pursuing the ROPC grant in this specific situation, vs accepting the need and duplication involved in a redirect-based flow to the IdP?
AMOUNT OF WORK
This is one of the big issues. As well as a login screen you'll have to make sure other areas such as Forget Password also work. If you build a second app you'll need to make it work there also.
EXTENSIBILITY
This article summarises problem areas. One of these is no scope to ever extend login solutions.
SECURITY
Token refresh does not (usually) work with ROPG, which leads to long lived access tokens and other complexity. Also, with OAuth it is recommended that the app never sees credentials.
From a security viewpoint it looks more modern to redirect the user - all the big providers do it - eg Google, Microsoft.
BRIDGING SOLUTION
As you say, if the password is private to your app it may not be the worst thing in the world. Capturing a user's Google password in your app would be a bad thing though.
ROPG has its uses but does not have much of a future - it is deprecated in OAuth 2.1 and providers will be getting rid of it. So I would also recommend what LalitaCode suggests ..