[ForHackernews]

> If you do use the authorization code flow securely (on the server side, with a strong client secret and proper CSRF protection)

This restriction precludes all desktop clients, mobile clients, and webapp clients -- any place where you can't trust the client code to protect a secret.

I don't exactly disagree with you: Security becomes much easier once you rule out handling all the hard edge cases.

[unscaled]

PKCE, OAuth 2.0 for Native Apps and the Device Code flow are a thing. In practice all of these clients work so well with OAuth 2.0, that the implicit and resource owner password credential grants have been removed from OAuth 2.1 and are the latest OAuth 2.0 BCP forbids the password grant and strongly recommends against the implicit grant.

[ForHackernews]

... so, then, there is a need for something other than a shared opaque random string API key?

I feel like I'm being argued in a circle by a series of strawmen.

[doc_ick]

Random strings aren’t truly random, can be predicted, and don’t carry information that can be used elsewhere