I think the guts of this is that there isn't really a good alternative to Oauth 2, and it probably does the job, so we might have to live with it.

2 vs 3 legged is basically a matter of what're you using a it for: 2 legged only authenticates an app, 3 legged authenticates the user and app..
I didn't think 3 legged oauth really demanded a full redirect everytime, unless the tokens are expiring far too often. Seems like Feedly might be doing it wrong. They seemed to pull all the data fresh each time, rather than just using OAuth to authenticate a user and grab new data.

Looking at different methods and trying to work out what we'd use for what. Its a little different from a lot of use cases since we're using the API for our own app, not just 3rd party ones.
Oauth 2 has an option called 'resource owner' where you basically send user/pass to the API and get back a bearer token you use from then. This could work for the official js app, since it avoids any weird redirect and the token is basically just session id in another form. The official mobile apps might also use this method.
Other methods might make more sense for other 'external' apps consuming data from an ushahidi install.

Watched through this video today https://blog.apigee.com/detail/oauth_20_don_t_throw_the_baby_out_with_the_bathwater_video_slides .. quite long but I'm starting to have a handle on how OAuth 2 works now. 



On Fri, Apr 12, 2013 at 12:20 PM, Aaron Huslage <huslage@...> wrote:
I'm not a huge fan of three-legged Oauth2. It tends to be unruly to users and makes them think that something is wrong when it is not. 

For instance, Feedly uses this and it drives me batty to have to think that I'm starting over every time I go to the site...even though I'm not. I know where to go to revoke auth within Google's infrastructure I don't need to be beaten over the head every time I login. 


On Thu, Apr 11, 2013 at 8:10 PM, David Kobia <david@...> wrote:
Oauth2 just seems so hard to beat -- not many options out there that are as battle tested. Even reading on of the comments - "... The problem I see with OAuth 2 is not that it exists, but that there doesn’t seem to be anything better."

Also, does anyone have any thoughts on three legged vs two legged Oauth?


On Thu, Apr 11, 2013 at 4:14 PM, Robbie MacKay <robbie@...> wrote:
Hey all,

I've written up another update on Ushahidi 3.0, focusing on current progress building the API : http://gh.robbiemackay.com/2013/04/11/api-wrangling/

I'm reposting my thoughts on API authentication here as I'd love more input on this:

This is probably the next major decision. How do we handle API authentication? do we use OAuth? 1.0 or 2.0? Where do we handle actual user login/registration?… the entire app is going to be built on the API.

At the moment I’m leaning towards OAuth 2.0, primarily because its what Swiftriver uses, and consistency between products is important. However OAuth 2.0 has some issues:

    • the editor for the spec withdrew saying OAuth 2 had failed
    • there are a few ways to mess up an implementation security wise
    • and one implementation isn’t guaranteed to be interoperable with another

That said the many almost-oauth APIs out there probably have more, and similar problems: rolling our own is not an option.

OAuth 2 is probably still going to get a lot of use, and there are good resources appearing on how to do it right, and a couple of good oauth2 clients.

One recommendation that stuck out was “If your API can require HTTPS, use OAuth 2.0 with bearer tokens. Otherwise, use OAuth 1.0a”. I need to dig into the details of this, but given deployers won’t always use SSL this is worth considering.

What do you think? preferences for one authentication method or another?

--
Robbie Mackay

Software Developer, External Projects
Ushahidi Inc
skype: robbie.mackay




--
Aaron Huslage
http://blog.hact.net
IM: AIM - ahuslage; GTalk - huslage@...; Skype - huslage



--
Robbie Mackay

Software Developer, External Projects
Ushahidi Inc
m: +64 27 576 2243
e: robbie@...
skype: robbie.mackay