Slashdot Mirror
A Truckload of OAuth Issues That Would Make Any Author Quit
New submitter DeFender1031 writes "Several months ago, when Eran Hammer ragequit the OAuth project, many people thought he was simply being overly dramatic, given that he gave only vague indications of what went wrong. Since then, and despite that, many companies have been switching to OAuth, citing it as a 'superior form of secure authentication.' But a fresh and objective look at the protocol highlights the significant design flaws in the system and sheds some light on what might have led to its creator's departure."
Step four: suddenly realize you posted under wrong article
I used to have a good sig...
That's it, I've had enough. It's easy enough to filter this kind of crap out, but /. just don't seem to bother. Yes, I could simply browse at a higher level, but I've usually got mod points and browse at -1 as suggested for very good reasons. But if /. aren't prepared to deal with the most basic levels of spamming then I can't be bothered helping them out any more. Email address deleted, password changed to a long random string that I don't know, sig changed to indicate account has been deleted. Bye everyone, most of the last decade or so has been fun, but frankly, I quit.
Please consider this account deleted, I just can't be bothered with the spam anymore.
I've implemented sites that use a variety of third party authentication schemes. Its a nuisance for users (multiplicity of accounts, more insecure passwords to remember etc) and a nuisance for developers. Why are we still doing this? Authentication (and user profiles for that matter) belong in the user's browser. I'm not talking about Chrome's password wallet. I'm talking about a certificate-based system that allows the user to control from their end which sites are authenticated, and what data they should have access to. Sites would then implement a simple API (possibly combined with meta data on the front end to let the browser know details) that would allow for login, signing up, or changing particulars. The process could be made completely transparent for users. I have this partially implemented as an insecure proof of concept browser plugin. It wouldn't take too much work to get it running, although it really should be core browser functionality instead.
I think the key point of the article is the first part, the "APUI" section. OAuth is "fine" when used for authentication by a user for a service based on a web browser. However, it is increasingly being applied at the "API" level (where services and applications interact, not users). It doesn't work _at all_ at this level.
I agree that the enterprise level permissions bit is pushing things, but the rest of the article is spot on.