Slashdot Mirror

Still a good critic from a contributor of OAuth 1.0
http://hueniverse.com/2012/07/...

And the problem is that "making" a correct implementation is where all the hard work is and there is no guidelines.

OAuth is an overly complex framework built upon unsecure fundations (the web).

Security is expensive. The real identity check should be in the real world, and there should be human checking and validating.

Security should not be made 100% in the same plan as communication and THAT is the weakness of all security making MITM so easy.

You can even have trusted CA x509 top of the security without REAL checks.

Computer security is a SCAM.

And now computers can break passwords that human can remember, the secrets are not possibly in the only safe place possible which is a brain.

Over exposure of personnal data (birth, relationship) makes that you hardly have any secrets any way.

The future is to build an internet without security. It will mean the end of e-commerce, ads powered contents ...

You will have your library/swimming pools openings, news that can sustain without ads, university papers, public domain data; administrative forms to print and addresses of administrations, quake servers, BBS, technical sheets.

The serious people in business could drop security and just have human pick a phone number, validate that customers are who they pretend to be and have all the "business data" being given on another plane (coursier, phone, banks) according to the cost/benefits and if they store credentials, they can use totally isolated networks internal to their buildings and use coursier/post to send hard drives with physical seals on them.

I crave for the future boring web that is useful again with 1Kb web pages.

As mentioned in the summary this has been discussed a few times on Slashdot, and the original discussion was kicked off by Paul Graham's assertion that the cool hacker kids were into Python and the only people using Java were boring corporate types who had no passion for their jobs and were often mediocre programmers. In this sense, "coolness" does matter a little bit - if you're starting a new project, you don't want to choose a language where the labor pool that you're recruiting from is full of crappy programmers.

And yes, I know good programmers can pick up new languages quickly. But it can take months or sometimes years to master all the libraries and frameworks around the language. Someone with relevant experience can hit the ground running and have a shorter ramp-up period than someone without. I'm not saying that this is more important than general coding ability - it's not - but this is valuable to a lot of smaller companies and startups who don't have lots of time to train up new hires.

What makes Java uncool isn't so much the language itself, but rather the community around it. I actually like Java as a language better than Python, but there's a real culture of overengineering in the Java community, and people there really value convoluted architectures that are (ostensibly) maintainable and extensible. In the Python community, people value simplicity and hackability, and you can see it when you do things like file I/O or compare popular frameworks from both languages.

Not directly related to Java, but a while ago the tech lead for OAuth 2.0 resigned citing cultural differences between the "web" and "enterprise" communities. The "cool" languages are definitely the ones that are favoured by the web community, and the uncool ones favoured by the enterprise community.

So as much as people might think that it's just language syntax, it's not - it's also about communities, culture and different ways of thinking.

good related read

OAuth2 like would be interdasting.

Would it? Well, OAuth's lead designer politely disagrees

The article is mostly FUD.

Not really. I believe the author's biggest beef is that the user should not be providing the app with their credentials to Tesla Motors.

This is true, and with OAuth they don't have to. All the third-party app get's is an access token. The access token can have completely different rights than the user account, and can be revoked /controlled by the user.

You can use OAuth for mobile/desktop access, it's just not as seamless as it is on the web. Here's a post that has some other perfectly reasonable suggestions for how to use it in these situations:
http://hueniverse.com/2009/02/beyond-the-oauth-web-redirection-flow/

Having implemented OAuth1.0 and 2.0 services for communicating with various platforms, I was amazed at the lack of any security in Oauth 2.0. As mentioned by others, it completely relies on SSL/TLS

Hammer has been saying similar things for years now: OAuth 2.0 (without Signatures) is Bad for the Web

I don't know much about oauth, but this sounds like a stupid move.

No, it's how it should have been to begin with. Bearer tokens are now pure capabilities supporting arbitrary delegation patterns. This is exactly what you want for a standard authorization protocol.

Tying crypto to the authorization protocol is entirely redundant. For one thing, it immediately eliminates web browsers from being first-class participants in OAuth transactions. The bearer tokens + TLS makes browsers first-class, and is a pattern already used on the web quite a bit, albeit not as granularly as it should be.

His criticisms against bearer tokens are based on the ideals of authenticating identity, but bearer tokens in OAuth are about authorization. These are very different problems, and authentication actually impedes the delegation patterns that people want to use OAuth for.

Giving someone a bearer token authorizes them to use a resource on your behalf. That third-party shouldn't also have to authenticate with the resource as well. It could be a person or service that's entirely unknown, so authentication requirements actually prevent work from getting done. This just leads to awkward workarounds, which OAuth was supposed to prevent!

That would be this instead...

http://hueniverse.com/webfinger/

I swear, I read that and the brass section in the back of my head immediately started up:

WebFINGER!! (Dah DAAAH daah!)
He's the man, the man with the browser touch...

It actually reminds me the most of the old unix "plan" file which popped up when users were "fingered".

That would be this instead...

http://hueniverse.com/webfinger/

Now you know web 2.0 really has come full circle :)

One simple but painfully restrictive solution is to duplicate the data for each user. Basically what this means is turning the service into an email system. Each user is given a mailbox and whenever someone they are following publishes a status, it is copied into their inbox, as well as into all the other followers' inboxes. This brings the solution in line with existing systems such as webmail services where data partitioning alone can accomplish great scaling. But this comes at a price. First the data storage grows significantly faster and requires much more disk space, together with increased backup cost. Second, it makes other actions much more complex such as erasing a message once sent.