The OAuth 2.0 RFC specifies the 'password' grant type, where the user provides the username and password directly.

I'd contest the claim that OAuth was not intended for authentication, because there are no authz uses for the password grant.

It famously wasn't intended for authentication, which is why OIDC was developed on top of it. Trying to run a delegated authorization protocol as an authentication protocol caused vulnerabilities.

There are obvious authz uses for the password grant: you use it when you want to delegate access to a client running on your desktop, which is in your custody, and there's no point in running a multi-legged authorization protocol because you can just log the client in yourself. Your first thought about that might be "that's authentication", but it's not: you don't have to give all-or-nothing access (in theory) to such a client.

OAuth 2.0 password grant can be (mis)used for authentication the same way that LDAP Bind is used for authentication. That doesn't make either of them an authentication protocol.

I've been seeing more and more apps and websites have me login with my xyz app login info. Then, ask if it's ok to grant access to xyz app so it can access xyz app information. Makes sense only if you are a developer. You are granting the frontend access to the backend via oauth. Completely confusing for everyone else and was pretty confusing for me at first as well.

In fact, there id say that the huge majority of oauth flows on the web are used for authentication at this point.

If you mean, like, logging into things with Google, sure, but isn't that technically OIDC? If you mean to say "most OAuth is used for OIDC, and is thus authentication", that's a different and less interesting claim. If instead you're saying that vanilla OAuth is primarily used for authentication, you're saying something more interesting (and problematic). You can use vanilla OAuth to log in, but you're adding a particularly subtle class of possible flaws in your design by doing so.

I mean the former. The primary use case of oauth on the modern web is to support openid connect. So much so that I expect it'll be a "SSL vs TLS" thing in the future where we actually use "oauth" to refer to the entire openid connect flow.

Sure, OK. But this article really thinking about OAuth authentication in terms of OAuth itself, not OIDC. The dominant use of TCP on the Internet is (I hope?) to fetch URLs, but HTTP is not TCP. :)

To be more precise, the flows are used to initiate authentication. They do not actually perform it.

Counterpoint: although SSN was not intended as a means of identification, it evolved into being used that way.