Cookie->Session->Token的发展旅程(二)

前言

上一篇讲了为了维持HTTP协议的状态,采用了Cookie与Session机制,但是这两种机制都有自己的局限性。Cookie保存在客户端有可能被篡改,而且浏览器可以手工禁止Cookie。Session对每个用户产生一个SessionId,可以通过url或者header传递。但是Session存储在服务器端的内存中,当数据量大的时候容易发生OOM,而且不利于扩展,从一台机器扩展到两台时,就需要保证两台机器的Session复制或者Session黏连。一种方案把SessionId存储到memcached或者Redis里,但是这样就要考虑单点失败的情况,需要做备份,这样又要考虑复制问题。基于以上问题,Token诞生了。

Token概念

SessionId我们不保存在内存中,给用户发一个令牌(Token),里面包含userId,客户端自己保存,每次用户访问时在header里携带Token。

有人会问,这个Token保存在客户端也是会被人篡改啊!怎么去验证这个Token是否有效呢?

这就用到了加密、解密算法了。加解密算法有很多,改天需要单独抽出一个章节去讲解。这里可以用SHA等加密算法对UserId加密,然后生成签名,将签名和数据一起作为Token发送给客户端,流程如下:

当客户端携带这些信息访问时,服务器用同样的密钥和算法对数据进行加密,得到的签名与请求的签名比较,如果一样则说明用户已经访问过了,如果不相等,则说明用户认证不通过。流程如下:

也许你会发现,当有人偷了你的Token,伪装访问服务器,这个时候服务端也是无能为力的。

第三方网站授权

现在很多网站都用qq、微信、新浪、网易等第三方授权登录的方式。这个流程用网络的一张时序图解释,有个网站“信用卡管家”,通过网易邮箱登录, 如下图所示:

步骤:

1、浏览器访问信用卡管家网站(www.a.com),跳转到网易邮箱登录页面(www.163.com/xxx?appid=xxx&return_uri=https://wwww.a.com/callback)。

2、授权并登录网易邮箱,成功后则重定向到https://wwww.a.com/callback?code=3679,从url中获取授权码(code=3679),然后携带code再次访问网易邮箱www.163.com/xxx?appid=xxx&return_uri=https://wwww.a.com/callback&code=3679,验证授权码后,创建Token.

3、重定向https://wwww.a.com/callback?token=6789。

这样的方式隐藏了Token的获取方式。后续还会介绍spring boot + Oauth授权框架。

敬请期待。

 

关注公众号:JAVA取经之旅

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页