Imagine a web experience sans cookies and sans JS. If you take into account the economics of content, it can only happen with browser-mediated login.
Unfortunately they are also very difficult to understand for even normal geeks and so basically no site use them.
Just not getting adoption it needs IIRC. Could be other explanation.
For right now, I think Portier hits a sweet spot for smaller sites without a lot of time or energy to put into building out bespoke authentication integrations.
Some de facto standards are completely client side.
Browsers embed at least the "fill form/remember password" authentication method. It's not a standard and some people use it. Some people use an external password manager instead (I do, keepassx). Some password managers come with addons for the major browsers. Other people don't use anything and try to remember passwords, sorry for them.
Maybe your question was why don't browsers embed oauth?
About the sans cookies experience, with oauth or without it, there should be a standard way for browsers to send authentication info in the request. I don't see another way, but I might be wrong. Basic auth is a way, cookies are another. Both are ok only with https. What do you suggest instead?
One problem is that you basically have to build out non-cert authentication to give people certs to install. That, and there's little to no mutual trust, so every institution needs to issue and manage its own certs.
In practice, anything related to client certificates in browsers is not usable.
The trick is, you set it up once and then your user agent does it for you, so all you have to do is set up sync (or any other option) once then never bother but just hit the "okay, log me in here" buttons, optionally, choosing an identity (certificate) if you have many.
Xanadu is/was specified to include user authentication. No idea about the implementation there.
 HTTP Basic Auth
1) HTTP Basic Auth sends passwords over plaintext. (Digest Auth at least hashes passwords, but isn't a huge security win either.)
2) Basic Auth still requires user management and if you are going to build a user management database you might as well build a login flow in HTML instead of basic auth (not just because basic auth is ugly but because you can own that login flow and provide handy things like password recovery which basic auth doesn't support).
As pointed out elsewhere, HTTPS Client Certificates are a much better option baked into every browser, but we've never figured out the UX to make it convenient for the average user.
Credential Management is newly ratified (or will be ratified soon I lose track at this point. Mike West works fast). Either way, the api is exposed to chrome.
The best I can understand is that Google and Apple both want to store your passwords in the browser/keyring, and sync them between your devices. Apple has begun "suggesting" passwords in Safari that are fairly strong.
It's scary to think about, but "browser" is already the most used "password manager". It just is not full featured yet.
* you are using chrome