OAuth is an open, industry-standard protocol for web authorization. Using tokens for authentication and authorization, OAuth gives end-users the ability to share their information with third parties without having to expose their credentials, such as passwords and other sensitive information.
OAuth 1.0 vs. Oauth 2.0¶
Even though they share the same goal and provide very similar user experiences, OAuth 2.0 is a complete rewrite of OAuth 1.0 which is why they are considered separate protocols. Additionally, OAuth 2.0 is not retrocompatible with OAuth 1.0.
Terminology and Roles¶
Some of the many differences between OAuth 1.0 and OAuth 2.0 radicate on terminology and roles. While in OAuth 1.0 the owner of the data to be shared is called "user", in OAuth 2.0 his or her name is now "resource owner". In terms of differences in roles, OAuth 2.0 now separates the "authentication server" from the "resource server" in contrast to OAuth 1.0 which treated them as the same entity.
Authentication and Signatures¶
One of the problems of OAuth 1.0 that hinders the speed of client-side development is its cryptographic complexity. By using OAuth 1.0, developers had no choice but to add and configure external cryptography libraries and signature generators just to send simple GET requests. With OAuth 2.0's addition of bearer tokens, all developers have to do is add an "Authorization" header with the bearer token as its value and the protocol will take care of the rest.
User Experience and Alternative Token Issuance Options¶
OAuth 1.0 used to have multiple "flows" or methods of obtaining access tokens, but then it merged all three of its flows (web app, desktop, and mobile or limited) into a single one, which proved to be effective for web apps yet cumbersome for other devices. OAuth 2.0 separates these flows once again as it was observed that separating them offers better user experiences. OAuth 2.0 names these separated flows "grant types".
Scaling and Performance¶
OAuth 1.0 requires client credentials to authenticate before serving API calls. This makes it very hard to separate API calls from calls requesting authorization, which clashes with the way large, industry-standard, app architectures are designed. OAuth 2.0 seprates API calls from client credential validation by introducing the bearer token which replaces client credentials and which API endpoints can easily validate without needing access to the originating client credentials.
OAuth 1.0 requires two strings for authentication: a public one and a private one. The private one is used only client-side and is never sent over the web. OAuth 2.0 reduces the complexity of authentication by providing only one string which is sent over the Internet in the HTTP request headers. This string is meaningless for clients but is significantly important for the API that requests it as authorization. It also facilitates the "authentication server"'s ability to revoke access.
Most situations in software development involve tradeoffs and using tokens for authorization is not the exception. Nonetheless, the use of tokens results in easing user experience, in speeding up development, and in making client-server architectures much more flexible.
The following subsection talks about how OAuth 2.0 now allows the creation of short-lived tokens to mitigate the cons mentioned before.
Wiht OAuth 1.0, developers were coaxed into creating long-lived tokens (usually a year or so of validity) due to the difficulty of generating tokens and the need to have them valid long enough for continuous testing. However, this approach makes it difficult to handle such tokens as access is desired but too much open access is not. OAuth 2.0 solves this issue by allowing the creation of short-lived tokens accompanied by a long-lived refresh token that can be used to renew access when necessary.
Roles in Oauth 2.0¶
As mentioned before, OAuth 2.0 separates the role of authorization servers from API servers. This separation of roles makes the coupling between authentication and serving API requests much more losse in such a way that authorization servers and API servers can be scaled independently, since they won't have to share a common data storage. In addition, development or replacement of one will not affect the other in any way.
OAuth 2.0 Official Website
For more information on OAuth 2.0 and how it relates to OAuth 1.0, please visit the OAuth 2.0 official website