> According to the OAuth2 spec[1], username and password are REQUIRED
    > fields.  Allowing clients to generate tokens based off of cookies is
    > reckless.

It's possible I'm not understanding you correctly, but the section of the spec to which you linked is describing the "Resource Owner Password Credentials Grant", just one _possible_ flow for requesting an access token. In that same section the spec reads:

    > The authorization server should take special care when enabling this
    > grant type and only allow it when other flows are not viable.

(read that section here: https://tools.ietf.org/html/rfc6749#section-4.3)

If you read the authorization grant overview section (https://tools.ietf.org/html/rfc6749#section-1.3), you'll see that the spec also defines an "Authorization Code" flow (https://tools.ietf.org/html/rfc6749#section-1.3.1) – this is what most sites implement.

Also worth reading is the section of the spec dedicated to security considerations (https://tools.ietf.org/html/rfc6749#section-10). There is an entire subsection regarding the password authentication flow you're referencing. Choice excerpts:

    > This grant type carries a higher risk than other grant types because it
    > maintains the password anti-pattern this protocol seeks to avoid.  The
    > client could abuse the password, or the password could unintentionally be
    > disclosed to an attacker (e.g., via log files or other records kept by
    > the client).

    > The authorization server and client SHOULD minimize use of this grant
    > type and utilize other grant types whenever possible.