OAuth2.0

一、oauth2.0

OAuth是一个关于授权的开放网路协议，目前版本是2.0。

名词定义

• Third-party application：第三方应用程序，又称为客户端。
• Http service：HTTP服务提供商，简称“服务提供商”。
• Resource Owner：资源所有者，也称为用户。
• User Agent：用户代理，浏览器。
• Authorization server：认证服务器，服务提供商专门用来处理认证的服务器。
• Resource server：资源服务器，服务提供商存放用户生成的资源的服务器。

所以，OAuth2.0的作用就是让客户端安全可控的获取用户的授权，与服务提供商进行互动。

OAuth2.0思路

在客户端与服务提供商之间，设置了一个授权层。客户端不能直接登录服务提供商，只能登陆授权层，将用户和客户端分开。客户端登陆授权曾锁用的令牌(token)，和用户使用的密码不同。用户可以在登陆的时候，指定授权层的权限范围和有效期。

运行流程

1. A用户打开客户端之后，客户端要求用户给予授权。
2. 用户同意给客户端授权。
3. 客户端使用上一步获得的授权，想认证服务器申请令牌。
4. 认证服务器对客户端进行认证以后，确认无误，同意发放令牌。
5. 客户端使用令牌，想资源服务器请求资源。
6. 资源服务器确认令牌无误，同意向客户端开放资源。

第二步骤是关键，即用户怎么才能给客户端授权。有了这个授权，客户端就可以获取令牌，从而获得资源。

客户端的授权模式

• 授权码模式

  功能最完整，通过客户端的后台服务器，与服务提供商的认证服务器进行互动。

  1. 用户访问客户端，客户端将用户导向认证服务器。
  2. 用户选择是否给客户端授权。
  3. 用户同意授权，认证服务器将用户导向事先指定的“重定向URI”，同时附上一个授权码。
  4. 客户端收到授权码，附上早先的重定向URL“，向认证服务器申请令牌。
  5. 认证服务器核对授权码和冲形象URL，确认无误后，向客户端发送令牌和更新令牌。

  1步骤需要以下参数：

  • response_type：授权类型，固定值为“code”
  • client_id：表示客户端ID，必填。
  • redirect_url：重定向URL
  • 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

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

  • code：授权码，一般是十分钟。该授权码和客户端ID与重定向URL是一一对应关系。
  • state：如果请求包含这个参数，认证服务器会原封不动的返回这个参数。

  下面是一个例子：

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

  4步骤中，包含以下参数：

  • grant_type：授权模式，固定值为“authorization_code”。
  • code：上一步获取的授权码
  • redirect_uri：重定向URI
  • 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

  5步骤中，认证服务器返回HTTP回复，包含以下参数：

  • access_token：访问令牌
  • token_type：表示令牌类型，大小写不敏感。可以是Bearer或者mac
  • expires_in：过期时间，S单位。
  • 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头信息中明确指定不得缓存。

• 简化模式

  不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了授权码步骤。所有步骤在浏览器完成， 令牌对访问者可见，且客户端不需要认证。

• 密码模式

  在密码模式中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向服务提供商获取token。

• 客户端模式

  客户端以自己的名义而不是以用户的名义想服务提供商进行认证。严格的说，客户端模式不属于pauth框架要解决的问题。在这种模式下，用户直接向客户端注册，客户端以自己的名义要求服务提供商提供服务，不存在授权问题。步骤如下：

  • 客户端向认证服务器进行身份认证，并要求一个token
  • 认证服务器确认无误，向客户端提供token

更新令牌

用户访问的时候，如果客户端的令牌已经失效，需要使用更新令牌申请一个新的访问令牌。

客户端发送更新令牌的请求，包含以下参数：

• granttype：授权模式，固定为“refreshtoken”
• refresh_token：早前收到的更新令牌。
• scope：权限范围

二、水杉平台对接腾讯会议

腾讯会议提供的oauth2.0对接的步骤如下：

• 用户同意授权，获取auth_code
• 通过auth_code换取token
• 刷新token
• 拉取用户信息(检查token是否有效)

很明显，对接腾讯会议使用的授权模式是授权码模式。

业务需求

对于水杉的用户来说，是没有企业身份的，所以不能通过企业授权的方式直接读取学生的信息。现在的需求是，老师使用水杉平台新建一个会议，然后在会后导出学生参会的具体信息。所以在老师新建一个会议后，不能直接把参加会议的URL给到老师或者学生，我们给出的链接，只能是oauth2.0授权的连接，学生拿到链接同意授权，然后从腾讯会议获取到学生的用户名，和我们数据库的真实姓名做绑定，这样在做导出的时候，就可以根据学生的腾讯会议的用户名导出真实的姓名。

关于上下文，在oauth2.0的连接中，会传两个参数，一个是state，另一个是auth_code，auth_code用于换取token，state用于参数校验，我们这里可以利用state做上下文，在state中放学生学号，然后在回调的时候，通过state作为主键查询，从而做到数据绑定。