普通token登录验证和OAuth2.0应用场景(简述,之后有空再详写)

之前2月底特地看了很多关于token机制和Oauth2.0的文章。由于3月初到现在每天都很忙，所以一直没时间整理。今天其实也还是没时间。不过现大概写一些东西。后面有空在补上吧。之前忙着发现杯的作品提交材料，最近则是忙着Netty开发。

在正式介绍Token之前，先大致回顾一下Cookie和Session。（下面介绍跨度比较大，涉及内容不止Cookie和Session）

1. Cookie

​ Cookie一般是指客户端浏览器的Cookie，别的地方有没有Cookie我就不清楚了。Cookie可以用于保存一些非隐私的公用状态数据。
​ 比如早期的前端页面开发中，由于刷新页面，JS代码的变量就会失效，必须通过别的形式使一些变量能够持久化。这时候可以考虑把变量存在Cookie中，使其持久化。当然，这也不是什么最优的方式。

​ 类似的形式，把参数保存在URL中，保存在公用的JS文件中（题外话，如果是Vue的话，在一些路由操作，多页面需要公用的状态参数，可以考虑使用VUEX）
​ 总之，Cookie就是一种保存非私密状态数据的方案，作用于客户端，往往只浏览器。由于Cookie不安全，不建议存储私密数据。现在很多网站开发，也尽量避免使用Cookie了。

2. Session

​ Session同样也是保存状态的一种方式。不过Session存在于服务器。由于管理状态的是服务器，那么相对Cookie就安全许多了。比如你把你的账号密码都存在服务器中，反正服务器也不会随便把你的账号密码发给其他人。但是Cookie是在你的浏览器的，假如存了账号密码，指不定就被人盗走了。

​ Session在单机环境比较实用，在集群or分布式环境就比较麻烦了。这里先扯一会Cookie吧，你用不同浏览器访问你的QQ邮箱啥的，每次都需要登录，因为是不同浏览器，Cookie在浏览器中存储，那么不同浏览器当然Cookie不共享了（不同浏览器对HTML、JS、CSS的实现和兼容也是有区别，IE出来挨打，哈哈）。

​ 为什么说Session在集群or分布式环境比较不方便呢？这里再扯一会别的东西。啥是集群，啥是分布式？说的土一点，集群就是同一个应用/服务，复制粘贴多个相同的去运行。分布式就是不同服务放到不同服务器上。那为什么闲着慌有人要搞集群or分布式？？集群的话，你可以假设你其中一个挂了，那么只要集群中其他的相同服务还在，用户就可以正常访问了。分布式的话，如果是提供相同服务的分布式，一般是为了容灾处理，集群能够保证程序级别的容灾（比如一个java程序挂了，同一台服务器集群的java程序还或者