OAuth 2.0 understanding

Make advertising, selling things to help a friend, something super cheap yo, factory direct shipping, is lower than the market price! ! ! Generally cheaper than the market price of 3-7 fold [are] brand goods, if you are interested, you can scan two-dimensional code bottom of the screen, thanks attention! ! !

Micro letter

---

        OAuth is an open network standards for authorization (authorization), and is widely used in the world, the current version is 2.0. In this paper, design ideas and run OAuth 2.0 flow and do a simple popular explanation, the main reference material for the RFC 6749. 

First, the application scenarios

        In order to understand the application of occasions OAuth, let me give you a hypothetical example.

        There is a "cloud printing" of the site, users can be stored on Google's photo, print out. In order to use this service user must be allowed to "cloud printing" read your own photos stored on Google.

        The problem is only with authorized users, Google would agree to "cloud printing" Read these photos. So, the "cloud printing" How to Get an authorized user of it?

        The traditional method is that users will their Google username and password, told the "cloud printing", which you can read the user's photos. This approach has several serious drawbacks.

(1) "cloud printing" In order to follow-up service will save the user's password, so very safe.     (2) Google had to deploy password, and we know that a simple login password is not secure.     (3) "cloud printing" Google has the power to all the information, the user can not restrict "cloud printing" authorized scope and validity of acquired user is stored in.     (4) Only users change the password, to recover the empowerment of "cloud printing" of. But to do so, it will make all other authorized users to obtain third-party applications all fail.     (5) As long as there is a third party application is cracked, it will result in the user password leak, data leakage and all password protected.

OAuth is to solve the above problems and birth.

Second, the definition of the term

        Prior to the detailed explanation OAuth 2.0, you need to know a few specific terms. They, in particular, are a few pictures, it is essential to read the back of explanation.

(1) Third-party application: third-party applications, herein also known as "client" (Client), i.e. in the example of a "cloud print."     (2) HTTP service: HTTP service provider, herein referred to as "Service Provider", ie an example of Google.     (3) Resource Owner: resource owners, herein called "user" (user).     (4) User Agent: user agent, this article refers to the browser.     (5) Authorization server: an authentication server that handles authentication service provider dedicated server is used.     (6) Resource server: server resources that a service provider server to store user-generated resource. It authentication server, which can be the same server, it can be a different server.

Know these terms above, not difficult to understand, OAuth role is to make the "client" secure, controlled access to the "user" authorization interact with the "service provider business."

Three, OAuth ideas

OAuth between the "client" and "service providers", set up a layer of authorization (authorization layer). "Client" can not log in directly to "service providers" can only login authorization layer, in order to distinguish between the user and the client area. "Client" Registration Authority layer with tokens (token), and passwords for different users. Users can login time, specify the authorized level of competence and the token is valid. 

        After the "client" login authorization layer, "Service Provider" under the authority of the scope and validity of the token to the "client" user data stored in the open.

Fourth, running processes

        OAuth 2.0 FIG operation process is as follows:

(A) after opening the user client, the client asks the user to give authorization.     (B) the user agrees to give the client authorization.     (C) The client uses the authorization obtained in the previous step, to the authentication server application token.     After (D) authentication server to authenticate the client, confirmation, agreed to release the token.     (E) The client token, apply to the resource server access to resources.     (F) confirmed that the token is correct server resources, agreed to open the resource to the client.

        Not hard to see, among the six steps above, B is the key that the user how to give the client authorization. With the future of this authorization, the client can get a token, and thus access to resources with token. Below explain one by one client to obtain the authorization of four modes.

Fifth, the client licensing model

The client must be authorized users (authorization grant), to get the token (access token). OAuth 2.0 Authorization defines four. 

• Authorization code pattern (authorization code) 
• Simplified mode (Implicit) 
• Password mode (resource owner password credentials) 
• Client mode (client credentials) 

Sixth, the authorization code pattern

        Authorization Code mode (authorization code) is the most complete, most rigorous authorization process mode. It is characterized, interact with the "Service Provider" certification server through the client's back-end server.

 

Its steps are as follows:

(A) the user access to the client, which will guide the former authentication server.     (B) the user to select whether to grant the client authorization.     (C) assuming that the user authorization is granted, the user authentication server will guide the client designated in advance "redirection URI" (redirection URI), while accompanied by an authorization code.     （D）客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。     （E）认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。

下面是上面这些步骤所需要的参数。 A步骤中，客户端申请认证的URI，包含以下参数： 

• response_type：表示授权类型，必选项，此处的值固定为"code" 
• client_id：表示客户端的ID，必选项 
• redirect_uri：表示重定向URI，可选项 
• scope：表示申请的权限范围，可选项 
• state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。 

下面是一个例子：

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

C步骤中，服务器回应客户端的URI，包含以下参数：

• code：表示授权码，必选项。该码的有效期应该很短，通常设为10分钟，客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端ID和重定向URI，是一一对应关系。 
• state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。 

下面是一个例子：

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

D步骤中，客户端向认证服务器申请令牌的HTTP请求，包含以下参数：

• grant_type：表示使用的授权模式，必选项，此处的值固定为"authorization_code"。 
• code：表示上一步获得的授权码，必选项。 
• redirect_uri：表示重定向URI，必选项，且必须与A步骤中的该参数值保持一致。 
• client_id：表示客户端ID，必选项。 

下面是一个例子:

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

E步骤中，认证服务器发送的HTTP回复，包含以下参数：

• access_token：表示访问令牌，必选项。 
• token_type：表示令牌类型，该值大小写不敏感，必选项，可以是bearer类型或mac类型。 
• expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。 
• refresh_token：表示更新令牌，用来获取下一次的访问令牌，可选项。 
• scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。 

下面是一个例子:

     HTTP/1.1 200 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"
     }

从上面代码可以看到，相关参数使用JSON格式发送（Content-Type: application/json）。此外，HTTP头信息中明确指定不得缓存。

七、简化模式

简化模式（implicit grant type）不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"授权码"这个步骤，因此得名。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。

它的步骤如下：

（A）客户端将用户导向认证服务器。     （B）用户决定是否给于客户端授权。     （C）假设用户给予授权，认证服务器将用户导向客户端指定的"重定向URI"，并在URI的Hash部分包含了访问令牌。     （D）浏览器向资源服务器发出请求，其中不包括上一步收到的Hash值。     （E）资源服务器返回一个网页，其中包含的代码可以获取Hash值中的令牌。     （F）浏览器执行上一步获得的脚本，提取出令牌。     （G）浏览器将令牌发给客户端。

下面是上面这些步骤所需要的参数，A步骤中，客户端发出的HTTP请求，包含以下参数： 

• response_type：表示授权类型，此处的值固定为"token"，必选项。 
• client_id：表示客户端的ID，必选项。 
• redirect_uri：表示重定向的URI，可选项。 
• scope：表示权限范围，可选项。 
• state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。 

下面是一个例子：

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

C步骤中，认证服务器回应客户端的URI，包含以下参数： 

• access_token：表示访问令牌，必选项。 
• token_type：表示令牌类型，该值大小写不敏感，必选项。 
• expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。 
• scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。 
• state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。 

下面是一个例子：

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

在上面的例子中，认证服务器用HTTP头信息的Location栏，指定浏览器重定向的网址。注意，在这个网址的Hash部分包含了令牌。 

        根据上面的D步骤，下一步浏览器会访问Location指定的网址，但是Hash部分不会发送。接下来的E步骤，服务提供商的资源服务器发送过来的代码，会提取出Hash中的令牌。

八、密码模式

密码模式（Resource Owner Password Credentials Grant）中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。 

        在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分，或者由一个著名公司出品。而认证服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式。

它的步骤如下：

（A）用户向客户端提供用户名和密码。     （B）客户端将用户名和密码发给认证服务器，向后者请求令牌。     （C）认证服务器确认无误后，向客户端提供访问令牌。

B步骤中，客户端发出的HTTP请求，包含以下参数： 

• grant_type：表示授权类型，此处的值固定为"password"，必选项。 
• username：表示用户名，必选项。 
• password：表示用户的密码，必选项。 
• scope：表示权限范围，可选项。 

下面是一个例子：

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

C步骤中，认证服务器向客户端发送访问令牌，下面是一个例子：

HTTP/1.1 200 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"
}

上面代码中，各个参数的含义参见《授权码模式》一节。整个过程中，客户端不得保存用户的密码。

九、客户端模式

客户端模式（Client Credentials Grant）指客户端以自己的名义，而不是以用户的名义，向"服务提供商"进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务，其实不存在授权问题。

它的步骤如下：

（A）客户端向认证服务器进行身份认证，并要求一个访问令牌。      （B）认证服务器确认无误后，向客户端提供访问令牌。

A步骤中，客户端发出的HTTP请求，包含以下参数： 

• granttype：表示授权类型，此处的值固定为"clientcredentials"，必选项。 
• scope：表示权限范围，可选项。 

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials

认证服务器必须以某种方式，验证客户端身份。 

B步骤中，认证服务器向客户端发送访问令牌，下面是一个例子。 

HTTP/1.1 200 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"
}

上面代码中，各个参数的含义参见《授权码模式》一节。

十、更新令牌

        如果用户访问的时候，客户端的"访问令牌"已经过期，则需要使用"更新令牌"申请一个新的访问令牌。客户端发出更新令牌的HTTP请求，包含以下参数：

• granttype：表示使用的授权模式，此处的值固定为"refreshtoken"，必选项。
• refresh_token：表示早前收到的更新令牌，必选项。
• scope：表示申请的授权范围，不可以超出上一次申请的范围，如果省略该参数，则表示与上一次一致。

下面是一个例子：

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