关于Token的介绍，这两篇博客介绍的非常详细：
https://www.cnblogs.com/xiekeli/p/5607107.html
https://blog.csdn.net/veloi/article/details/53940022
我的这篇博客，相当于读书笔记。
OAuth（开放授权）是一个开放的授权标准，允许用户让第三方应用访问该用户在某一web服务上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。
Token用于实现服务器对客户端的认证，它本身就具有认证功能，有点类似于带有数字签名的数据包：既包含认证用户身份信息，又包含这些信息的加密值，当服务器通过用户名和密码对用户的身份进行认证后，便生成一个token发送给用户，便于以后对用户身份的识别。
一、背景:
1、Token的产生：Token是在客户端频繁向服务端请求数据，服务端频繁的去数据库查询用户名和密码并进行对比，判断用户名和密码正确与否，并作出相应提示，在这样的背景下，Token便应运而生。
2、Token的定义：Token是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。
3、使用Token的目的：Token的目的是为了减轻服务器的压力，减少频繁的查询数据库，使服务器更加健壮。
4、token的生成原理：
（1）token的结构：
- msg部分：而msg本身也有两部分组成：一部分，随机字符的主体，另一部分是过期时间戳。
- 分隔符号：用符号分隔msg部分，和加密后生成的signature签名部分，这里用的是”.“
- 签名signature,按照msg中提到的msg的信息部分，按照特定的秘钥进行加密（SHA256）。
（2）Token的加密：按照合适得加密方法对数据进行加密，通用的就是使用sha256散列算法，然后进行BASE64的格式转换。在token串中隐含过期时间的设定，从需求上讲，每条与服务器交互的token有是有过期时间的，超过这个时间范围，就无效了，需要重新从服务器中取得。
（3）token的验证：服务器接收到客户端发送的token字符串后；
- 解包：根据分隔符，将token分为：msg和signature两部分
- 对比签名
- 判断时间是否过期
二、使用过程
不同类型的认证过程，传统的cookie认证和使用token进行认证：
使用Token时，用户登录的认证过程：
用户发送请求时的认证过程，每一次请求中都带上完成签名的Token信息，这个Token信息可能在COOKIE中，也可能在HTTP的Authorization头中。
三、Token机制相对于Cookie机制的优点
- 支持跨域访问: Cookie是不允许垮域访问的，这一点对Token机制是不存在的，前提是传输的用户认证信息通过HTTP头传输.
- 无状态(也称：服务端可扩展行):Token机制在服务端不需要存储session信息，因为Token 自身包含了所有登录用户的信息，只需要在客户端的cookie或本地介质存储状态信息.
- 更适用CDN: 可以通过内容分发网络请求你服务端的所有资料（如：javascript，HTML,图片等），而你的服务端只要提供API即可.
- 去耦: 不需要绑定到一个特定的身份验证方案。Token可以在任何地方生成，只要在你的API被调用的时候，你可以进行Token生成调用即可.
更适用于移动应用: 当你的客户端是一个原生平台（iOS, Android，Windows 8等）时，Cookie是不被支持的（你需要通过Cookie容器进行处理），这时采用Token认证机制就会简单得多。 - CSRF:因为不再依赖于Cookie，所以你就不需要考虑对CSRF（跨站请求伪造）的防范。
- 性能: 一次网络往返时间（通过数据库查询session信息）总比做一次HMACSHA256计算 的Token验证和解析要费时得多.
不需要为登录页面做特殊处理: 如果你使用Protractor 做功能测试的时候，不再需要为登录页面做特殊处理. - 基于标准化:你的API可以采用标准化的 JSON Web Token (JWT). 这个标准已经存- - 在多个后端库（.NET, Ruby, Java,Python, PHP）和多家公司的支持（如：Firebase,Google, Microsoft）.
四、Token防范攻击原理
1、Token 防范Replay Attacks
所谓重放攻击就是攻击者发送一个目的主机已接收过的包，来达到欺骗系统的目的，主要用于身份认证过程。比如在浏览器端通过用户名/密码验证获得签名的Token被木马窃取。即使用户登出了系统，黑客还是可以利用窃取的Token模拟正常请求，而服务器端对此完全不知道，以为JWT机制是无状态的。
针对这种情况，可使用时间戳 +共享秘钥
这种方案，客户端和服务端都需要知道： User ID，共享秘钥
2、Token防御CSRF
https://www.cnblogs.com/hwhxy/p/7889890.html
CSRF 攻击之所以能够成功，该请求中所有的用户验证信息都是存在于 cookie 中，因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的 cookie 来通过安全验证,伪造用户的请求。
要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。可在 HTTP 请求中以参数的形式加入一个随机产生的 token，黑客并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求，黑客并不知道该如何产生token，所以无法伪造合法用户的请求。
token 可以在用户登陆后产生并放于 session 之中，然后在每次请求时把 token 从 session 中拿出，与请求中的 token 进行比对，但这种方法的难点在于如何把 token 以参数的形式加入请求。对于 GET 请求，token 将附在请求地址之后，这样 URL 就变成 http://url?csrftoken=tokenvalue。 而对于 POST 请求来说，要在 form 的最后加上 ，这样就把 token 以参数的形式加入请求了。但是，在一个网站中，可以接受请求的地方非常多，要对于每一个请求都加上 token 是很麻烦的，并且很容易漏掉，通常使用的方法就是在每次页面加载时，使用 javascript 遍历整个 dom 树，对于 dom 中所有的 a 和 form 标签后加入 token。这样可以解决大部分的请求，但是对于在页面加载之后动态生成的 html 代码，这种方法就没有作用，还需要程序员在编码时手动添加 token。
该方法还有一个缺点是难以保证 token 本身的安全。特别是在一些论坛之类支持用户自己发表内容的网站，黑客可以在上面发布自己个人网站的地址。由于系统也会在这个地址后面加上 token，黑客可以在自己的网站上得到这个 token，并马上就可以发动 CSRF 攻击。为了避免这一点，系统可以在添加 token 的时候增加一个判断，如果这个链接是链到自己本站的，就在后面添加 token，如果是通向外网则不加。不过，即使这个 csrftoken 不以参数的形式附加在请求之中，黑客的网站也同样可以通过 Referer 来得到这个 token 值以发动 CSRF 攻击。这也是一些用户喜欢手动关闭浏览器 Referer 功能的原因。