[Synthpixel]

While I believe that allowing CSRF is terrible practice, as a user of Doorkeeper, I think the problem here is Digital Ocean's atypical usage of OAuth2. When you request an access token for a resource owner in OAuth2, you are supposed _actually authenticate_ the owner. According to the OAuth2 spec[1], username and password are REQUIRED fields. Allowing clients to generate tokens based off of cookies is reckless.

Useful CSRF exploits depend on the server to trust session data to authenticate client actions. OAuth2 is designed for allowing external (third-party) applications to communicate with you. Cross-site requests are an expectation in OAuth2. If you ignore the spec and skip proper authentication, you're in a bad spot anyway.

[1] https://tools.ietf.org/html/rfc6749 (page 37 & 38)

[peter_l_downs]

    > 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.

[diafygi]

I can't name a single OAuth2-enabled website that does this. Facebook, Twitter, Dropbox, Google, LinkedIn, ...

They all let you approve if you are already logged in.

[ewang1]

Usually those implementations redirect the user to a separate authentication system. OAuth2 only handles authorization and not authentication. Upon successful authentication, the user gets redirected back to the OAuth2 request which then generates the authorization code.

When the user is already logged in via a cookie set by the authentication system (i.e. an existing valid session), they don't get prompted for a password again; the authentication system will simply redirect to the OAuth2 request url. The typical OAuth2 implementations shouldn't be reading the authentication cookies directly.

The "password flow" in OAuth2 is really a special case for those who want to bypass the separate authentication system and use OAuth2 directly for both authentication and authorization.

[jfarmer]

GitHub and LinkedIn do this, I believe.

[Synthpixel]

I can say that recently LinkedIn has asked me to reauthenticate on multiple occasions in the same session. I've had the same for Google but I have not tried recently. I'm aware that Twitter and Facebook allow you to do so, but I propose that none of the above give scopes without authentication that allow you to perform actions that charge an account.

That said, I agree that some of the giants are fine with using cookies for auth in OAuth2. And while that indicates that this is a possible use case, OAuth2 is capable of being used in many ways and Digital Ocean's usage still doesn't make much sense.