
The OAuth chronicles: I am not stupid - moeedm
http://ashfurrow.com/2011/12/oauth_sucks/
======
kainosnoema
He's right. OAuth does suck. Thankfully OAuth2 sucks less... a lot less. We're
working on an API now, and only plan to support OAuth2.

As far as the iOS side of things, the OAuth2Client library by nxtbgthng has
worked amazingly well for us: <https://github.com/nxtbgthng/OAuth2Client>

~~~
AshFurrow
I hadn't seen that. It looks really promising - thanks!

------
alex_c
I haven't worked much with OAuth on the iPhone, but what I hate is that, when
it's embedded in apps, it makes phishing attempts pretty much undetectable for
end users. I see a Facebook login form pop up in a UIWebView in an app - is it
really Facebook, or is it some other site? I have no way of knowing.

~~~
bct
There was a big thread on the OAuth mailing list about this a couple of months
ago. The official response seems to be "don't use native applications that you
think might phish you", which isn't very satisfying.

I'm not sure what the alternative is, though, and OAuth is still a big
improvement for the web app client use case.

------
Pewpewarrows
As an Android developer who's been struggling to get OAuth 1.x working for the
past few weeks in his spare time, I wish I could say it's any better on this
side of the pond. We have some marginal improvements since we can register our
own app to be the receiver of the OAuth callback (using Intents). But it's
still excessively complicated.

~~~
adelevie
Last summer I had some issues getting OAuth working with the Twitter API for
Android apps. I ended up using the signpost library. I posted my results with
instructions here: <https://github.com/adelevie/AndroidOAuth>. Maybe it will
help you.

~~~
MrVitaliy
Similarly here
[https://github.com/vitalius/Twiturr/blob/master/src/com/twit...](https://github.com/vitalius/Twiturr/blob/master/src/com/twiturr/AuthActivity.java)

I also find using WebView activity for launching twitter authentication page
is more robust in terms of controlling activity focus.

------
Spearchucker
OAuth (even two) sucks - and not just at the implementation level. OAuth will
continue to suck until it adheres to the laws of identity.

Unfortunately the alternatives look pretty bleak too. If you want to use
identity federation, you're stuck with WS-* (you need the active requestor
profile for thick clients), and, more fundamentally, you need an identity
provider (IDP). Note that Facebook, Google and Twitter don't count - they're
not justifiable parties except unto themselves.

Once you get the IDP sorted you have more options. You can use U-Prove or
IDEMIX to provide anonymity, derived claims (proving you're over 18 without
divulging your age) and discretionary access to claims.

Problem with all of the above is that identity selectors aren't as mature as
they could be (CardSpace has been abandoned by Microsoft, and the Higgins
Project doesn't have an adequate solution for putting information cards onto,
say, a smart phone).

Given the sorry state of identity today, I've created my own framework which
required close to 10K LOC (client and server).

It's an insane world. We still haven't managed to come up with anything better
or more usable than user name and password.

~~~
carsongross
Absolutely.

You can just look at all the various revs and options that OAuth has and know
that they are casting around for a correct answer.

I've implemented two oauth 1.x handshakes and both were full of one-off
complications and incomprehensible error states.

I'll take a look at OAuth 2 when it becomes more prevalent, but until then no
why in hell I'm moving away from a simple "generate an API key" approach.

------
chrisrhoden
Everyone chiming in here is just blatantly, blatantly wrong. OAuth is a solid
solution to a very real set of problems.

The fact that you are unaware of the potential problems does not make those
problems any less valid.

As someone who has implemented an OAuth flow on Android and iOS, I can agree
that it's not easy. But it _does_ solve a serious set of security issues which
are raised by having a third party act on behalf of a user. Not only does it
permit more fine grained grants to applications that the user trusts to
varying levels, it allows a compromised application to have all of its keys
invalidated at once. It allows a user to disable a single misbehaving
application's access to their account. These are prices worth paying.

Learn what you're whining about. Then deal with it.

~~~
Spearchucker
Not quite sure which (or who's) whining you're having a go at, but as an
identity system OAuth is indeed a pile of poo.

First, OAuth1's poorly-spec'd signatures make implementation difficult. That's
an accepted and pretty well-documented fact.

OAuth2 removes all crypto and instead relies on bearer tokens and SSL/TLS,
while not mandating it. It does away with signatures in favour of ease of
implementation. [edit] This is a bad thing.

OAuth2 is also susceptible to man-in-the-middle attacks where a malicious
party could gain access if it intercepts a token.

That's a pretty poor implementation.

As an identity provider OAuth 1 and 2 have problems beyond the technical
interpretation of the specs, or implementation difficulties. Both fail as an
identity system (ref.
<http://www.identityblog.com/stories/2004/12/09/thelaws.html>).

I'd love to hear why you think OAuth is a solid solution.

~~~
chrisrhoden
I would also love to hear why you think that identity has anything to do with
OAuth or this discussion.

~~~
Spearchucker
OAuth is an authentication mechanism, meaning it implements a principle of
logic stating that a subject is who he/she claims to be (authN), and then
asserts that to a relying party (authR). In other words, OAuth establishes
identity.

Your question about MITM is answered at
[http://www.subbu.org/blog/2010/09/oauth-2-0-and-cookie-
conve...](http://www.subbu.org/blog/2010/09/oauth-2-0-and-cookie-convergence).

~~~
chrisrhoden
OAuth is a mechanism by which an application can be granted authorization by a
user to another application.

The identity question is not in any way addressed by OAuth. It is up to the
application implementation to handle identifying the user creating the grant.

The link you provided basically establishes the same problem which is always
the case - if someone is watching your (unencrypted) traffic, you're hosed.

~~~
Spearchucker
That authorisation is an assertion of identity. This makes OAuth an identity
system inasmuch as WS-Federation and the SAML protocol are identity systems.
Technically they're parts of an identity system, making them identity meta-
systems.

~~~
chrisrhoden
Maybe, but that has nothing to do with OAuth. One could be completely within
the OAuth spec and allow one user to provide grants to act as dozens of other
users. You are basically saying that OAuth is not good at something it was
never designed to have any say about.

It's as though you're saying that your rolling pin doesn't work well as a meat
tenderizer. Yeah, I guess they're related, but that's not what a rolling pin
does.

~~~
Spearchucker
Of course you're right. I'm an idiot. Thanks for setting me straight.

------
100k
OAuth 1 is hard. OAuth 2 is much easier.

But OAuth 2 still sucks on native apps. The spec strongly discourages storing
keys in the application binary, but every single mobile app example I see does
this. My question: is anyone doing this _right_? How?

~~~
ssutch
Storing app keys? You have to store some sort of key in the binary.

------
robertszkutak
This is all it took for me to implement Tumblr's API with OAUTH on Android 1.6
and up:
[https://github.com/RobertSzkutak/AndroidExamples/blob/master...](https://github.com/RobertSzkutak/AndroidExamples/blob/master/TumblrExample/src/com/robertszkutak/androidexamples/tumblrexample/TumblrExampleActivity.java)
. I've personally never had a problem working with OAUTH (1.0 or 2.0) on
Android. Does iOS development really complicate writing clients for web
services that much more?

~~~
chrisrhoden
This is such a ridiculous post from someone who got frustrated because they
didn't understand OAuth. Nothing more. They will get it soon, and they will
feel bad for attempting to write something that makes OAuth look bad. Give it
time.

------
dennish00a
I just need to add my voice to the chorus: OAuth really, really sucks.

I don't understand what problem it solves. A malicious app (native or web) can
find a way to get your password, period. A well-behaved app can have your
password and do no harm. And, practically speaking, I don't know any real
person who's had a problem that has been solved by the existence of OAuth.

OAuth is just a massive pain in the rear end.

~~~
bct
> A well-behaved app can have your password and do no harm.

Until someone steals its database.

You hash your user's passwords, right? Same thing - whether you're talking
about your app's passwords, or some 3rd party app's passwords, keeping them
around in plain text is a _bad idea_.

~~~
chrisrhoden
And hashing them is _not useful_ if you intend to authenticate with them. I
think you mean encrypt. Hacker finds encryption key. See "Until someone steals
its database."

~~~
bct
No, that's not what I meant. It's an analogy - if sites shouldn't store their
own passwords in plaintext or reversibly encrypted (which everyone here agrees
on - "use BCrypt", etc), then they shouldn't store other passwords in
plaintext or reversibly encrypted. They should use something like OAuth
instead.

------
jcizzle
Not familiar with OAuth, but the concern about NSURLConnection seems a bit
silly. Create an NSObject subclass, give it a NSURLConnection and a block
ivar. Set it as the delegate of its own NSURLConnection. Setting up a "store"
object that handles the preparation of NSURLConnection instances is also
useful. Have the store keep track of all working NSURLConnections (which gives
you the ability to cancel easily, too).

If you are using NSURLConnection out of the box and writing the delegate
methods over and over again in every view controller or store object, you are
doing something wrong.

------
geoffhill
This article doesn't say anything about whether OAuth, the authentication
protocol, sucks or not. It's referring to current OAuth libraries for iOS.

~~~
kainosnoema
There's a reason the client libraries are lacking though.

In my experience with both OAuth 1.0 and 2.0 libraries for iOS, Node.js, and
Ruby (among others), OAuth 1.0 is just a lot harder to implement. It's not fun
in any way...

------
ghurlman
This article reads more like "XAuth sucks". I've done more Windows Phone dev
than iOS dev - and apparently I've taken the "native code listening for a
Javascript event" functionality for granted. OAuth via a web view is dead
simple.

~~~
chrisrhoden
You can do this in iOS and Android as well.

------
dpres
Correction, OAuth < 2.0 sucks. OAuth2.0 is actually easy to use and more
secure.

~~~
tomjen3
There is no reason to use OAuth ever, in any shape, under any circumstance,
which is a bad for the tech but (in this case) good for everybody else.

Instead of using the bloated OAuth multiple requests back and forth,
permission keys, auth keys, consumer secrects, etc, etc. you can simply add an
additional header saying "client id" which the service provider can then use
to "secure" his er her service as he sees fit.

OAuth is a bloated attempt to paper around the simple solution so that the
astronaut architects who made it can feel smug about themselves.

OAuth solves no problems, helps nobody and has (drastically) polluted our
ecosystem. To hell with that shit.

~~~
ryanpetrich
> you can simply add an additional header saying "client id" which the service
> provider can then use to "secure" his er her service as he sees fit.

OAuth 2.0 is basically that + a standardized protocol for requesting a "client
id", which is why it's completely insecure over standard HTTP.

~~~
dpres
Thats why OAuth2.0 protocol is limited to HTTPS and is said to never be
implemented over HTTP.

------
TheFuture
Agree. Had a hell of a time getting OAuth to work on my iPhone Netflix app.
Just hours and hours wasted.

I have an Instagram iPad app which was a breeze to implement. IG does a great
job documenting their API.

------
PaulHoule
Asynchronous comm doesn't need to lead to spaghetti code, but it certainly
will if you don't know how to organize it.

~~~
AshFurrow
More like spaghetti code, then. dispatch_async() with NSURLConnection's
synchronous method is way cleaner and faster to build an app with than
NSURLConnectDelegate callbacks and holding onto the reference of multiple
NSURLConnection instances.

It's possible to organize your code using asynch methods, but considering
Apple's move toward block-based APIs, that's what I choose to use when
architecting the apps I write.

~~~
nupark2
Apple's block-based APIs aren't intended to replace asynchronous APIs. In
fact, Apple's block-based APIs _ARE_ asynchronous APIs. Half of the intent of
GCD is to provide a dynamic-thread-queue _asynchronous_ interface to non-
blocking I/O APIs via kqueue and friends.

GCD aside, there are a ton of reasons not to use synchronous networking, from
the resource costs (you're paying for a thread stack per request) to the
inability to cancel the synchronous request.

One of Apple's engineers (Quinn) wrote up a whole post on the dev forums about
why you should _not_ use synchronous networking. It's a "sticky" post at the
top of the iOS->Core OS forum:

<https://devforums.apple.com/thread/9606?tstart=0>

Lastly, I think your position on spaghetti code is misguided. A block-based
wrapper on NSURLConnection will be just as simple as dispatch_async().

------
peterbraden
The big problem with oauth is how inconsistent everybodies implementations
are. There isn't a good library because there are so many edge cases where
API's implement it differently.

It's a developer hostile mechanism, but unfortunately it's the best option out
there for granting subset access to an API with easy token revocation.

~~~
andrewmccall
The reason is OAuth1 is painful, the double encoded and signature requirements
are strict and so easy to get wrong that everyone has jumped on OAuth2.
Unfortunately they've all jumped on different versions of the spec which keeps
changing , because it's still a draft.

------
eridius
Started skimming the article and my eye fell upon this:

> If you want any meaningful error messages, you need to opt for the
> asynchronous URL connection methods. Why does that suck? Because it takes a
> really easily architected, synchronously-called API layer that is run in a
> background queue with Grand Central Dispatch and turns it into a bloated,
> complicated asynchronous pile of spaghetti code.

Sorry, dude, but you definitely are stupid. You're seriously advocating tying
up an entire OS thread purely to do synchronous network IO. That's incredibly
stupid. It's pretty trivial to throw asynchronous network IO onto a worker
thread. You're still using a thread, but now you can multiplex _all_ of your
IO on to one thread instead of using one thread per network call.

------
ssutch
FB and IG are OAuth 2.0.

