emerging "standard" for delegating access to protected resources without having to share a password.

Everyday new website offer services which tie together functionality from other sites. A photo lab printing your online photos, a social network using your address book to look for friends, and APIs to build your own desktop application version of a popular site. These are all great services - what is not so great about some of the implementations available today is their request for your username and password to the other site. When you agree to share your secret credentials, not only you expose your password to someone else (yes, that same password you also use for online banking), you also give them full access to do as they wish. They can do anything they wanted - even change your password and lock you out... Libraries are already available for many popular platforms such as PHP, Ruby On Rails, Python, DotNet, C, and Perl. We expect most upcoming work to focus on implementations and the development of extensions to the protocol.



lots of the same people as behind OpenID, but no real relation between the 2 standards

2009: Dave Winer did not enjoy getting it working to talk to Twitter.

relating to BasicAuth

Nov'2009: A few weeks ago at IIW, Dick Hardt of Microsoft, Brian Eaton of Google, and Allen Tom of Yahoo! presented WRAP, a competing specification to OAuth... Their effort was based on a simple fact, that OAuth does not adequately support large providers... At the end, due to internal corporate politics and product release schedule, Microsoft and Google decided to ship WRAP implementations and positioned it as a complete solution available as an OAuth replacement. As of now, they intend to focus on enterprise products, an area OAuth is not widely deployed in... OAuth WRAP is just one illustration of the demise of the OAuth community.

Jul'2012: Eran Hammer has dropped out of the v2.0 process saying it's been hijacked by Enterprise players. One of the compromises was to rename it from a protocol to a framework, and another to add a disclaimer that warns that the specification is unlike to produce interoperable (InterOp) implementations... As the work dragged on (and on) past its first year, those web folks left along with every member of the original 1.0 community... In the real world, FaceBook is still running on draft 12 from a year and a half ago, with absolutely no reason to update their implementation... If you are currently using 1.0 successfully, ignore 2.0. It offers no real value over 1.0... If you are new to this space, and consider yourself a security expert, use 2.0 after careful examination of its features. If you are not an expert, either use 1.0 or copy the 2.0 implementation of a provider you trust to get it right (Facebook’s API documents are a good place to start)... I’m hoping someone will take 2.0 and produce a 10 page profile that’s useful for the vast majority of web providers, ignoring the enterprise. A 2.1 that’s really 1.5. But that’s not going to happen at the IETF. That community is all about enterprise use cases and if you look at their other efforts like OpenID Connect (which too was a super simple proposal turned into almost a dozen complex specifications), they are not capable of simple.

Jan'2013: Tim Bray gives his perspective. is it really a “Standard” in any useful sense? And should we invest in implementing it? Yes to both. OAuth2 is, for lack of a better word, a framework that you can use to build actual real protocols. And also mentions Open Id Connect (OIDC): It’s trying really hard to be a real actual Internet Protocol; plug a client into a server and feel entitled to anger if it doesn’t Just Work. I’m super-interested in OIDC and starting to become a fan... it’s built on OAuth2.

  • Feb'2013: DaleOlds on trying to harmonize OAuth-2, OIDC, and SCIM for a single service: OAuth2 for delegated authorization, OpenID Connect for session and authentication information, SCIM for user and group management.

Edited: |

blog comments powered by Disqus