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取经之旅