RFC 9700, the current OAuth security best practice, says the resource owner password credentials grant must not be used. The app collects the user's actual password and sends it to the token endpoint, which widens the attack surface, trains users to type passwords into apps, and cannot work with MFA or passkeys.
What the password grant does
In the password grant, the user types a username and password into the client app. The client sends them to the authorization server and gets tokens back. It looks convenient, especially for first party mobile apps and scripts, and it often appears in tutorials because it needs no redirect.
The problem is that the client now handles the user's real credentials.
The reasons in the RFC
RFC 9700 gives these reasons for the ban:
- The grant exposes the resource owner's credentials to the client. Even a benign client increases the places where credentials can leak.
- It trains users to enter their credentials somewhere other than the authorization server.
- It is not designed for two factor authentication or for sign in processes with several interaction steps.
- Authentication with cryptographic credentials, such as WebAuthn, may be impossible with it.
That last point matters more each year. As more services move to passkeys, a flow that needs a typed password has nowhere to go.
What to use instead
| What you have | Use instead |
|---|---|
| Web or mobile app with users | Authorization code flow with PKCE, sign in on the authorization server |
| Command line tool on a developer machine | Device authorization grant, or code flow with a local redirect |
| Server job with no user | Client credentials grant |
| Legacy client you cannot change yet | Plan a migration, see below |
How to migrate a legacy client
- Inventory every client that still calls the token endpoint with a password grant. Your authorization server logs should show the grant type per request.
- Group them by type: interactive apps, command line tools, and scheduled jobs.
- Move interactive apps to the code flow with PKCE. Use the system browser for native apps.
- Move jobs to client credentials, with a dedicated client per job.
- Turn the password grant off per client once traffic stops, then off globally.
- Add an alert if the grant type ever appears again.
Is it ever acceptable
The spec text is a flat must not. Teams sometimes keep it for a migration window, but that should be a dated, owned exception, not a design choice. Where it remains, rate limit and monitor those requests, because the endpoint becomes a password guessing target.
Quick check
Does the password grant work with MFA?
RFC 9700 says it is not designed to work with two factor authentication or multi step sign in.
What replaces it for a command line tool?
The device authorization grant is a common choice, and so is the code flow with a redirect to a local port. Both keep the password on the authorization server.
Safeguard's policies and gates can hold a pull request until your review checks pass, and its SBOM and dependency scanning shows which auth libraries you ship. There is a free scan.
Sources
Last reviewed: 19 October 2026.
