标签：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
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。