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."

Re:

[Anonymous Coward]

Can a hosts file block apk's posts, though?

Re:

[Anonymous Coward]

127.0.0.0 slashdot.org

Re:

[FatdogHaiku]

Not really but it always gets modded down to -1 so you might adjust your slashdot settings to hide -1 posts...

brain asplode!

[Thud457]

oh man, that incredible interminable list of responses is almost as funny as the original post. This is getting to be truly epic. If there were and admins around any more that gave a damn, expect some ham-handed attempt at anti-trolling code soon -- that'll fuck /. up ever further for everybody else.

Get out the duct tape

[sl4shd0rk]

*sigh* "conflict between the web and the enterprise worlds." is another way of saying users complained when not given an option to aim at their foot.

Re:

[jhoegl]

I stopped reading at "There is no standard".
Computers run on standards, there is no excuse for this.

Re:

[thelovebus]

What are you talking about? The original submitter? Eran Hammer? The blog being linked to?

I honestly don't know what you're referring to -- could you explain for those of us who are out of the loop?

Re:

[EvanED]

I think it's a complaint about (and I hesitate to link to it) this post [slashdot.org] which keeps showing up story after story.

Last Post

[History's Coming To]

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.

Re:

[Anonymous Coward]

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.

Good to know. Weed out the thin-skinned people, I always say. People who don't actually understand how tricky a problem spam filtering really is, people who can't deal with the internet in general, people who feel the need to get on a soapbox and announce the significantly massive amounts of them not being around anymore everyone else is about to experience (ooo, how impressive and scary!). Sorry, who were you again and why do we care? I missed that part.

Re:

[noh8rz10]

i thought the whole point of slashdot posts is that it was a free-for-all, self-moderated through the mod point / threshold approach. they also limit posting from people with low karma (not filtering by post content, but just quieting the low karma people). also, you can block ACs while not changing your viewing threshold. There are many options!

although personally I don't like the posting limits on low karma people. I think this encourages slashdot group-think, where if you speak up against whatever ideas

Re:

[noh8rz10]

bahahaha I can't believe this was downvoted.

Re:

[Spottywot]

His name is apk & he's been posting it for over 4 years. Here's one from 2009:

http://tech.slashdot.org/comments.pl?sid=1206409&cid=27661983 [slashdot.org]

He keeps adding new stuff on so it keeps growing longer and longer as the years pass.

A bit like a Hosts file then? I hate trolls but I do admire that level of dedication.

Genius

[Synerg1y]

Step one: Make digital card game.
Step two: Print cards and sell them.
Step three: Profit more from WOW.

Re:Genius

[GLowder]

Step four: suddenly realize you posted under wrong article

Re:

[Synerg1y]

So I did :)

totally secure == powered off

[mt1955]

OAuth is ugly to implement, no argument there.

Most of the points made in the article were interesting and seemed valid to me but near the conclusion it felt like the author was reaching bit by ignoring the refresh token concept to make the final point.

The threat of a hacked browser was a bit of an eye opener for me -- never heard that one brought up as a possibility while working on an OAuth implementation for a client.

Re:

[kldavis4]

I agree about the hacked browser. I think one of the main arguments by Eran against OAuth2 is that it is basically broken for mobile applications (non-web) and this is just another of the ways it is broken.

Re:

[DeFender1031]

You miss the point. He says to have the user create separate passwords from the primary one, with restricted permissions, and give a different managed password to each application. That way, if the application misbehaves, the user themselves can remove that password without having to affect anything else.

Re:

[hazah]

Before you call others "idiot" perhaps you should actually understand what they're saying, idiot.

Re:

[hazah]

Nope.

Re:

[DeFender1031]

Again, you miss the point. The point isn't separate accounts. The point is, you have a user account, say "JoeCool", and a password, say "12345". Your system allows Joe, when logged in under that password, to create a secondary password, 67890 which, when logged in with, only allows limited access. Joe can then give "67890" as a password a third-party application, which will then have only limited access. If the application misbehaves, Joe can remove the "67890" password, thus locking out the malicious appli

Re:

[Xeger]

A separate password for each application, is exactly what an OAuth refresh token is. The user is free to revoke the corresponding grant at any time.

Re:

[DeFender1031]

True that's exactly what it is but with a lot of cruft surrounding it as well. It requires a web browser to facilitate the connection, rather than the user just copying a password to wherever it's needed, it requires that the third-party application which wants to authenticate needs its own domain and its own server, instead of just being able to be a standalone application which can authenticate directly. Because of this, it's just a mess of a system. What the author is suggesting is to leave the part of i

Re:

[silas_moeckel]

If you have hacked the browser or machine you have an issue. For the browser there are a slew of API's dependent on OS that let there be separation so that a browser exploit is limited to allowing authentication while that browser remains open but never exposes the base digital certificates. Smart cards take that further by never exposing the private key to anybody.

As to AUPI vs API oauth was never meant to be a end all and be all of authentication. Designing something to let arbitrary systems share data

WTF was that?

[antifoidulus]

The authors biggest complaint about OAuth is that it doesn't do what it was never designed to do....and this is a problem because....? It was never designed for enterprise-level permissions management(there are plenty of other solutions for that). And his solution(copying and pasting tokens) is worse than the disease. It would be easier to go phishing with copied and pasted tokens than it is with OAuth where the login is automatic and tokens/applications can be revoked by the site that manages the account....

I think someone is just bitter and decided to take it out on a protocol.

Re:WTF was that?

[Anonymous Coward]

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.

Re:

[Anonymous Coward]

wrong api works fine. I use it with google apis. once user grants auth, you can call their apis without any user interaction when their not even logged in. it all depends upon the permissions they grant you.

Re:

[Trails]

Actually two-legged OAuth is pretty straightforward and works just fine for me

Re:

[Anonymous Coward]

The authors biggest complaint about OAuth is that it doesn't do what it was never designed to do....and this is a problem because....?

Because people are, with great gusto, actually using it for what it was never designed to do.

Auth belongs in the browser

[jeremylichtman]

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.

Re:

[Lennie]

I don't know if he is a shill, but can you tell me what you don't like about BrowserID, that could be a lot more interresting discussion.

Re:

[jeremylichtman]

I'm not a shill for anyone. Hmm. Maybe for myself. BrowserID uses emails for authentication. Why do we even need to have that? What if you want to change your email address? And why should websites have your email address unless you want them to do so. What I had in mind was that users can create any number of profiles for themselves on their browser, each with flexible set of fields for things like their name, and each field having privacy options. They then can register that profile on a given website;

Re:

[Lennie]

I think this is their reasoning:

1. one of the reasons OpenID failed is because people did not associate website/webpage with identity, BrowserID uses an email address, which is already very directly associated with an identity by many people

2. email addresses are already used on many, many websites, because of password recovery. Even with Facebook Connect/oAuth people will take the email address from the identity provider and record it (yes, it is already provided in most situations !).

3. with current free

Re:

[Lennie]

Anyway, you could also take a look at the recent presentation from Mozilla:

http://pyvideo.org/video/1764/beyond-passwords-secure-authentication-with-mozi-0 [pyvideo.org]

Re:

[jeremylichtman]

Something along these lines. The problem is that there's a proliferation of authentication schemes owned by various companies, and implemented in a scattershot fashion. What is really needed is a standard that can be implemented by many vendors, and that allows users to control their own data.

Re:

[sjames]

So it's a metastandard? Standards compliance really should imply inter-operability. If two implementations of a standard can both be certified as compliant and yet cannot communicate, the standard needs to be tightened or clarified. If that is not desired or if inter-operation isn't a goal, then it may be something, but it is not a standard and should not call itself one.

Blogspot? Really?

[TwistedGreen]

Some guy's rant on Blogspot is news? I guess the "stuff that matters" tagline doesn't apply anymore...

This is a bad article

[ChaseTec]

The author makes no distinction between OAuth 1.0a and OAuth 2.0. One of the spec leads did rage quit, not because of how bad OAuth is in general but because of all the "enterprise" help in version 2.0. Saying there is no standard is also dumb, yes version 2.0 can suffer from incompatible implementations but version 1.0 is pretty straight forward, the standard is right here: http://tools.ietf.org/html/rfc5849 [ietf.org]. The suggestion that we should just stick to HTTP Basic Authentication over SSL/TLS shows that the

Re:

[efalk]

Agreed.

Can anybody explain what's wrong with just using Oauth 1?

Native apps == insecure

[shirikodama]

I brought this up with the oauth working group and got snarled at by lots of people including Eran Hammer. It's nice to see that other people are noticing the same problems. When you have a native app, you can show the user anything to get their confidence, and with some work get their credentials, including apps with webview's. OAuth's security model was not designed with native apps in mind, it was designed for ~trustable web browsers. This isn't surprising because OAuth was designed before the current fa

Re:

[DeFender1031]

Exactly. And the people commenting that "you should never have a hacked browser" don't get that it's referring to native apps which embed a browser to mislead you rather than, say, a spyware-infested version of firefox. Of course you shouldn't have the latter, but for the former, anyone can make an app that imitates anything.

Not complex; not broken; not meant for enterprise

[Xeger]

IMHO, the only legitimate points in this gentleman's post are: (1) a compromised browser defeats OAuth, and (2) OAuth isn't mobile-friendly because it requires browser interaction to gain user consent to grant access.

While both of these are true, Web browsers are ubiquitous; OAuth is a Web standard. You can abuse it slightly to make it work with mobile devices (see "access code grant") but really, it not was intended to be a be-all end-all authorization mechanism.

Likewise, claims that the protocol isn't "en

Re:

[DeFender1031]

If people were only using OAuth for web-to-web communication, I don't think those issues would have been raised. But many of the big players have their "API"s based on it. Take a look at this thread [citrixonline.com] on citrix's development site for example. Here, there's a service which is hardly web-based, pretty much the only thing web-based about it is that you join meetings by browsing to a URL, and yet the only authentication model they provide for their "API" is OAuth. This is wrong. It's not what OAuth was designed f

Re:

[manu0601]

Frankly, anyone who thinks the OAuth draft RFC is complex, should choose a dozen or so documents from the SAML protocol suite, relax in a hot bath, and read through several hundred pages of THAT claptrap.

Indeed the spec is huge, but it works extremely well. I must confess still do not understand why OAuth exists since we have SAML