OAuth 2.0 Licensing Agreement Details _ other comprehensive

OAuth is an open network standard on Authorization (authorization), which is widely used worldwide, and the current version is 2.0 edition.
This paper makes a concise and popular explanation for the design idea and running flow of OAuth 2.0, the main reference material is RFC 6749.

First, the application scene

To understand the application of OAuth, let me cite a hypothetical example.
There is a "cloud printing" of the site, users can be stored in Google's photos, printing out. In order to use the service, users must let "cloud stamping" read their own stored in Google Photos.

The problem is that only with the user's authorization will Google agree to "cloud stamping" to read the photos. So how does "cloud stamping" get the user's authorization?

The traditional method is that users will be their Google username and password, told the "Cloud Printing", the latter can read the user's photos. There are several serious shortcomings in this approach.

(1) "Cloud stamping" for the follow-up service, will save the user's password, this is not safe.
(2) Google has to deploy password login, and we know that simple password login is not safe.
(3) "Cloud stamping" has the right to acquire all the information stored in Google, users can not limit the "cloud stamping" to obtain the scope and validity of the authorization.
(4) The user can only change the password to reclaim the power of "cloud stamping". But doing so will invalidate all other third-party applications that have been authorized by the user.
(5) As long as a third-party application is cracked, it will lead to user password leakage, as well as all password-protected data leaks.

OAuth was born to solve these problems.

Ii. definition of nouns

Before you explain OAuth 2.0 in detail, you need to know a few special nouns. They are very important to understand the explanations behind them, especially the graphs.

(1) Third-party application: Third-party applications, this article is also referred to as "client", which is the example in the previous section of "Cloud stamping."
(2) HTTP service:http service provider, referred to as "service provider" in this article, that is, Google in the previous example.
(3) Resource owner: Resource holder, also referred to as "user" in this article.
(4) User agent: This article refers to the browser.
(5) Authorization Server: Authentication servers, which are specifically used by service providers to process authentication servers.
(6) Resource Server: A resource server, a server where the service provider holds user-generated resources. It can be the same server as the authentication server, or it can be a different server.

Knowing the above nouns, it is not difficult to understand, the role of OAuth is to allow "clients" secure and controllable access to the "user" authorization, and "service provider" to interact.

Three, OAuth's thought

OAuth a authorization Layer (authorization layer) is set between the client and the service provider. The client cannot log on to the service provider directly, and can only log on to the authorization layer to differentiate the user from the client. The token (token) used by the client login authorization layer is different from the user's password. The user can specify the permission range and validity period of the authorization layer token when logging in.

After the "client" login authorization layer, the "service provider" opens the user's stored information to "client" according to the scope and validity of the token's permissions.

Four, the operation process

The running process of OAuth 2.0 is shown in the following illustration, excerpted from RFC 6749.

(A) After the user opens the client, the client asks the user to grant authorization.
(B) The user agrees to grant the client authorization.
(C) The client uses the authorization obtained in the previous step to request a token from the authentication server.
(D) After the authentication server authenticates the client, confirms the correctness and agrees to issue the token.
(E) The client uses the token to request a resource from the resource server.
(F) The resource server confirms that the token is correct and agrees to open resources to the client.

Not ugly out of the above six steps, B is the key, that is, how users can give client authorization. With this authorization, the client can obtain the token and then obtain the resource by token.
The following one by one explains the four modes of client access authorization.

Five, the client's licensing mode

The client must be authorized by the user (authorization grant) to obtain a token (access token). OAuth 2.0 defines four ways to authorize.

1. Authorization Code mode (authorization code)
2. Simplified mode (implicit)
3. Password Mode (resource owner password credentials)
4. Client-side mode (credentials)

Six, Authorization Code mode

Authorization Code mode (authorization code) is the most complete and the most rigorous process authorization mode. It is characterized by the client's backend server, with the "service provider" of the authentication server to interact.

Its steps are as follows:

(A) User access to the client, which directs the former to the authentication server.
(B) The user chooses whether to grant the client authorization.
(C) Assuming that the user gives the authorization, the authentication server directs the user to the "redirect Uri" (redirection URI) previously specified by the client, accompanied by an authorization code.
(D) The client receives the authorization code and attaches an earlier "redirect Uri" to the authentication server for the token. This step is done on the server in the backend of the client and is not visible to the user.
(E) The authentication server checks the authorization code and redirect Uri, and when confirmed, sends an access token (access token) and an update token (refresh token) to the client.

The following are the parameters required for these steps above.

In step A, the client requests a certified URI that contains the following parameters:

1.response_type: Indicates the type of authorization, the required option, where the value is fixed to "code"
2.CLIENT_ID: Indicates the ID of the client, required option
3.redirect_uri: Indicates a redirect URI, optional
4.scope: the permission range for the request, optional
5.state: Indicates the current state of the client, you can specify any value, the authentication server will return the value intact.
Here is an example.

Copy Code code as follows:

Get/authorize?response_type=code&client_id=s6bhdrkqt3&state=xyz
&REDIRECT_URI=HTTPS%3A%2F%2FCLIENT%2EEXAMPLE%2ECOM%2FCB http/1.1
Host:server.example.com

In step c, the server responds to the client's URI and contains the following parameters:

1.code: Authorization code, required option. The code's validity period should be very short, usually set to 10 minutes, the client can only use the code once, otherwise it will be denied by the authorized server. The code corresponds to the client ID and the redirect Uri, which is one by one.
2.state: If this parameter is included in the client's request, the authentication server's response must also contain this parameter exactly the same.

Here is an example.

Copy Code code as follows:

http/1.1 302 Found
Location:https://client.example.com/cb?code=splxlobezqqybys6wxsbia
&state=xyz

In step D, the client requests an HTTP request for the token from the authentication server, containing the following parameters:
1.grant_type: Represents the licensing mode used, required, and the value here is fixed to "Authorization_code".
2.code: Indicates the authorization code obtained from the previous step, must be selected.
3.redirect_uri: The redirection URI is required and must be consistent with the value of the parameter in step a.
4.CLIENT_ID: Indicates client ID, required option.

Here is an example.

Copy Code code as follows:

Post/token http/1.1
Host:server.example.com
Authorization:basic CZZCAGRSA3F0MZPNWDFMQMF0M2JW
content-type:application/x-www-form-urlencoded

Grant_type=authorization_code&code=splxlobezqqybys6wxsbia
&redirect_uri=https%3a%2f%2fclient%2eexample%2ecom%2fcb

In step e, the HTTP reply sent by the authentication server contains the following parameters:

1.access_token: Indicates an access token, required option.
2.token_type: Represents a token type that is not case-sensitive, required, and can be either a bearer type or a Mac type.
3.expires_in: Indicates an expiration time in seconds. If this argument is omitted, the expiration time must be set otherwise.
4.refresh_token: Represents an update token that is used to obtain the next access token, optional.
5.scope: The scope of the permission, which can be omitted if the scope of the client application is the same.
Here is an example.

Copy Code code as follows:

http/1.1 OK
Content-type:application/json;charset=utf-8
Cache-control:no-store
Pragma:no-cache

{
"Access_token": "2yotnfzfejr1zcsicmwpaa",
"Token_type": "Example",
"Expires_in": 3600,
"Refresh_token": "Tgzv3jokf0xg5qx2tlkwia",
"Example_parameter": "Example_value"
}

As you can see from the above code, the related parameters are sent using JSON format (Content-type:application/json). In addition, the HTTP header information explicitly specifies that it must not be cached.

Vii. Simplified mode

The simplified mode (implicit grant type) does not go through the server of a Third-party application, directly in the browser to the authentication server request token, skipped the "Authorization code" This step, hence the name. All steps are completed in the browser, and the token is visible to the visitor, and the client does not require authentication.

Its steps are as follows:

(A) The client directs the user to the authentication server.
(B) The user decides whether to authorize the client.
(C) Assuming the user gives authorization, the authentication server directs the user to the "redirect URI" specified by the client and includes an access token in the hash portion of the URI.
(D) The browser makes a request to the resource server, excluding the hash value that was received in the previous step.
(E) The resource server returns a Web page that contains code to get tokens in the hash value.
(F) The browser performs the script obtained in the previous step and extracts the token.
(G) The browser will send the card to the client.

The following are the parameters required for these steps above.
In step A, the client sends an HTTP request that contains the following parameters:

1.response_type: Represents the authorization type, where the value is fixed to "token" and must be selected.
2.CLIENT_ID: Indicates the ID of the client, required option.
3.redirect_uri: The URI that represents the redirection, optional.
4.scope: Permission range, optional.
5.state: Indicates the current state of the client, you can specify any value, the authentication server will return the value intact.

Here is an example.

Copy Code code as follows:

Get/authorize?response_type=token&client_id=s6bhdrkqt3&state=xyz
&REDIRECT_URI=HTTPS%3A%2F%2FCLIENT%2EEXAMPLE%2ECOM%2FCB http/1.1
Host:server.example.com

In step c, the authentication server responds to the client's URI and contains the following parameters:

1.access_token: Indicates an access token, required option.
2.token_type: Represents the token type, which is case insensitive and must be selected.
3.expires_in: Indicates an expiration time in seconds. If this argument is omitted, the expiration time must be set otherwise.
4.scope: The scope of the permission, which can be omitted if the scope of the client application is the same.
5.state: If this parameter is included in the client's request, the authentication server's response must also contain this parameter exactly the same.

Here is an example.

Copy Code code as follows:

http/1.1 302 Found
Location:http://example.com/cb#access_token=2yotnfzfejr1zcsicmwpaa
&state=xyz&token_type=example&expires_in=3600

In the example above, the authentication server specifies a browser-redirected URL with the Location column of HTTP header information. Note that the hash part of this URL contains a token.

Depending on the D step above, the next browser will visit the URL specified by location, but the hash part will not be sent. The next e step, the service provider's resource server sends over the code that extracts the token from the hash.

Eight, password mode

In password mode (Resource Owner Password Credentials Grant), users provide their own user name and password to the client. The client uses this information to request authorization from the service provider.

In this mode, the user must give their password to the client, but the client is not allowed to store the password. This is typically used in situations where the user has a high degree of trust in the client, such as a client is part of the operating system or is produced by a reputable company. The authentication server can only consider using this mode if other licensing modes cannot be implemented.

Its steps are as follows:

(A) The user provides A user name and password to the client.
(B) The client sends the user name and password to the authentication server, requesting the token from the latter.
(C) Provide access tokens to the client after the authentication server has confirmed the error.

In step B, the client sends an HTTP request that contains the following parameters:

1.grant_type: Represents the authorization type, where the value is fixed to "password" and must be selected.
2.username: Indicates user name, Required option.
3.password: Indicates the user's password and must be selected.
4.scope: Permission range, optional.

Here is an example.

Copy Code code as follows:

Post/token http/1.1
Host:server.example.com
Authorization:basic CZZCAGRSA3F0MZPNWDFMQMF0M2JW
content-type:application/x-www-form-urlencoded

grant_type=password&username=johndoe&password=a3ddj3w

In step c, the authentication server sends an access token to the client, as follows is an example.

Copy Code code as follows:

http/1.1 OK
Content-type:application/json;charset=utf-8
Cache-control:no-store
Pragma:no-cache

{
"Access_token": "2yotnfzfejr1zcsicmwpaa",
"Token_type": "Example",
"Expires_in": 3600,
"Refresh_token": "Tgzv3jokf0xg5qx2tlkwia",
"Example_parameter": "Example_value"
}

In the code above, the meaning of each parameter is shown in the "Authorization Code pattern" section.
The client must not save the user's password throughout the process.

IX. Client-side mode

Client Credentials Grant means that the client authenticates to the service provider on its own behalf, not on behalf of the user. Strictly speaking, the client mode does not belong to the OAuth framework to solve the problem. In this mode, the user registers directly with the client, and the client requests the service provider in its own name, in fact, there is no authorization problem.

Its steps are as follows:

(a) The client authenticates to the authentication server and requires an access token.
(B) Provide access tokens to the client after the authentication server has confirmed the error.

In step A, the client sends an HTTP request that contains the following parameters:

1.granttype: Indicates the type of authorization, where the value is fixed to "clientcredentials" and must be selected.
2.scope: Permission range, optional.

Copy Code code as follows:

Post/token http/1.1
Host:server.example.com
Authorization:basic CZZCAGRSA3F0MZPNWDFMQMF0M2JW
content-type:application/x-www-form-urlencoded

Grant_type=client_credentials

The authentication server must verify the identity of the client in some way.
In step b, the authentication server sends an access token to the client, as an example below.

Copy Code code as follows:

http/1.1 OK
Content-type:application/json;charset=utf-8
Cache-control:no-store
Pragma:no-cache

{
"Access_token": "2yotnfzfejr1zcsicmwpaa",
"Token_type": "Example",
"Expires_in": 3600,
"Example_parameter": "Example_value"
}

In the code above, the meaning of each parameter is shown in the "Authorization Code pattern" section.

X. Update token

If the client's access token has expired when the user accesses it, you will need to request a new access token using the update token.

The HTTP request for the client to issue an update token containing the following parameters:
1.granttype: Represents the licensing mode used, where the value is fixed to "refreshtoken" and must be selected.
2.refresh_token: Indicates an update token received earlier, must be selected.
3.scope: Indicates the scope of authorization for the request, not exceeding the scope of the last request, and if omitted, represents the previous agreement.

Here is an example.

Copy Code code as follows:

Post/token http/1.1
Host:server.example.com
Authorization:basic CZZCAGRSA3F0MZPNWDFMQMF0M2JW
content-type:application/x-www-form-urlencoded

Grant_type=refresh_token&refresh_token=tgzv3jokf0xg5qx2tlkwia

Finish