This page covers high level time line of identity delegation evolution in chronological order.
Direct Password sharing (2005 and Earlier)
Twitter, SlideShare, and other web applications used credential sharing to access third-party APIs. It was definitely insecure as the applications could have used their credentials in to get personal data which user may not have intended to share.
Google clientLogin & Authstub - 2006
Google introduced 2 protocols to handle delegation.
Google ClientLogin was intended to be used by “installed applications.” Example of installed applications included desktop or mobile installed applications. Google ClientLogin used identity delegation with password sharing.
Google AuthSub was the recommended authentication protocol to access Google APIs via web applications in the post-2006 era. One of the improvement this protocol has was the fact that Users don’t need to provide credentials for a third-party web application—instead, the application provides credentials directly to Google, along with a temporary token with a limited set of privileges.
The AuthSub API was deprecated in 2012.
Yahoo! Browser-Based Authentication (BBAuth) - 2006
Yahoo! BBAuth was launched in September 2006 as a generic way of granting third-party applications access to Yahoo! data with a limited set of privileges. Yahoo! photos and Yahoo Mail were the first two services to support BBAuth.
oAuth 1.0 / oAuth Wrap - 2010
oAuth1.0 was developed in 2007. OAuth 1.0 was the first step toward identity delegation standardization. The access-delegation model proposed in OAuth 1.0 was very similar to what Google, Yahoo, and Flickr already had.
OAuth 1.0 faced criticism due to its usability and extensibility. For example, it imposed strong cryptographic requirements on clients, it did not support revocation all that well, and its model had important architectural limitations that made it unsuitable for being used outside the web-app-to-web-app-server communications case. Those limitations made it hard for OAuth to be applied in many business scenarios.
For that reason, a group of companies (Google, Yahoo, Microsoft) got together and created an alternative OAuth profile, called OAuth WRAP (Web Resource Authorization Profile), which was aimed at eliminating those shortcomings.
The OAuth working group considered the new profile and decided to build the new version of OAuth (OAuth 2) on top of it. OAuth2 is not compatible with either OAuth 1 or OAuth WRAP, although it contains elements of both.
oAuth2 - 2012
OAuth 2.0 was developed as an authorization framework, rather than a standard protocol
- Allows better support for non-browser based clients
- No longer requires client applications to have cryptography
- oAuth 2.0 tokens are short lived
|1||Advanced API security|