Go OAuth 2.0 Licensing Protocol details and process

This article mainly introduces the OAuth 2.0 licensing protocol, this article explains the OAuth protocol in detail, the OAuth protocol of all aspects of the decomposition, read this article you will know exactly what is oauth, the need for friends can refer to the next

OAuth is an open network standard for licensing (authorization) that is widely used worldwide and is currently available in version 2.0.
This paper makes a concise and popular explanation for the design idea and running flow of OAuth 2.0, and the main reference material is RFC 6749.

First, the application scenario

To understand the application of OAuth, let me cite a hypothetical example.
There is a "cloud printing" of the site, you can store users in Google Photos, print out. In order to use the service, the user must have "cloud print" read the photos that they have stored on Google.

The problem is that Google agrees to "cloud print" to read the photos only if it is authorized by the user. So, "cloud printing" how to get the user's authorization?

The traditional approach is that users will be able to read the user's photos by telling them their Google username and password to "cloud stamping". There are several serious drawbacks to this approach.

(1) "Cloud printing" in order to follow up the 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 secure.
(3) "Cloud printing" has the power to obtain all the information stored by users in Google, and users cannot limit the scope and validity of "cloud stamping".
(4) The user only has to change the password, can recover to give "cloud printing" power. However, 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 result in user password leaks and 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 several specialized nouns. They are important to understand the explanations behind them, especially a few pictures.

(1) Third-party application: Third-party applications, also referred to in this article as "client", which is "cloud stamping" in the example of the previous section.
(2) The HTTP service:http service provider, referred to as the "service provider" in this article, is Google in the previous section.
(3) Resource owner: Resource owner, also known as "user" in this article.
(4) User agent: Users agents, this article refers to the browser.
(5) Authorization Server: Authentication server, which is a service provider dedicated to handling authentication.
(6) Resource Server: A resource server, which is 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 these nouns, it is not difficult to understand that the role of OAuth is to let the "client" securely controllable access to the "user" authorization, and "service provider" interaction.

Third, the idea of OAuth

OAuth between "client" and "service provider", set up an authorization layer (authorization layer). The client is not able to log on directly to the service provider, but only to the authorization layer, which distinguishes the user from the client. The token (token) used by the Client logon authorization layer is different from the user's password. The user can specify the permission range and validity period of the authorization layer token at login time.

After the client logs on to the authorization layer, the service provider opens the data stored by the user to the client based on the permission range and validity period of the token.

Iv. Operation Process

The running process for OAuth 2.0 is, for example, 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, it confirms the error and agrees to issue the token.
(E) The client uses a token to request a resource from the resource server.
(F) The resource server confirms that the token is correct and agrees to open the resource to the client.

Not ugly out, above six steps, B is the key, that is, how the user can give the client authorization. With this authorization, the client can obtain tokens and then obtain the resources by token.
The following one by one explains the four modes that the client obtains authorization.

Five, the client's licensing mode

The client must be authorized by the user (authorization grant) to get the token (access token). OAuth 2.0 defines four ways of authorizing.

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

The Authorization Code mode (authorization code) is the most complete and most process-intensive licensing mode. It is characterized by the client's backend server, and "service provider" Authentication server interaction.

Its steps are as follows:

(A) The user accesses 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 grants authorization, the authentication server directs the user to the "redirect Uri" (redirection URI) specified by the client, with an authorization code attached.
(D) The client receives the authorization code and attaches an earlier "redirect Uri" to request a token from the authentication server. This step is done on the client's backend server and is not visible to the user.
(E) The authentication server checks the authorization code and the redirect Uri, sends an access token (access token) and updates the token (refresh token) to the client after confirmation is correct.

The following are the parameters required for the above steps.

In step A, the client requests the URI for authentication, which contains the following parameters:

1.response_type: Denotes authorization type, mandatory option, where the value is fixed to "code"
2.CLIENT_ID: Indicates the ID of the client, required option
3.redirect_uri: Represents the redirect Uri, optional
4.scope: The permission range that represents the request, optional
5.state: Indicates the current state of the client, can specify any value, the authentication server will return this value unchanged.
Here is an example.

The code is 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 the C step, the server responds to the client's URI, which contains the following parameters:

1.code: Indicates authorization code, required option. The code should be short-term, 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 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.

Here is an example.

The code is 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 a token from the authentication server, which contains the following parameters:
1.grant_type: Indicates the authorization mode used, the required option, and the value here is fixed to "Authorization_code".
2.code: Indicates the authorization code obtained in the previous step, the required option.
3.redirect_uri: Indicates the redirect URI, required option, and must be consistent with the parameter value in step a.
4.CLIENT_ID: Indicates the client ID, required option.

Here is an example.

The code is as follows:

Post/token http/1.1
Host:server.example.com
Authorization:basic CZZCAGRSA3F0MZPNWDFMQMF0M2JW
Content-type:application/x-www-form-urlencodedgrant_type=authorization_code&code=splxlobezqqybys6wxsbia

& REDIRECT_URI=HTTPS%3A%2F%2FCLIENT%2EEXAMPLE%2ECOM%2FCB

In the E-step, the authentication server sends an HTTP reply that contains the following parameters:

1.access_token: Represents an access token, required option.
2.token_type: Represents the token type, which is case insensitive and must be an option, either bearer type or Mac type.
3.expires_in: Indicates the expiration time, in seconds. If this argument is omitted, the expiration time must be set in other ways.
4.refresh_token: Represents an update token that is used to obtain the next access token, which can be selected.
5.scope: Represents a permission range, which can be omitted if the scope of the client request is consistent.
Here is an example.

The code is 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 code above, the relevant parameters are sent in JSON format (Content-type:application/json). Additionally, the HTTP header information is explicitly specified not to be cached.

Vii. Simplified mode

Simplified mode (implicit grant type) does not use a third-party application's server, directly in the browser to the authentication server to request a token, skip the "Authorization Code" This step, hence the name. All steps are done in the browser, 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 that 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, which does not include the hash value received in the previous step.
(E) The resource server returns a Web page that contains code that can get tokens in the hash value.
(F) The browser executes the script obtained from the previous step, extracting the token.
(G) The browser will send the token to the client.

The following are the parameters required for the above steps.
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", the mandatory option.
2.CLIENT_ID: Indicates the ID of the client, the required option.
3.redirect_uri: The URI that represents the redirection, optional.
4.scope: Represents a permission range, optional.
5.state: Indicates the current state of the client, can specify any value, the authentication server will return this value unchanged.

Here is an example.

The code is 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 the C step, the authentication server responds to the client's URI, which contains the following parameters:

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

Here is an example.

The code is 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 uses the location bar of the HTTP header information to specify the URL of the browser redirection. Note that the hash portion of this URL contains tokens.

Depending on the D step above, the next browser accesses the URL specified by the location, but the hash portion is not sent. The next e-step, the code sent by the service provider's resource server, extracts the tokens from the hash.

Eight, password mode

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

In this mode, the user must give their own password to the client, but the client cannot store the password. This is often used in situations where the user is highly trusted by the client, such as the client is part of the operating system, or is produced by a reputable company. The authentication server can only be considered if the other authorization mode cannot be performed.

Its steps are as follows:

(A) The user is provided with 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) After the authentication server has confirmed the error, provide the client with an access token.

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", the mandatory option.
2.username: Indicates user name, Required option.
3.password: Indicates the user's password, required option.
4.scope: Represents a permission range, optional.

Here is an example.

Copy CodeThe code is 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 the C step, the authentication server sends an access token to the client, and here is an example.
Copy CodeThe code is 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 above code, the meaning of each parameter is described in the "Authorization Code mode" section.
The client must not save the user's password throughout the process.

IX. Client Mode

Client Credentials Grant means that the client authenticates to the "service provider" on its own behalf, rather than on behalf of the user. Strictly speaking, the client mode is not a problem that the OAuth framework solves. In this mode, the user directly to the client registration, the client on its own behalf of the "service provider" to provide services, 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) After the authentication server has confirmed the error, provide the client with an access token.

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

1.granttype: Represents the authorization type, where the value is fixed to "clientcredentials", the mandatory option.
2.scope: Represents a permission range, optional.

The code is as follows:

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

The authentication server must verify the client identity in some way.
In step b, the authentication server sends an access token to the client, and here is an example.

The code is 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 above code, the meaning of each parameter is described in the "Authorization Code mode" section.

X. UPDATE tokens

If the client's access token has expired when the user accesses it, a new access token needs to be requested using the update token.

The client sends an HTTP request for an update token that contains the following parameters:
1.granttype: Represents the authorization mode used, where the value is fixed to "Refreshtoken", the required option.
2.refresh_token: Indicates the update token received earlier, the required option.
3.scope: Indicates the scope of authorization for the request, not exceeding the scope of the last request, and if omitted, indicates the same as the previous one.

Here is an example.

The code is as follows:

Post/token http/1.1
Host:server.example.com
Authorization:basic CZZCAGRSA3F0MZPNWDFMQMF0M2JW
content-type:application/x-www-form-urlencodedGrant_type=refresh_token&refresh_token=tgzv3jokf0xg5qx2tlkwia simple and easy to understand examples

The first step: users login to the third-party website, using QQ login.

Second step: After clicking Login, will jump to QQ platform prompt input user name and password.

The third step: if the user name and password is correct, will prompt whether to accept the authorization, if the authorization is successful, the third party website can access your resources, QQ Avatar, user name, etc.

Certification and authorization process (including tripartite)

1, the service provider, the user to use the service provider to store protected resources, such as photos, videos, contacts list.

2. The user, the owner of the protected resource stored in the service provider.

3, the client, to access the service provider resources of third-party applications, usually the site. Before the authentication process, the client will request a client identity from the service provider.

The user accesses the client's website and wants to manipulate the resources that the user holds in the service provider.

The 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.

Finish

Go OAuth 2.0 Licensing Protocol details and process