[awinter-py]

Real question here is 'why isn't auth built in to the browser'. Lack of browser support is the reason oauth is so complicated (it relies on HTTP redirect to pass information around).

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.

[ejcx]

It is*

Credential Management[1] 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.

[1] https://w3c.github.io/webappsec-credential-management/

* you are using chrome

[tomjen3]

It is, and has been since god knows when: client certificates. Better than passwords because they can't be phised, doesn't require an email, doesn't require trusting any third-party service.

Unfortunately they are also very difficult to understand for even normal geeks and so basically no site use them.

[drdaeman]

It's not hard to understand ("you have the key, in a form of file or a hardware token, use it to open your account" is something average grandma can grok - no harder than passwords), but current UI and UX are terrible. Then it's chicken-and-egg problem: no one uses certificates because they're unuseable, and no one works on their usability because no one uses them.

[nickpsecurity]

We tried:

https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...

http://srp.stanford.edu/

Just not getting adoption it needs IIRC. Could be other explanation.

[callahad]

In the long run, authentication should be baked into browsers, and it seems like FIDO U2F is making decent strides in that arena.

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.

[pmontra]

Basically you're asking for an authentication standard.

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?

[closeparen]

Client cert support has been built into the browser for a long time.

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.

[bradleyjg]

If the client certificate distribution problem was a one-time per site thing it wouldn't be so bad. The issue is that people want to be able to use multiple browsers on multiple devices, and some of those browsers are in use by multiple people.

[drdaeman]

In theory, it's well possible to sync keystores (just like browsers sync passwords), or issue multiple certificates for a single account. There are a lot of options and scenarios well possible (no single size fits all, of course)

In practice, anything related to client certificates in browsers is not usable.

[bradleyjg]

If you are authenticating all the time to a sync server or a certificate granting server than that ends up being the real login process.

[drdaeman]

Yes, it is a login process and there has to be one somewhere under the hood. Whatever the scheme is - at some point, one has to authenticate.

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.

[aethertron]

Could it be done in a non-spoofable, decentralised way?

Xanadu is/was specified to include user authentication. No idea about the implementation there.

[jamesgeck0]

Yes. Mozilla Persona was explicitly designed with the intent of having auth as a feature in every browser.

[kruhft]

Auth is built into the browser[1], it's just ugly (popups) and nobody uses it.

[1] HTTP Basic Auth

[WorldMaker]

Nobody uses it because:

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.

[zimpenfish]

As a counterpoint, https://www.rdegges.com/2015/why-i-love-basic-auth/