The password grant
The first version of photos-cli, the photo service's own command-line tool, began every session the same way. It asked for your photo account's username and password, right there in the terminal, traded them for tokens, and, to its credit, never saved the password.
That trade was the resource owner password credentials grant, usually called the password grant. It was part of OAuth 2.0 from the start, and current security guidance says it must not be used.
A token for a password
All values in these examples are fictional, including the password. The tool sent what you typed straight to the token endpoint:
POST /token HTTP/1.1
Host: auth.photos.example
Content-Type: application/x-www-form-urlencoded
grant_type=password
&username=you%40mail.example
&password=demo-password-not-real
&scope=photos.read
&client_id=photos-cliThere is no browser, no redirect, no code, and no approval screen. The authorization server checked the password with its normal sign-in logic and, if it was right, returned an ordinary token response, often with a refresh token so the tool would not need the password again. A confidential client would also have authenticated itself in the same request. photos-cli, installed on many people's computers, was a public client and sent only its client ID.
Why it was included
When OAuth 2.0 was written, plenty of applications already held users' passwords. Desktop mail programs, phone apps, and scripts signed in to APIs with HTTP Basic or Digest authentication, sending the password with every request and storing it so they could. RFC 6749 offered the password grant as a step away from that: exchange the password once for a token, then forget it.
The specification hedged it heavily. It described the grant as suitable only where the person had a high degree of trust in the client, such as the device's operating system or a highly privileged application, and only when other grants were not available. In practice, many services also used it for their own applications, where the tool and the authorization server belonged to the same organization. If photos-cli is the photo service's own tool, why send you through a browser to type the same password into the same company's page?
What it costs
The answer is that the password grant keeps the very problem OAuth was created to remove. The client sees your password. Even a well-behaved client can leak it through a crash report, a debug log, or a compromised computer, and a less honest one can simply keep it. The authorization server cannot tell whether the request came from you or from a script trying stolen passwords, which is why RFC 6749 itself required the endpoint to be protected against brute-force attempts.
It also freezes sign-in at a username and a password. The client knows how to collect two fields and nothing else. If the photo service adds a second factor, offers passkeys, or lets business accounts sign in through their company's identity provider, the password grant cannot take part, because none of those steps fits into a form that the client posts. Passkeys and similar credentials are usually bound to the authorization server's own web origin, so a form inside another application often cannot use them at all. Services that kept the grant often found it was the one sign-in path their stronger protections did not reach.
You lose your part in the decision, too. There is no approval screen, so nothing shows you which application is asking or what it will be able to do; the client chooses the scope. And every legitimate application that asks for a photo service password teaches people that typing it into other applications is normal, which is exactly the habit a phishing page relies on.
Current guidance
The OAuth 2.0 Security Best Current Practice, RFC 9700, is direct: the password grant MUST NOT be used. It names the exposure of the person's credentials to the client, the habit it teaches, and its incompatibility with multi-step and cryptographic authentication. OAuth 2.1, the working group's consolidation of OAuth 2.0, leaves the grant out as well.
The replacements depend on the client. An installed application, whether it belongs to the photo service or to someone else, opens the system browser for the authorization code flow with PKCE, as Native applications described. A command-line tool like photos-cli can do the same with a loopback redirect, or use the device authorization grant when it runs where no browser is available, as Command-line tools compared. Either way, the password is typed only on the photo service's own page, which can ask for whatever else the account requires.
The most common reason the grant survives today is automated testing, because a script can sign in a test user without driving a browser. Tests have better options, such as a test authorization server that issues tokens for test accounts, or client credentials when the test concerns a service rather than a person. A grant left enabled for tests tends to stay enabled for everything else as well.