There's no shortage of simple OAuth consumer libraries out there, what I really want to see is a simple way to set up my app as an OAuth _provider_. As far as I know there's nothing out there to make that simple yet.
Or even if there was a simple, detailed guide on what your own OAuth needs to do to be secure - and a basic overview of how to implement it (not language specific, just concept-wise).
Well if you implement OAuth 2 properly, you'll prevent session fixation and hijacking attacks, and with https you will also prevent man-in-the-middle attacks.
The hueniverse guy was one of the people drafting the standard and as far as I can tell he laments that the providers can return a "bearer token" instead of a "mac token". That means the token is sent on every request to the provider, and without https it can be intercepted. But with https everything is fine!
OAuth 1.0 didn't rely on https to prevent MITM attacks an instead used the "mac token" to sign each request to the provider, along with an increasing timestamp/nonce to prevent replay attacks.
I don't know what language you use, but we wrote an open-source Ruby app called Vanilla [1] that acts as a generic OAuth provider. Maybe it can be useful to you, either directly or as an example.
Vanilla is a Sinatra app, exposes a simple API and user database, and the UI is rendered entirely through webhooks. In other words, it's designed to be a headless system that works in concert with a real app, so that the app itself does not need to implement OAuth or indeed the core account handling.
(Some parts, like the ability to sign up by verifying your phone through an SMS code, are very specific to our workflow, but it's intended to be completely generic, so those things can be changed.)
That said, OAuth 2.0 is very simple to implement. It's pretty much entirely encapsulated in oauth.rb, token.rb and authorization.rb, if you want some inspiration.
Sure there is. http://framework.qbix.com does it out for you out of the box. But then again, we haven't launched it yet, so I apologize... but reach out to me if you want early access.
However I should say that our framework takes a different philosophy. We believe that web apps shouldn't have to ask for OAuth access at all just to personalize the experience for you. They can ask the provider to display to you your name and everything else, in iframes that they can't get visibility into. Although I dislike patents, the whole system was non obvious enough to file one for the investors: http://www.faqs.org/patents/app/20120110469#b
We use oauth mainly for single sign-on, and the access permissions are actually a special case of an app requesting access to various streams you publish. In our framework, the app simply has a user id just like any other user, and can request access to your stream just like any other user. You can put users into friends, family, admins or any other roles, and then give them permissions on various streams.
that is actually totally not true. not if you want to use it in javascript apps that is, ie. a chrome extension.
currently the only good way to use google's v3 api's, which are oauth 2.0, is to use their new experimental identity library. you can however not deploy that in the play store afair. that said, i'd be surprised if this thing just worked in chrome extensions. but if it does it's useful i guess
