OAuth, short for "Open Authorization", is an open protocol that helps resource owners authorize third-party applications to access protected resources on their behalf without providing their own credentials.
1. The role of OAuth
The third-party application authorized by the resource owner to obtain the protected resource does not use the authorizer's credentials (username and password), but a security token called Access Token.
Let's use a specific example to illustrate. Suppose we have developed an App that integrates Sina Weibo authentication for publishing discounted product news. After user authorization, it can call Sina Weibo's Web API to obtain the user's email address and publish it. Corresponding discount news. Then the role of OAuth in this scenario is that the user authorizes the application (app) to call the Web API of Sina Weibo to obtain his own email address in his own name. The whole process involves the following four roles.
1. Resource Owner (Ro, Resource Owner)
The owner of the resource is also the authorizer, if it is a "person", the stock refers to the end user. Since the "resource" is represented in this scenario as the user's email address, the resource owner naturally refers to the end user.
2. Client application (Client)
The application that needs to obtain the authorization of the resource owner and finally access the protected resource, for our scenario, is the App we created.
3. Resource server
The server that ultimately hosts the resources is generally embodied as a callable Web API. For the scenario we provide, the client obtains the user's email address by calling the Web API of Sina Weibo, so Sina Weibo is the resource server.
4. Authorization server (AuthoHzatifln server)
It authenticates the user (generally the resource owner) and the client application, and issues an Access Token to the client application when the user authorizes it. In the scenario we provide, the resource server and the authentication server are combined into one, both of which are Sina Weibo.
2. Client Credentials
Generally speaking, if we need to develop our own application for a third-party authentication service, we need to register the application with the corresponding authentication service provider. After successful registration, we will get an AppID and Appsecret that uniquely identifies the application. They are equivalent to the client application's credentials, which are used by the authentication service to determine its true identity.
3. Processing flow
Although the specific execution process of OAuth2.0 varies with different types of authorization methods, the whole process is generally completed by three rounds of interaction between the client application and the resource owner, authorization server and resource server. It's called the classic "Three LeggedOAuth". As shown below:
1. The first round of obtaining user authorization
When a client application tries to obtain a protected resource, it must first obtain the authorization of the resource owner, so the first round of message exchange aims to allow the client to obtain the authorization of the resource owner (ie, the user). After the client application is authorized, it will get an object called Authorization grant, which is actually a simple string to indicate that the user's authorization has been successfully obtained.
2. The second round of obtaining Access Token
Next, the client application uses this Authorization grant to obtain the Access Token needed to access the protected resource from the authorization service.
3. The third round of access to target resources
After successfully obtaining the Access Token, the client application attaches it to the request to the resource server to obtain the target resource it needs.
四、Authorization Grant
The Authorization Grant in OAuth2.0 represents an intermediate credential (Intermediate CredentiaI), which represents the authorization of the resource owner to obtain the target resource for the client application. It reflects the method of authorization and the acquisition mechanism of Access Token.
OAuth2.0 defines the following four types of Authorization Grant, and we can also customize other types of Authorization Grant by using the extension mechanism defined therein.
1、Implicit
It represents an "implicit" authorization method, that is, the client directly obtains the Access Token under the condition of obtaining the resource owner (end user) authorization, rather than indirectly using the obtained Authorization Grant to obtain the Access Token. Then the "Three-Logged OAuth" introduced above becomes "Two-Logged OAuth"
2、Authorization Code
This is the most typical Authorization Grant. The client application will get an Authorization Code as the Authorization Grant from the authorization server after obtaining authorization from the resource owner. Before it obtains the target resource hosted in the resource server, it needs to use this Authorization Code to obtain the Access Token from the authorization server.
3、Resource Owner Password Credentials
The resource owner's credentials are directly used as the Authorization Grant to obtain the Access Token. This type of Authorization Grant seems to be contrary to the original intention of OAuth design (the main purpose of oAuth is to allow client applications to obtain protected resources on his behalf without providing resource owner credentials), but if the client The client program is trustworthy, and it is acceptable for the user (resource owner) to provide its own credentials.
4、CIient Credentials
The client application's own credentials directly serve as the Authorization Grant it uses to obtain the Access Token. This type of Authorization Grant is suitable for the client application to obtain its own resources, in other words, the client application itself is equivalent to the owner of the resource.
5. Authorization Grant authorization process
For details, see Understanding OAuth 2.0