The OAuth chronicles: I am not stupid
ashfurrow.com
ashfurrow.com
As far as the iOS side of things, the OAuth2Client library by nxtbgthng has worked amazingly well for us: https://github.com/nxtbgthng/OAuth2Client
I'm not sure what the alternative is, though, and OAuth is still a big improvement for the web app client use case.
I also find using WebView activity for launching twitter authentication page is more robust in terms of controlling activity focus.
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.
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.
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.
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.
OAuth is a set of flows for obtaining tokens. These toekns are, by definition, bound to an application-user grant.
The rest is implementation details.
Which flow are you referring to as being succeptible to mitm attack?
Your question about MITM is answered at http://www.subbu.org/blog/2010/09/oauth-2-0-and-cookie-conve....
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.
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.
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?
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.
The most obvious advantage is the app doesn't have to learn the users new password when they change passwords.
But you're right, the whole dance of having the app never `touch` the user's password is bullshit, a pretense cooked up by bureaucracy. You could get all the meaningful functionality of Oauth by letting apps request a single "permission key" when they login - with the user's password. On the other hand, if a site want real, meaningful security, it could give each user a seperate "app password" that they authorized apps with. That would provide real protection - but since it requires one teentsy extra step for the end user, it will never, ever fly.
http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-1....
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.
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.
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...
Only way (even with OAuth2, if I recall right Google documentation) to get "working" flow with natice apps is to give special parameter as callback-url, which will return validation token in html-page. From where you need scrape it. Maybe there will be something better after OAuth2 is finished, but for now: easier to make own authentication server and API to talk with it.
1) Redirect the user 2) Do a POST request to acquire an access token
How is that a pain?
3) When you make an authenticated API call, send the access token along with the request, and make sure you're using HTTPS.
The HTTPS part is important to give a bunch of the security guarantees than OAuth 1 gives you with plain HTTP and some complicated crypto dancing around.
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.
OAuth 2.0 is basically that + a standardized protocol for requesting a "client id", which is why it's completely insecure over standard HTTP.
That means you have to agree on a way of exchanging that client ID.
Which at it's simplest is what OAuth 2 does with bearer tokens. If you have no use for the other parts of the spec then just ignore them, it's all optional and you only need to implement it if you need it.
You must not be developer. OAuth 2.0 is not bloated and pretty much 2 steps with a clause to never use it via HTTP. How could it be more simple?
I have an Instagram iPad app which was a breeze to implement. IG does a great job documenting their API.
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.
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().
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.
> 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.