前言
这个博客的内容是我笔记里面粘过来的,可能有些内容都是以前从别人的博客抄过来总结的的,可能会有重复的问题.
1．传统身份认证
HTTP 是一种没有状态的协议，也就是它并不知道是谁是访问应用。这里我们把用户看成是客户端，客户端使用用户名还有密码通过了身份验证，不过下回这个客户端再发送请求时候，还得再验证一下。
解决的方法就是，当用户请求登录的时候，如果没有问题，我们在服务端生成一条记录，这个记录里可以说明一下登录的用户是谁，然后把这条记录的 ID 号发送给客户端，客户端收到以后把这个 ID 号存储在 Cookie 里，下次这个用户再向服务端发送请求的时候，可以带着这个 Cookie ，这样服务端会验证一个这个 Cookie 里的信息，看看能不能在服务端这里找到对应的记录，如果可以，说明用户已经通过了身份验证，就把用户请求的数据返回给客户端。
上面说的就是 Session，我们需要在服务端存储为登录的用户生成的 Session ，这些 Session 可能会存储在内存，磁盘，或者数据库里。我们可能需要在服务端定期的去清理过期的 Session 。
这种认证中出现的问题是：
Session：每次认证用户发起请求时，服务器需要去创建一个记录来存储信息。当越来越多的用户发请求时，内存的开销也会不断增加。
可扩展性：在服务端的内存中使用Session存储登录信息，伴随而来的是可扩展性问题。
CORS(跨域资源共享)：当我们需要让数据跨多台移动设备上使用时，跨域资源的共享会是一个让人头疼的问题。在使用Ajax抓取另一个域的资源，就可以会出现禁止请求的情况。
CSRF(跨站请求伪造)：用户在访问银行网站时，他们很容易受到跨站请求伪造的攻击，并且能够被利用其访问其他的网站。
在这些问题中，可扩展性是最突出的。因此我们有必要去寻求一种更有行之有效的方法。
2．Token身份认证
使用基于 Token 的身份验证方法，在服务端不需要存储用户的登录记录。大概的流程是这样的：
客户端使用用户名、密码请求登录
服务端收到请求，去验证用户名、密码
验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端
客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 、Session Storage里
客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据
使用Token验证的优势：
无状态、可扩展
在客户端存储的Tokens是无状态的，并且能够被扩展。基于这种无状态和不存储Session信息，负载负载均衡器能够将用户信息从一个服务传到其他服务器上。
安全性
请求中发送token而不再是发送cookie能够防止CSRF(跨站请求伪造)。即使在客户端使用cookie存储token，cookie也仅仅是一个存储机制而不是用于认证。不将信息存储在Session中，让我们少了对session操作。
3．Token的来源
HTTP请求都是以无状态的形式对接。即HTTP服务器不知道本次请求和上一次请求是否有关联。所以就有了Session的引入，即服务端和客户端都保存一段文本，客户端每次发起请求都带着，这样服务器就知道客户端是否发起过请求。
这样，就导致客户端频繁向服务端发出请求数据，服务端频繁的去数据库查询用户名和密码并进行对比，判断用户名和密码正确与否。而Session的存储是需要空间的，频繁的查询数据库给服务器造成很大的压力。
在这种情况下，Token应用而生。
Token是服务端生成的一串字符串，以作客户端进行请求的一个令牌。当客户端第一次访问服务端，服务端会根据传过来的唯一标识userId，运用一些算法，并加上密钥，生成一个Token，然后通过BASE64编码一下之后将这个Token返回给客户端，客户端将Token保存起来（可以通过数据库或文件形式保存本地）。下次请求时，客户端只需要带上Token，服务器收到请求后，会用相同的算法和密钥去验证Token。
最简单的Token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，由Token的前几位+盐以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接Token请求服务器)。
4．Token的工作流程
使用基于 Token 的身份验证方法，在服务端不需要存储用户的登录记录。大概的流程是这样的：
客户端使用用户名跟密码请求登录
服务端收到请求，去验证用户名与密码
验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端
客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者数据库里
客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据
APP登录的时候发送加密的用户名和密码到服务器，服务器验证用户名和密码，如果成功，以某种方式比如随机生成32位的字符串作为Token，存储到服务器中，并返回Token到APP，以后APP请求时，凡是需要验证的地方都要带上该Token，然后服务器端验证Token，成功返回所需要的结果，失败返回错误信息，让他重新登录。
对于同一个APP同一个手机当前只有一个Token；手机APP会存储一个当前有效的Token。其中服务器上Token设置一个有效期，每次APP请求的时候都验证Token和有效期。
5．使用Token的目的
Token的目的是为了验证用户登录情况以及减轻服务器的压力，减少频繁的查询数据库，使服务器更加健壮。
Token 能解决哪些问题呢？有如下几点：
Token 完全由应用管理，所以它可以避开同源策略。
Token 可以避免 CSRF 攻击(http://dwz.cn/7joLzx)。
Token 可以是无状态的，可以在多个服务间共享。
Token 是在服务端产生的，如果前端使用用户名/密码向服务端请求认证，服务端认证成功，那么在服务端会返回 Token 给前端。
前端可以在每次请求的时候带上 Token 证明自己的合法地位。如果这个 Token 在服务端持久化（比如存入数据库），那它就是一个永久的身份令牌。
6．token有效期问题
于是，又一个问题产生了：需要为 Token 设置有效期吗？
需要设置有效期吗？
对于这个问题，我们不妨先看两个例子：
登录密码，一般要求定期改变密码，以防止泄漏，所以密码是有有效期的。
安全证书，SSL 安全证书都有有效期，目的是为了解决吊销的问题，对于这个问题的详细情况，来看看知乎的回答(http://dwz.cn/7joMhq)。
所以无论是从安全的角度考虑，还是从吊销的角度考虑，Token 都需要设有效期。
那么有效期多长合适呢？只能说，根据系统的安全需要，尽可能的短，但也不能短得离谱。
想像一下手机的自动熄屏时间，如果设置为 10 秒钟无操作自动熄屏，再次点亮需要输入密码，会不会疯？
如果你觉得不会，那就亲自试一试，设置成可以设置的最短时间，坚持一周就好（不排除有人适应这个时间，毕竟手机厂商也是有用户体验研究的）。
然后新问题产生了，如果用户在正常操作的过程中，Token 过期失效了，要求用户重新登录……用户体验岂不是很糟糕？
为了解决在操作过程不能让用户感到 Token 失效这个问题，有一种方案是在服务器端保存 Token 状态，用户每次操作都会自动刷新（推迟） Token 的过期时间——Session 就是采用这种策略来保持用户登录状态的。
然而仍然存在这样一个问题，在前后端分离、单页 App 这些情况下，每秒种可能发起很多次请求，每次都去刷新过期时间会产生非常大的代价。
如果 Token 的过期时间被持久化到数据库或文件，代价就更大了。所以通常为了提升效率，减少消耗，会把 Token 的过期时保存在缓存或者内存中。
还有另一种方案，使用 Refresh Token，它可以避免频繁的读写操作。这种方案中，服务端不需要刷新 Token 的过期时间，一旦 Token 过期，就反馈给前端，前端使用 Refresh Token 申请一个全新 Token 继续使用。
这种方案中，服务端只需要在客户端请求更新 Token 的时候对 Refresh Token 的有效性进行一次检查，大大减少了更新有效期的操作，也就避免了频繁读写。
当然 Refresh Token 也是有有效期的，但是这个有效期就可以长一点了，比如，以天为单位的时间。
时序图表示
使用 Token 和 Refresh Token 的时序图如下：
登录
业务请求
Token 过期，刷新 Token
上面的时序图中并未提到 Refresh Token 过期怎么办。不过很显然，Refresh Token 既然已经过期，就该要求用户重新登录了。
当然还可以把这个机制设计得更复杂一些，比如，Refresh Token 每次使用的时候，都更新它的过期时间，直到与它的创建时间相比，已经超过了非常长的一段时间（比如三个月），这等于是在相当长一段时间内允许 Refresh Token 自动续期。
7．token类型
为了这篇文章的目的，我们将重点讨论两种最常见的token类型：access token和refresh token。
Access Token携带了直接访问资源的必要信息。换句话说，当客户端将access token传给管理资源的服务器时，该服务器可以使用token中包含的信息来决定是否授权给客户端。access token通常有一个过期时间，而且通常时间非常短暂。
Refresh Token携带了用来获取新的access token的必要信息。换句话说，当客户端需要使用access token来访问特定资源的时候，客户端可以使用refresh token来向认证服务器请求下发新的access token。通常情况下，当旧的access token失效之后，才需要获得新的access token，或者是在第一次访问资源的时候。refresh token也有过期时间但是时间相对较长。refresh token对存储的要求通常会非常严格，以确保它不会被泄漏。它们也可以被授权服务器列入黑名单。
