使用Token进行登录验证

261 阅读4分钟

 持续创作,加速成长!这是我参与「掘金日新计划 · 10 月更文挑战」的第1天,点击查看活动详情

在读大学的时候,我们开java课的时候学到了jsp,在前几堂课里面老师教会了我们一个常用用户登录的方式,那就是使用cookie加session 后来我学会了另一个验证方式 就是使用Token 

这一篇是一篇比较理论的文章 不会涉及太多代码 

 我们先来认识一下Session Session 当这个英文单词有很多意思这里的意思是会话的意思 Session是一块保存在服务器端的内存空间,一般用于保存用户的会话信息 通常情况下,当用户通过用户名,密码登录成功后,服务器内部会生成一个Session空间,并根据你的信息生成一个独一无二的Session_ID 并把它返回给Cookie 那么下次你下次用户再来访问 客户端发起请求的时候带上Cookie 然后服务器通过检查Cookie内部的Session_ID 去寻找对应的Session,如果session内有相关的用户信息,代表这个用户已经登录过了 这个时候就不需要重复的输密码了。 

使用Session保持对话信息,使用起来并不难,并且这套技术已经是十分的成熟了,但是他存在几个问题

 1.服务器的压力会大,每次客户端再次登录都发请求 回应请求这期间服务器要通过ID去寻找对应的Session而这样会浪费服务器资源,同时一旦用户数量增加的话,那么服务器就需要更大的空间,这十分消耗服务器资源

2.Session共享:现在很多网络布置服务器应用都是分布式集群,需要我们做额外的操作进行不同服务器之间的Session信息共享

3.容易被网络攻击:Session模式是依赖于浏览器端的cookie的,cookie如果被截获,用户就会很容易受到跨站请求伪造的攻击

于是这个时候我们就会使用Token

Token英文单词里面有令牌的意思(如果我没有记错的话)

Token和Session机制一样都是由服务器端生成并返回给客户端不同的是他的验证机制的不同

简单的流程如下:

在服务端验证成功账号和密码对应成功后会返回一个Token给客户端

客户端收到Token之后会把他存储起来比如存储岛Cookie或者 Local Storage 里或者Session Storage里面 这个看具体要求

没错当客户端向服务器端进行请求的时候 服务器端会对Token进行验证 如果验证成功 那就向客户端返回成功的数据 

重点的区别就是这个验证

上面的Session是一个查找 然后确认存在 服务器再做出反应

而Token他是由服务器生成的一端识别码 比如JWT生成的一段加密数据

每次当客户端携带Token去访问服务器的时候,服务器就会对Token进行解析的推算去验证这个Token是不是由本服务器生成给他签发的 如果最后验证到是那么就允许返回数据

Token验证机制的优点:

1.支持跨域访问,如果我们将Token至于请求头中就可以实现跨域范围

2.可以解决分布式集群中,服务器之间需要数据共享相关数据的问题,因为每一个服务器上只需要能够对Token的正确性方法进行验证即可节约服务器资源

3.无状态化,服务端无需存储token,可以减少服务器的空间

4.因为Token并不依赖于Cookie 所以基于Cookie的网络攻击也可以化解

5.更加适配于多端设备,也是因为Cookie 很多的比如微信写程序是不支持Cookie那么传统的Session方式就用不了的这个时候就要用到Token了

但是Token也不是没有缺点的

第一就是服务器内部并不存储Token,因此服务器并没有中途修改Token权限,所以在Token有效期结束前,他是可以为所欲为的。一般这个时候,我们都会给Token设置一个很短有效期,然后让服务器不断的更新Token和客户端一起配合,来做到中途对Token进行限制。

第二个就是比起传统的Session验证 Token的验证更加的复杂 一般情况下小的项目都是用Session更多