Also, a few that aren't listed: Rails: https://github.com/pelle/oauth-plugin Django: http://code.larlet.fr/django-oauth-plus/wiki/Home NodeJS: https://github.com/nightworld/node-oauth2-server (me) CakePHP: https://github.com/thomseddon/cakephp-oauth-server (me again)
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.
http://www.codinghorror.com/blog/2012/02/should-all-web-traf...
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.
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.
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