OAuth2.0

OAuth2.0

OAuth(开放授权)是一个开放标准，允许用户授权第三方应用访问用户在其他平台存储的数据(前提是平台有授权)，而不需要给第三方提供账号和密码。(简单的说就是一个验证、授权的过程)

应用场景：

第三方登录。例如网站A想接入Google、QQ、wechat等第三方的登录。那么需要怎么做呢？首先是A网站根据用户的选择(Google、QQ、wechat等)重定向到对应的第三方登录页面，通过用户授权。用户授权通过后网站A会获取到一个授权码(get方式)，网站A带上授权码向第三方申请令牌（post方式），第三方通过验证后给网站返回令牌信息。网站A通过令牌信息可以调用第三方对应的接口，例如登录成功后获取用户信息。(OAuth2.0的应用场景其实有很多，比如单点登录，API调用等)

具体实现：

在OAuth2.0中，实现的方式有很多种，在这里我只写一种，即授权码模式。
授权码模式是功能最完整、流程最严密的授权模式。        
 +----------+
 | Resource |
 |   Owner  |
 |          |
 +----------+
      ^
      |
     (B)
 +----|-----+          Client Identifier      +---------------+
 |         -+----(A)-- & Redirection URI ---->|               |
 |  User-   |                                 | Authorization |
 |  Agent  -+----(B)-- User authenticates --->|     Server    |
 |          |                                 |               |
 |         -+----(C)-- Authorization Code ---<|               |
 +-|----|---+                                 +---------------+
   |    |                                         ^      v
  (A)  (C)                                        |      |
   |    |                                         |      |
   ^    v                                         |      |
 +---------+                                      |      |
 |         |>---(D)-- Authorization Code ---------'      |
 |  Client |          & Redirection URI                  |
 |         |                                             |
 |         |<---(E)----- Access Token -------------------'
 +---------+       (w/ Optional Refresh Token)

                 Figure 3: Authorization Code Flow
  (A)用户访问客户端，客户端将用户导向认证服务器(Authorization Server)
  (B)授权服务器认证资源所有者，并确定资源所有者授予或拒绝客户端的访问请求。
  (C)若资源所有者授予访问权限服务器将用户代理重定向回客户端之前提供的重定向URI（在请求中或之前）。
     重定向URI包括一个授权代码(这是一个get请求的过程，授权码是一个临时令牌用于获取后期的token)
  (D)客户端拿到临时临牌后，授权服务器请求access token，这个过程用post请求，因为get请求会被记录到系统日志
  (E)授权服务器验证客户端，验证授权代码，并确保重定向URI收到的匹配用于重定向客户端的URI 步骤（C）。
     如果有效则授权服务器回应访问令牌和可选的刷新令牌
  拿到access token后，就可以访问授权服务器提供的api了。

  本文参考OAuth2.0官网，后期附上整个过程的数据包分析以及用asp.net mvc实现的代码。
  OAuth2.0官网 https://tools.ietf.org/html/rfc6749
  从认证到授权的整个过程的英文文档如下

 Note: The lines illustrating steps (A), (B), and (C) are broken into
    two parts as they pass through the user-agent.
 The flow illustrated in Figure 3 includes the following steps:
   (A)  The client initiates the flow by directing the resource owner's
        user-agent to the authorization endpoint.  The client includes
        its client identifier, requested scope, local state, and a
        redirection URI to which the authorization server will send the
        user-agent back once access is granted (or denied).


   (B)  The authorization server authenticates the resource owner (via
        the user-agent) and establishes whether the resource owner
        grants or denies the client's access request.

   (C)  Assuming the resource owner grants access, the authorization
        server redirects the user-agent back to the client using the
        redirection URI provided earlier (in the request or during
        client registration).  The redirection URI includes an
        authorization code and any local state provided by the client
        earlier.

   (D)  The client requests an access token from the authorization
        server's token endpoint by including the authorization code
        received in the previous step.  When making the request, the
        client authenticates with the authorization server.  The client
        includes the redirection URI used to obtain the authorization
        code for verification.

   (E)  The authorization server authenticates the client, validates the
        authorization code, and ensures that the redirection URI
        received matches the URI used to redirect the client in
        step (C).  If valid, the authorization server responds back with
        an access token and, optionally, a refresh token.

推荐文章