ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

Web基础:Token

2022-06-24 11:02:31  阅读:7  来源: 互联网

标签:Web 请求 基础 token 用户 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

标签:Web,请求,基础,token,用户,Token,服务端,客户端
来源: https://www.cnblogs.com/iancloud/p/16407997.html

专注分享技术,共同学习,共同进步。侵权联系[admin#icode9.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有