Web基础：Token

Web基础：Token

不怕猫的耗子A

已于 2022-03-03 21:22:02 修改

31631
收藏 418
分类专栏： HTTP：接口测试 文章标签： web token
版权

HTTP：接口测试
专栏收录该内容
12 篇文章7 订阅
订阅专栏
传统身份验证的方法
1、HTTP是一种没有状态的协议，也就是它并不知道是谁是访问应用
⑴客户端使用用户名还有密码通过了身份验证，不过下回这个客户端再发送请求时候，还得再验证一下用户名密码，这样就显得很麻烦

2、解决的方法就是，当用户请求登录的时候，如果没有问题，我们在服务端生成一条记录，这个记录里可以说明一下登录的用户是谁，然后把这条记录的ID号发送给客户端
⑴客户端收到以后把这个ID号存储在Cookie里，下次这个用户再向服务端发送请求的时候，可以带着这个Cookie，这样服务端会验证一个这个Cookie里的信息，看看能不能在服务端这里找到对应的记录
⑵如果可以，说明用户已经通过了身份验证，就把用户请求的数据返回给客户端

3、上面说的就是Session，我们需要在服务端存储为登录的用户生成的Session，这些Session可能会存储在内存，磁盘，或者数据库里。我们可能需要在服务端定期的去清理过期的Session

Token
1、token是一种客户端认证机制，是一个经过加密的字符串，安全性强，支持跨域

2、用户第一次登录，服务器通过数据库校验其UserId和Password合法，则再根据随机数字+userid+当前时间戳再经过DES加密生成一个token串
⑴当然具体生成token的方式是开发自己定义的

3、token的生成一般是采用uuid保证唯一性，当用户登录时为其生成唯一的token，存储一般保存在数据库中
⑴token过期时间采用把token二次保存在cookie或session里面，根据cookie和session的过期时间去维护token的过期时间

4、Token是在服务端产生的。如果前端使用用户名/密码向服务端请求认证，服务端认证成功，那么在服务端会返回Token给前端。前端可以在每次请求的时候带上Token证明自己的合法地位

5、Token，就是令牌，最大的特点就是随机性，不可预测。一般黑客或软件无法猜测出来

Token的身份验证方法
1、使用基于Token的身份验证方法，在服务端不需要存储用户的登录记录(只保留用户签名过程中的加密算法和密钥即可)

2、大概的流程是这样的：
⑴当客户端第一次请求时，发送用户信息至服务器(用户名、密码)，服务器对用户信息使用HS256算法及密钥进行签名，再将这个签名和数据一起作为Token一起返回给客户端
⑵服务器不保存Token，客户端保存Token(比如放在Cookie里或者Local Storage里)
⑶当客户端再次发送请求时，在请求信息中将Token一起发给服务器
⑷服务器用同样的HS256算法和同样的密钥，对数据再进行一次签名，和客户端返回的Token的签名进行比较，如果验证成功，就向客户端返回请求的数据

3、请求参数中带token
⑴用户在调用需要登录操作的接口时，无需传递userid和password即可完成操作(因为token代表登录成功)
⑵服务器控制过期时间，假如一个极端情况，服务器端的token规则泄露，则可以控制用户可以重新登录，获取新的token

4、当然，token也是可以保存在专门一张数据库表中的
⑴将用户名、用户生成的token信息等放到一张表中
⑵用户每次请求时，从前端获取token，然后去表中进行查询
①如果未查询到，那么说明校验失败
②如果查询到，说明校验通过：通过token来获取用户名(用户信息)
⑶总的来说就是不同的设计人员可能有不同的实现方式，总的来说还是差不多的

token的优势
1、无状态、可扩展：
⑴在客户端存储的Token是无状态的，并且能够被扩展
①基于这种无状态和不存储Session信息，负载均衡器能够将用户信息从一个服务传到其他服务器上
②session是存在服务器里面的，因此不能再服务器间共享，若负载均衡器将用户请求路由到其他服务器上后，服务器就不能识别
⑵如果我们将已验证的用户的信息保存在Session中，则每次请求都需要用户向已验证的服务器发送验证信息(称为Session亲和性)。用户量大时，可能会造成一些拥堵

2、安全性
⑴请求中发送token而不再是发送cookie能够防止CSRF(跨站请求伪造)
①即使在客户端使用cookie存储token，cookie也仅仅是一个存储机制而不是用于认证。不将信息存储在Session中，让我们少了对session操作
⑵token是有时效的，一段时间之后用户需要重新验证。我们也不一定需要等到token自动失效，token有撤回的操作，通过token revocataion可以使一个特定的token或是一组有相同认证的token无效

token如何保证安全
1、服务器端：不多说了，代码安全。

2、客户端：
①本地存储 token对称加密(因为Android一般存在SharedPreference里)

①Apk加固 防止被反编译，动态调试等等

③传输安全采用https方式，且最好双向验证，如果没有你还不想被别人抓到看到原始数据，那就至少要做一下对称加密。如果你是Http方式一定记得至少要对称加密再传输数据。

注：

1、Token一般用在两个地方:
①防止表单重复提交
①anti csrf攻击（跨站点请求伪造）

2、如果应用于“anti csrf攻击”，则服务器端会对Token值进行验证，判断是否和session中的Token值相等，若相等，则可以证明请求有效，不是伪造的

3、如果应用于“防止表单重复提交”，服务器端第一次验证相同过后，会将session中的Token值更新下
⑴若用户重复提交，第二次的验证判断将失败，因为用户提交的表单中的Token没变，但服务器端session中Token已经改变了
⑵比如，应对“重复提交”时，当第一次提交后便把已经提交的信息写到cookie中，当第二次提交时，由于cookie已经有提交记录，因此第二次提交会失败

4、运用Token服务器就不用保存session ID了，只负责生成Token，然后验证Token
⑴Token通常被放在cookie中，如果客户端不支持cookie，Token也可以放在请求头中
⑵和cookie一样，为了数据安全性Token中不应该放如密码等敏感信息，可以通过抓包工具获取Token值
————————————————
版权声明：本文为CSDN博主「不怕猫的耗子A」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_39314932/article/details/88356747