DISQUS

David Recordon · 10 months ago

Makes sense and I think that these lessons and ideas are true for a lot of technologies. If the OAuth community were to attack this list, what order do you think makes sense? Is a validator the most important thing to build first?

Joseph Smarr · 10 months ago

Actually I think the first step should be a good recipe guide and a companion "transparent provider" that the recipe uses. It would take the user through getting/writing a library, hitting a basic "hello world" up to a more complex API call, and it would provide lots of detail and feedback at each step. The idea is, we could tell developers to "first get your code working against this extra-friendly OAuth API, and then turn it to twitter or whoever else you want o hit, since then you'll be confident that it at least works in theory already." And yes, I agree that these types of developer aids are necessary for all the Open Stack building blocks!

David Recordon · 10 months ago

A bit like your OpenID recipe that you wrote a few years ago. We're planning to write this sort of guide for our book, but haven't started on the OAuth content yet.

Ryan Kennedy · 10 months ago

Joseph, I totally agree. As someone who works on OAuth code every day (mostly working on SDKs to access Yahoo!'s OAuth protected social resources), OAuth seems pretty simple to me. However, as we've all seen, users don't have the same experience. Consumers are buggy, providers are buggy and OAuth itself is just plain complicated to understand for someone who just wants to execute a bit of YQL that performs an image search.

Feel free to get in touch with me, I'd love to help in any way I can. I'm particularly interested in the transparent OAuth provider and OAuth validator. Given my role at Yahoo!, I might even be able to convince the powers that be that it's a good idea for me to spend some of my work time on such an effort.

Joseph Smarr · 10 months ago

Ryan-sounds great, and I'll definitely take you up on that offer! ;) It's clear to me that a little extra time and effort by people like you and me whose jobs and companies depend on OAuth being easy to make it so will be a wise investment indeed.

dave · 10 months ago

Why don't we have a dinner in March to discuss?

Karl Adam · 10 months ago

I don't know, personally I never found OAuth hard so much as just new. The problems that people are facing aren't so much with the hows, as Winer had the hashing and such correct, but didn't understand that concepts as to why certain things were being done. I grokked OAuth after looking at the Yahoo! OAuth guide which displayed a graphic of the handshake process and was clear to me how to move from unauthorized to authorized and authenticated.

lmorchard · 10 months ago

A “transparent OAuth Provider” is exactly what I was looking for when I started trying to help Dave, too. I've not yet had the chance until now to dive very deep into OAuth myself, and it's very easy to get one thing inexplicably wrong (eg. not url-encoding all the right parts) and have no clue what you got wrong because the signatures are necessarily so opaque.

Would be nice if the "training wheels" of a transparent provider could take all the client-side key/secret and duplicate the expected work for the client side as a cross-check.

Luca · 10 months ago

I think that all these ideas make perfectly sense, it would be ideal if recipes were collected for all of the OAuth libraries (i mean: having a version of the recipe for each library out there...).

In the meantime, today I have started to work on a prototype "transparent oauth provider", I should have something usable by tomorrow evening (day-job permitting :-) )

Daniel Rubio · 10 months ago

I followed your comment on Dave Winer post.
Just thought I would mention it. The Google OAuth playground is the one thing that finally got me to understand the process, since its interactive showing the requests, headers, tokens and responses.
Its located here : http://www.googlecodesamples.com/oauth_playground/

dready · 10 months ago

Thanks for presenting this action list. I agree that these will tremendously improve the developer accessibility for OAuth.

Regarding terminology confusion, that's very true with the sheer number of tokens coupled with possibly name collision with app-specific parameters (which could be called "api_key", or "secret"). It makes it so easy to get a typo or function parameters swapped. On FireEagle, two different access tokens (user-specific and general access) are used, which may make things worse.

I haven't dabbled in OAuth much, but my first experience was implementing the Fire Eagle widget on MojiPage. We use the Python OAuth library, and provide useful abstraction for the widget (also written in Python) so that it needs only call a few functions. Debugging was a tad harder than the usual web app, but it was a smooth ride on the whole.