Modern security flow/process for trusted Mobile and SPA apps with self-hosted OIDC

Question

Currently, there are two common auth flows i know:

• Resource Owner Password Flow
• Authentication Code Flow + PKCE (didn't mention other, since this one is more robust within redirect-based)

This theme was discussed long and across, but for primitive non-security-expert guy like me it's not clear, why should i ditch ROPC for Mobile and SPA apps:

• which my team develop itself and trust
• which performs authentication (and further authorization) via OIDC self-hosted by the same team
• which uses accounts only from our self-hosted OIDC (keycloak, mb hydra) and registration performed there too
• with no plans to support third-party auth providers or SSO
• which operate only via https and server-side use only Let's Encrypt certificates
• with ports protected/ssl-verified by nginx (in fact there are 3 layers with token presence checks and jwks)
• with ports protected against some very common attacks by ufw

My understanding is that ROPC vs ACF + PKCE (in common systems like ours) is more about human mistakes which may be allowed during system design ?
If Attacker finds out victim's password, there is no difference between ROPC and redirect-based flows, if so, why should i care about ACF at all ?
Even if server's private key got somehow leaked, during the MITM Attacker doesn't need any code challenge parts, he can just install this App and authenticate via leaked user password to get the data.

If my understanding meet the reality, am i missing some even straight algorithm, than self-hosted OIDC and ROPC ?

self lyrics:
I'm definitely vote for redirect-flow, but this approach is so unmatured (in terms of software) nowadays, that users always suffer from Android and IOS bugs during second redirect, browser versions, installed custom protection software on their phones and the abyss of other App <-> Browser interaction issues during auth.
I encountered issue myself even authenticating on Amazon.

Answer 1

OAuth is a delegation protocol to enable platforms to delegate a limited access to a resource to a third party. Your use case is a first party one as you already highlighted: resource server(s), client(s) and authorization server are run by the same organization.

The ROPCG will be removed in OAuth 2.1 as it breaks with this delegation pattern and makes implementing two-factor authentication very difficult.

But even in the first party scenario OAuth with its redirect flows will provide benefits:

1. You do not have to trust the client(s) and the people developing them even if they are your own ones.
2. You reduce the attack surface drastically: Only the authorization server has access to the users credentials.
3. Only in redirect flows allow strait forward implementation of two-factor authentication like TOTP or WebAuthn.
4. Usability issues: Having only one place where the user enters his credentials, communication to the user about error during login is much simpler than with the limited error codes during ROPCG.
5. Single Sign On does not work as the user has to enter his credentials in every app as there is no shared session.
6. The user cannot benefit from saving the credentials in his preferred browser as the browser is not used at all.
7. The user is teached to enter his credentials in some app asking for them. In redirect based flows, the user interface is always the same and he might even be instructed to verify the authorization servers URL. This might result in phishing to be more likely.
8. OpenID Connect is not specified for ROPCG.
9. Single Sign Out is not possible as the ROPCG is not specified in OIDC and federated Sign Out is very difficult to implement in this flow.

However the decision is up to the developer. But it is important to have all facts available.