OAuth 2.0 is a complete rewrite of OAuth 1.0 from the ground up, sharing only overall goals and general user experience. OAuth 2.0 is not backwards compatible with OAuth 1.0 or 1.1, and should be thought of as a completely new protocol.
OAuth 1.0 was largely based on two existing proprietary protocols: Flickr’s authorization API and Google’s AuthSub. The work that became OAuth 1.0 was the best solution based on actual implementation experience at the time. Over a few years of many companies building OAuth 1 APIs, and many developers writing code to consume the APIs, the community learned where the protocol was proving challenging to people. Several specific areas were identified as needing improvement because they were either limiting the abilities of the APIs, or were too challenging to implement.
OAuth 2.0 represents years of discussions between a wide range of companies and individuals including Yahoo!, Facebook, Salesforce, Microsoft, Twitter, Deutsche Telekom, Intuit, Mozilla and Google.
This section covers the major differences between OAuth 1.0 and 2.0, and the motivations behind them. If you are familiar with OAuth 1.0, this is a good starting point to quickly understand the major changes in OAuth 2.0.
Terminology and Roles
Where OAuth 2.0 defines four roles, (client, authorization server, resource server, and resource owner,) OAuth 1 uses a different set of terms for these roles. The OAuth 2.0 “client” is known as the “consumer,” the “resource owner” is known simply as the “user,” and the “resource server” is known as the “service provider”. OAuth 1 also does not explicitly separate the roles of resource server and authorization server.
The terms “two-legged” and “three-legged” have been replaced by the idea of grant types, such as the Client Credentials grant type and the Authorization Code grant type.
- Authentication and Signatures
- User Experience and Alternative Token Issuance Options
- Performance at Scale
- Bearer Tokens
- Short-lived tokens with Long-lived authorizations
- Separation of Roles