What is the resource owner password credentials grant, and why is it discouraged?
The user types their username and password directly into the client, which sends them to the authorization server in exchange for a token; it brings back exactly the password sharing OAuth was invented to avoid.
In this grant (grant_type=password) there is no redirect and no consent page: the app collects the credentials itself and forwards them. It was intended only for clients the user trusts as much as the service itself, typically the service's own official app, or for migrating legacy apps that already stored passwords.
Why it is discouraged:
- The client sees the password, so it could store or misuse it. Users get trained to type their password into any app that asks.
- No multi-factor or modern login: the authorization server cannot show its own login page, so passkeys, second factors or federated login cannot be used.
- No real consent step, and the scope of what the app gets is decided without the user seeing it.
RFC 9700 states that this grant must not be used, and OAuth 2.1 omits it. For a first-party app the recommended alternative is the authorization code flow with PKCE, which gives the same user experience through the service's own login page.
Go deeper:
RFC 9700, Section 2.4: Resource Owner Password Credentials Grant — why the grant is now forbidden.- oauth.net: Password Grant (Deprecated) — the reasoning in a few paragraphs.