This looks incredibly useful! However, its existence raises an important question. Doesn't the necessity of this product inherently suggest underlying flaws in

This looks incredibly useful! However, its existence raises an important question. Doesn't the necessity of this product inherently suggest underlying flaws in the 0Auth 2.0 framework (not protocol)? In my mind (and Eran Hammer apparently agrees), one major shortcoming of OAuth 2.0 is that the specification all but ensures that a universal, drop-in library for an arbitrary implementation of OAuth 2.0 cannot exist. We saw this problem with OpenID - we even had a service designed around 'solving' the problem of integrating multiple OpenID providers. If the framework itself is so complicated that it needs extra abstraction layers to simplify it for basic, general use, to me, that suggests design flaws. EDIT: On re-reading Hammer's post[1], I've realized that it's even worse than I'd thought: the OAuth 2.0, Draft 30 specification even admits plainly that it is 'likely to produce a wide range of non-interoperable implementations.' If that is considered an acceptable candidate for the goal of OAuth 2.0, then I would question the goal itself. [1] http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/ http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell... [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-1.8 http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-1....