OAuth 2.0 is a completely new protocol, and this release is not backwards-compatible with OAuth 1.0.
OAuth 1.0 is not browser based. e.g a OAuth 1.0 desktop application or mobile app direct the user to open their browser to the desired service, where user need to authenticate with the service, and copy the token from the service back to the application. This creates a bad user experience. With OAuth 2.0, there are now new ways for an application to get authorization for a user.
OAuth 1.0 requires the cryptographic requirements of the protocol. The complexity of OAuth 1.0 signatures was a major pain point for anyone coming from the simplicity of username/password authentication. The evelopers used to be able to quickly write twitter scripts to do useful things by using just their username and password. With OAuth 1.0 the developers were forced to find, install, and configure libraries in order to make requests to the Twitter API since it requires cryptographic signing of each request. With the introduction of OAuth 2.0 Bearer tokens, it is again possible to quickly make API calls from a cURL command. The access token is used instead of a username and password.
OAuth 2.0 signatures are much less complicated than OAuth 1.0, because there are no special parsing, sorting, or encoding.
ALSO READ: Oauth 2.0 Roles
OAuth 1.0 mandates that the client must generate a signature on every API call to the server resource using the token secret. On the receiving end, the server must regenerate the same signature, and the client will be given access only if both the signatures match. OAuth 2.0 requires neither the client nor the server to generate any signature for securing the messages. Security is enforced via the use of TLS/SSL (HTTPS) for all communication. OAuth 2.0 signatures are not required for the actual API calls once the token has been generated. It has only one security token.
ALSO READ: What is the difference between access and refresh token?
Access tokens of OAuth 2.0 are 'short-lived'. Typically, access tokens of OAuth 1.0 could be stored for a year or more (FYI, Twitter never let them expire). In OAuth 2.0 we have a refresh token from which we can get the expired access token, rather than have the user re-authorize your application.
OAuth 2.0 clearly defines the roles for all parties involved in the communication. There are four roles, (client, authorization server, resource server, and resource owner,) OAuth 1.0 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.0 also does not explicitly separate the roles of resource server and authorization server.
-K Himaanshu Shuklaa..
No comments:
Post a Comment