Understanding OAuth 2.0

Understanding OAuth 2.0

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 of Google's data stored by users, and users cannot limit the scope and validity of "cloud stamping".
4. Users only have to change the password, to regain the power to give "cloud printing". 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 can 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 known as "client" in this article, "Cloud stamping" in the previous example.
2. httpService: HTTP provider, referred to as "service provider" in this article, is Google in the previous section.
3. ResourceOwner: The resource owner, also known as "user" in this article.
4. User agent: This article refers to the browser.
5. AuthorizationServer: The server that the service provider is dedicated to handle authentication.
6. ResourceServer: A resource server, which is a server where a 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.

• Authorization Code mode (authorization code)
• Simplified mode (implicit)
• Password Mode (resource owner password credentials)
• Client 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:

• Response_type: Denotes authorization type, mandatory option, where the value is fixed to "code"
• CLIENT_ID: Indicates the ID of the client, required option
• Redirect_uri: Represents the redirect Uri, optional
• Scope: Represents the permission range for the request, optional
• State: Indicates the current status of the client, can specify any value, and the authentication server returns the value intact.

Here is an example.

GET/AUTHORIZE?RESPONSE_TYPE=CODE&CLIENT_ID=S6BHDRKQT3&STATE=XYZ        &redirect_uri=https%3a%2f% 2FCLIENT%2EEXAMPLE%2ECOM%2FCB http/1.1host:server.example.com

In the C step, the server responds to the client's URI, which contains the following parameters:

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

http/1.1 302 Foundlocation: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:

• Grant_type: Indicates the authorization mode used, the required option, and the value here is fixed to "Authorization_code".
• Code: Indicates the authorization code obtained in the previous step, the required option.
• Redirect_uri: Indicates the redirect URI, required option, and must be consistent with the parameter value in step a.
• CLIENT_ID: Indicates the client ID, required option.

Here is an example.

Post/token http/1.1host:server.example.comauthorization:basic Czzcagrsa3f0mzpnwdfmqmf0m2jwcontent-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:

• Access_token: Represents an access token, required option.
• Token_type: Represents the token type, which is case insensitive and must be an option, either bearer type or Mac type.
• Expires_in: Indicates the expiration time, in seconds. If this argument is omitted, the expiration time must be set in other ways.
• Refresh_token: Represents an update token that is used to obtain the next access token, which can be selected.
• Scope: Represents a permission range, which can be omitted if the scope of the client request is consistent.

Here is an example.

     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:

• Response_type: Represents the authorization type, where the value is fixed to "token", the mandatory option.
• CLIENT_ID: Indicates the ID of the client, the required option.
• Redirect_uri: The URI that represents the redirection, optional.
• Scope: Represents a permission range, optional.
• State: Indicates the current status of the client, can specify any value, and the authentication server returns the value intact.

Here is an example.

    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:

• Access_token: Represents an access token, required option.
• Token_type: Represents the token type, which is case insensitive and must be selected.
• Expires_in: Indicates the expiration time, in seconds. If this argument is omitted, the expiration time must be set in other ways.
• Scope: Represents a permission range, which can be omitted if the scope of the client request is consistent.
• 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.

     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:

• Grant_type: Represents the authorization type, where the value is fixed to "password", the mandatory option.
• Username: Indicates user name, Required option.
• Password: Indicates the user's password, required option.
• Scope: Represents a permission range, optional.

Here is an example.

     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.

     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:

• Grant Type: Represents the authorization type, where the value is fixed to "clientcredentials", the mandatory option.
• Scope: Represents a permission range, optional.

     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 client identity in some way.

In step b, the authentication server sends an access token to the client, and here is an example.

     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:

• GrantType: Represents the authorization mode used, where the value is fixed to "refreshtoken", the mandatory option.
• Refresh_token: Indicates the update token received earlier, the required option.
• Scope: Represents the scope of authorization for the request and cannot exceed the scope of the last request, and if omitted, indicates the same as the previous one.

Here is an example.

     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

Related articles

• Nginx An example module that simply returns the content of the HTTP request to the output
• RESTful API Design Guide
• VC implementation of the HTTP protocol get and Post methods
• MySQL Authentication protocol
• Several points for attention of Nginx module Fastcgi_cache
• Automating SSH password authentication without using expect

Reprint Please specify: Love Open Source» Understanding OAuth 2.0

Understanding OAuth 2.0