接口测试基础——session认证和token认证

总算是把这个过程理清楚了，现在我们的思路是：what?why?How?，实际上这些个机制产生的内部逻辑是从下至上的的：遇到问题了，想办法解决，总结归纳并取名。从解决一些小问题开始生长，不断打补丁直至完善。学习接口，永远有个认识：这是客户端 和 服务器的之间的交流，可以类别为 用户 和 超市！

什么是session?

Http协议是无状态的，Session是一种让请求从无状态变成有状态的机制，实现session的方式有很多种，通过地址栏，借助cookie（cookie就是存在浏览器里的一些信息，以一个文件夹的形式存在，里面的信息是由服务端产生的）。

基于session的身份认证

借助cookie，客户端登陆成功后，服务端就能识别其后续请求，而不需要每次都登陆。

为解决数据被篡改的问题：

一种是把cookie里面的内容加密，但这种方法有两个缺点：1）cookie的大小是有限制的，2）加密方式以及密钥有泄露的风险

另一种方法是通过一个ID来辨别身份，这个ID称之为seesion id，Server只在Cookie里面存一个Session id，其余的状态都存在Server那边，可以存在数据库或内存里。其具体的认证过程如下：

1)      客户端登陆，一般输入用户名和密码

2)      服务端如果验证通过，生成session，并把它存入数据库中，并将其中的session id存放在Set-Cookie当中发给客户端

3)      客户端接收到Set-Cookie，在浏览器上会产生cookie，并把session id写入

4)      客户端后续有新的请求，都会在请求后携带sessIon id，发给服务端，服务端进行验证

5)      如果客户端登陆出去（log out），该生成的session就会在客户端和服务端都被销毁

基于session认证的不足

服务端存储每个用户的session，当用户很多时，需要大量的资源

不能很好解决跨域资源共享问题

什么是Token?

token的意思是“令牌”，是服务端生成的一串字符串，作为客户端进行请求的一个标识。

简单token的组成：uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign（签名，token的前几位以哈希算法压缩成的一定长度的十六进制字符串，为防止token泄露）。

基于token机制的身份认证

Token是服务端用自己的密钥签名的，当它收到客户带有Token的请求时，只需要再用自己的密钥去验证，就可以判断这个Token是不是自己签发的。这里面的核心就是用签名和验证，从而减轻了服务端的负担，无需再存储session。大概的流程：

1)     客户端使用用户名和密码请求登录

2)     服务端验证，验证通过，生成Token返还给客户端（一般用哈希算法，再加个随机数）。

3)     客户端收到token后把它存储起来，可以放在cookie或者Local Storage（本地内存）里

4)     客户端以后每次向服务端发送请求的时候都需要带上该token。

5)     服务端收到请求时验证Token，如果验证通过，则允许用户访问相应资源)

 

token认证与session认证的区别

token认证中，服务端不会保存token，再次访问只会对token中携带的信息进行验证，session认证服务器会给每一个session分配唯一的session id保存在服务端的数据库中，再次访问时浏览器通过cookie把session id传回给服务器，服务器根据session id找到第一次登陆时所分配的session对象

使用基于Token认证可以使API应用到不同的服务和域中