B04_接口测试前置知识补充：Token、JWT和OAuth2
在接口测试中，Token 也是一个躲不过去的关卡。
这一章节中我们简单说说和 Token 相关的内容吧：
- Token 技术的特点和实现原理分析
- JWT 技术分析
- OAuth2.0 授权框架
- Refresh Token 和 Access Token
- 防范 CSRF 攻击
1. Token 技术的特点和实现原理分析
由于 HTTP 协议无状态（无记忆）的特点，服务器需要必要的手段来识别发来请求的用户身份。这里有前面我们提到的 Cookie + Session 技术，但是 Cookie 是属于浏览器专用的，而现在可以访问服务器的手段又多样化了，手机APP、PAD、分布式等层出不穷，那么 Cookie 就不能以点盖面了，这时 Token 技术就应运而生了。
Session 技术的关键是交给浏览器一个唯一的字符串（称之为 SessionID），而 Token 技术的关键思想也是类似的，交给各种客户端一个唯一的字符串（称之为 Token），它们的作用简单来说都是用于用户身份的识别。
Token：翻译成“令牌”，多用于服务器端对用户的身份认证
- Token 是在服务端产生的并发送给客户端的一张身份证明（实际是一个字符串）
- 客户端向服务端请求认证（如输入用户名和密码、使用微信登录等），服务端认证成功，会返回 Token 给前端
- 客户端在每次请求的时候都要带上这个 Token ，以供服务器验明正身
在 Django REST Framework 构建的项目下，查看数据库，可以看见一个 authtoken_token 的数据表。key 字段用于存放生成的 Token 值，user_id 字段是外键，用于关联 auth_user 表，知道是哪个用户产生的 token 值，created 字段是该 Token 的创建时间，当需要设置 Token 过期时间的时候可以进行参考。
如上，实现 Token 技术，是将用户信息保存到了服务器端数据库中，先通过请求中传来的 Token 值去 authtoken_token 数据表中匹配，匹配到后再通过 user_id 到 auth_user 表中查询对应的用户名,用以识别用户身份，相当于需要进行两次数据查询，这样会增加数据库查询的开销和压力。
2. JWT 技术分析
那么我们能否把一些用户信息直接保存到 Token 中去呢？ 可以的，这就是 JWT 技术。
JWT（Json Web Token） 是一个开放标准(RFC 7519)，它利用简洁且自包含的 JSON 对象形式进行信息安全传递。所谓自包含就是将用户信息直接保存到 Token 中，而不用再去数据库中进行查询了。当然，这些信息为了辨别其真伪，也是需要数字签名来保障的。
JWT 设计的 Token 结构简单，由三个部分组成，分别是头部、负载部和签名部，三者之间以点号隔开。
JWT 的结构：
- 第一部分：头部区域，包括两部分内容，分别指明Token的类型和签名部分使用何种签名算法，这些内容需要经过Base64编码。
- 第二部分：负载区域，就是该Token的有效载荷，可以存储用户信息，例如：最常见的就是存储用户ID了，另外还可以保存用户名、过期时间等相关字段，这部分内容同样需要经过Base64编码。
- 第三部分：签名区域，使用头部规定的签名算法，对头部和负载部的Base64编码进行签名。
Base64 并不是一个加密算法，而是一种基于64个可打印字符来表示二进制数据的方法，即把数据、文件（如图片）等以64个可见字符的方式来表示，便于网络的传输和处理。我们可以通过在线工具将前面图片中抓的 JWT 值前两部分进行解码。可以看到，当前的 JWT 使用了 HS256 的加密算法，而且记录了用户的 “电话号码（识别用户身份）” 和 “学校编码”信息。
另外上图中，exp 显示的是一个过期时间，以Unix时间戳的形式来表示，我们也可以利用在线工具将其转换为易读的时间方式。
3. OAuth2.0 授权框架
随着用户需求的多样化，当前很多网站在登录的时候，不止提供了传统的“用户名/密码”方式，还允许客户使用各种社交帐号来登录，如通过微信扫码登录。这个过程中也需要用到 Token 技术来识别用户身份。
各大平台推出的授权登录系统，其实都是基于 OAuth2.0 协议标准所构建。OAuth 2.0 授权框架支持第三方应用程序，以获得对HTTP服务的有限访问。通过设计的一套交互过程，来代表资源所有者在资源所有者和HTTP服务之间，或通过允许第三方应用程序以自己的名义获取访问权限。
具体 OAuth 2.0 的实现方法，这里提供淘宝和微信开放平台的官网授权说明地址，大家可以自行参考查阅。
| 淘宝开放平台用户授权介绍 |
https://open.taobao.com/doc.htm?spm=a219a.7386653.0.0.77a7669aj8RY84&source=search&docId=102635&docType=1 |
| 微信开放平台授权流程说明 |
https://developers.weixin.qq.com/doc/oplatform/Website_App/WeChat_Login/Wechat_Login.html |
关于 OAuth 2.0 的详细规范，大家可以参考标准 《The OAuth 2.0 Authorization Framework》
地址：https://tools.ietf.org/html/rfc6749
下面以我通过微信授权登录CSDN为例，过程简单描述如下：
前提：
- 用户是自己个人信息的拥有者
- 微信的资源服务器只是存储了用户的信息，但是没有对外使用权
- 只有用户同意后，微信才能把用户部分非敏感信息透露给其他第三方应用
- 微信的授权服务器给CSDN发放一个介绍信（Token）
- CSDN拿着这个介绍信，再去微信的资源服务器获得用户信息
授权过程分析：
（A）客户端向资源所有者发起授权请求，即用户在CSDN登录页面用微信进行扫码。
（B）客户端收到资源所有者的授权同意，即微信扫码成功。
（C）客户端向授权服务器请求身份验证，即告诉微信，客户已经允许我来获取信息啦。
（D）授权服务器对客户端进行验证，如果有效（是微信认可的应用），则发出访问令牌(Token)。
（E）客户端携带访问令牌再向资源服务器请求受保护的资源。
（F）资源服务器验证访问令牌，如果有效，则提供请求资源。
4. Refresh Token 和 Access Token
以上介绍中，Token 是如此的重要，一旦用户的 Token 丢失或者被劫持，则不需要获得用户名和密码就可以用户的身份进行资源的访问了，所以要为 Token 设置一个有效期，超过这个时间段，即便获得了 Token 也没有用啦。
但是，如果 Token 的过期时间很短，那么需要用户频繁的进行授权登录，这样易用性肯定不好，所以又引入了“访问令牌（access token）”和“刷新令牌(refresh token)”的机制。
授权服务器会同时返回一个访问令牌（access token）和一个刷新令牌(refresh token)
如微信授权服务器返回的结果如下：
- 访问令牌：access_token，有效期是7200秒（2小时）
- 刷新令牌：refresh_token，拥有较长的有效期（默认30天）
{
"access_token":"ACCESS_TOKEN",
"expires_in":7200,
"refresh_token":"REFRESH_TOKEN",
"openid":"OPENID",
"scope":"SCOPE",
..........
}access_token 是调用授权关系接口的凭证，有效期较短，当其过期后，客户端会把自己以前收到的refresh_token 发送给服务器，服务器收到后再重新产生一个新的 access_token，当然，如果refresh_token 也失效后，那就需要用户重新授权了。
5. 防范 CSRF 攻击
CSRF：跨站点请求伪造(Cross—Site Request Forgery)，攻击者盗用用户的身份，并以用户的身份向目标服务器发送请求，以获取资源或者进行恶意攻击。
防御 CSRF 攻击有多种手段，这里仅以对表单进行处理为目的，为表单生成一个编号（即 Token），提交表单时要在请求中附加此 Token 值，由服务器进行验证。这样，攻击者如果只是从网络中劫持了用户的 cookie 信息，但是并没有获取到表单中附加的 Token 值，即便模拟了用户的请求也无法通过服务器的验证。
CSRF Token 在表单中的写法大致如下：
<input type="hidden" name="csrftoken" value="token_value" />在 Django 中专门有针对 CSRF 的处理。而 Xadmin 是一个基于 Django 编写的，可以替代 Django 自身的 admin 后台的管理工具。访问其官网的“示例”登录页面，直接查看页面源码，在登录表单中可以清楚的找到 CSRF Token 的内容。
还有，我们在“简书”的登录页面中，也可以找到类似的 Token 使用。
