What is OAuth2.0?

OAuth2.0 is the next version of the OAuth protocol, but does not backwards-compatible with OAuth 1.0, which completely abolishes the OAuth1.0. OAuth 2.0 focuses on the simplicity of the client developer. Either represent the user through an approved interaction between the resource owner and the HTTP service provider, or allow third-party apps to gain access on behalf of the user. It also provides a dedicated certification process for Web applications, desktop applications, mobile phones, and living room devices. In October 2012, the OAuth 2.0 protocol was formally released as RFC 6749.

Facebook's new graph API only supports OAuth 2.0,google, which also announced the Google API's support for OAuth 2.0 in March 2011. Authentication Authorization Process

The three parties involved in the authentication and authorization process include: The service provider, the user uses the service provider to store protected resources such as photos, videos, and contact lists. User, the owner of the protected resource that is stored in the service provider. A client, a third-party app that wants to access service provider resources, is usually a website, such as a Web site that provides photo printing services. Before the authentication process, the client will request a client identity from the service provider.

The process of authenticating and authorizing with OAuth is as follows:

The user wants to manipulate the resources stored in the service provider. The User logon client requests a temporary token from the service provider.

After the service provider verifies the identity of the client, it grants a temporary token.

After the client obtains the temporary token, the user is directed to the service provider's authorization page to request authorization from the user. In this procedure, the temporary token and the client's callback connection are sent to the service provider.

The user enters the user name and password on the service provider's Web page, and then authorizes the client to access the requested resource. After the authorization is successful, the service provider directs the user back to the client's Web page.

The client obtains an access token from the service provider based on the temporary token. The service provider grants a client access token based on the temporary token and the authorization of the user.

The client uses the obtained access token to access the protected resources that are stored on the service provider. new features of OAuth 2.0: 6 new processes user-agent The flow– client runs within the user agent (typically a Web browser). The Web server flow– client is part of the Web server program and is accessed via HTTP request, which is a simplified version of the process provided by OAuth 1.0. Device flow– is intended for clients to perform operations on a restricted device, but the end user is individually connected to another computer or device's browser Username and Password flow– The application scenario for this process is that the user trusts the client to process the identity credentials, But still do not want the client to store their user name and password, this process only applies when the user highly trusts the client. Client Credentials flow– clients apply its identity credentials to get access tokens, which supports the 2-legged OAuth scenario. The assertion flow– client uses assertion to redeem access tokens, such as SAML assertion.

OAuth support for native applications (Programs running on desktop operating systems or mobile devices) can be achieved by using the various processes above trusted token

OAuth 2.0 provides an authentication method that does not require encryption, which is based on the existing cookie authentication architecture, and token itself acts as a secret, sent over HTTPS, replacing the way it is encrypted and sent via HMAC and token secret. This allows Apicall and other simple scripting tools to be launched using curl without having to follow the original request method and sign. Signature Simplification:

For signature support, the signature mechanism is greatly simplified, without the need for special parsing, coding, and sequencing of parameters. Replace the original two secret with a secret. Short-term token and long-lasting identity credentials

The original OAuth will issue a token that is very long-term (typically a one-year or no-expiration limit), and in OAuth 2.0, the server will issue a short-term access token and a long-life refresh token. This allows the client to obtain a new access token without the user being re-operating, and also limits the validity period of access tokens. Role Separation

OAuth 2.0 will be divided into two roles:
Authorization server is responsible for obtaining the user's authorization and issuing tokens.
Resource is responsible for handling API calls.