众所周知http是无状态的协议，也就是说，HTTP 请求方和响应方间无法维护状态，都是一次性的，它不知道前后的请求都发生了什么。（是不是可以单纯的理解为它是一个超级无敌健忘的协议）
但有的场景下，我们需要维护状态。最典型的，一个用户登陆我们CSDN博客，发布、关注、评论，都应是在登录后的用户状态下的。那我每次打开页面你都让我登录？我能不给你差评吗？实在是太繁琐了吧。那怎么办呢？
这个东西就像身份证一样，坐高铁的时候刷一下身份证就能进，坐飞机的时候刷一下身份证也能进，有了身份证你就是一个合法的人，没有它你想出入一些比较正规的场合就是会有问题。
说完身份证，我至少要有个口袋装一下身份证吧？要求更高一点，身份证能随便放在口袋里吗？不怕丢吗？所以是不是要找一个合适的地方去放置我的身份证呢？
前端的存储方式有很多。
有地方存了，请求的时候就可以拼到参数里带给接口了。
刚刚的方式听起来就感觉很繁琐啊，我（前端）又要存，又要拼到参数里带给接口，有没有简单高效一点的方法？毕竟懒惰是生产力发展的第一要素是不是
答案就是 cookie。
cookie 也是前端存储的一种，但相比于 localStorage 等其他方式，借助 HTTP 头、浏览器能力，cookie 可以做到前端无感知。
一般过程是这样的：
身份证是好身份证，你能拿着身份证在人家America随意出入吗？那不合适了，没这么一个说法。
那cookie也是要限制空间范围的，就是通过Domain、path去设置（这里简单一说，毕竟不是今天重点）
Domain属性指定浏览器发出 HTTP 请求时，哪些域名要附带这个 Cookie。如果没有指定该属性，浏览器会默认将其设为当前 URL 的一级域名，比如 http://www.example.com 会设为 http://example.com，而且以后如果访问http://example.com的任何子域名，HTTP 请求也会带上这个 Cookie。如果服务器在Set-Cookie字段指定的域名，不属于当前域名，浏览器会拒绝这个 Cookie。
Path属性指定浏览器发出 HTTP 请求时，哪些路径要附带这个 Cookie。只要浏览器发现，Path属性是 HTTP 请求路径的开头一部分，就会在头信息里面带上这个 Cookie。比如，PATH属性是/，那么请求/docs路径也会包含该 Cookie。当然，前提是域名必须一致。
身份证是好身份证，你拿着你三岁拍的照片的身份证，用到八十岁你还用这个身份证能行吗？这不合适了，没有这么一个说法的
那么cookie也要有时间限制，通过Expires/Max-Age去设置
Expires属性指定一个具体的到期时间，到了指定时间以后，浏览器就不再保留这个 Cookie。
Max-Age属性指定从现在开始 Cookie 存在的秒数，比如60 * 60 * 24 * 365（即一年）。过了这个时间以后，浏览器就不再保留这个 Cookie。
身份证是好身份证，你可不能随意涂改DIY吧，这可真没有这么一个说法，也就是说对于这个的使用方式，您得讲究一下
那么cookie也要讲究一下使用方式了。
Secure属性指定浏览器只有在加密协议 HTTPS 下，才能将这个 Cookie 发送到服务器。
HttpOnly属性指定该 Cookie 无法通过 JavaScript 脚本拿到，主要是Document.cookie属性、XMLHttpRequest对象和 Request API 都拿不到该属性。这样就防止了该 Cookie 被脚本读到，只有浏览器发出 HTTP 请求时，才会带上该 Cookie。
回过头来，HTTP 是如何写入和传递 cookie 及其配置的呢？
HTTP 返回的一个 Set-Cookie 头用于向浏览器写入「一条（且只能是一条）」cookie，格式为 cookie 键值 + 配置键值。例如：
Set-Cookie: username=QZW; domain=QZW.com; path=/blog; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
前端可以自己创建 cookie，如果服务端创建的 cookie 没加HttpOnly，那恭喜你也可以修改他给的 cookie。
调用document.cookie可以创建、修改 cookie，和 HTTP 一样，一次document.cookie能且只能操作一个 cookie。
了解了 cookie 后，我们知道 cookie 是最便捷的维持 HTTP 请求状态的方式，大多数前端鉴权问题都是靠 cookie 解决的。当然也可以选用别的存储方式。
那有了存储工具，接下来怎么做呢？
典型的 session 登陆/验证流程：
显然，服务端只是给 cookie 一个 sessionId，而 session 的具体内容（可能包含用户信息、session 状态等），要自己存一下。存储的方式有几种：
通常服务端是集群，而用户请求过来会走一次负载均衡，不一定打到哪台机器上。那一旦用户后续接口请求到的机器和他登录请求的机器不一致，或者登录请求的机器宕机了，session 不就失效了吗？
这个问题现在有几种解决方式。
但通常还是采用第一种方式，因为第二种相当于阉割了负载均衡，且仍没有解决「用户请求的机器宕机」的问题。
npm中有已经封装好的中间件可以直接使用（例如 express-session-npm）。主要实现了这几个功能
session的维护会给服务端造成不小的压力，我们必须找地方存放它，又要考虑分布式的问题，甚至要单独为了它启用一套 Redis 集群。有没有更好的办法呢？
回过头来想想，一个登录场景，也不必往 session 存太多东西，那为什么不直接打包到 cookie 中呢？这样服务端不用存了，每次只要核验 cookie 带的「证件」有效性就可以了，也可以携带一些轻量的信息。
这种方式通常叫做：token
token 的流程是这样的：
在前面 cookie 说过，cookie 并不是客户端存储凭证的唯一方式。token 因为它的「无状态性」，有效期、使用限制都包在 token 内容里，对 cookie 的管理能力依赖较小，客户端存起来就显得更自由。但 web 应用的主流方式仍是放在 cookie 里，毕竟少操心。
那我们如何控制 token 的有效期呢？很简单，把「过期时间」和数据一起塞进去，验证时判断就好。
JSON Web Token (JWT) 是一个开放标准，定义了一种传递 JSON 信息的方式。这些信息通过数字签名确保可信。
它是一种成熟的 token 字符串生成方案，包含了我们前面提到的数据、签名。不如直接看一下一个 JWT token 长什么样：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyaWQiOiJhIiwiaWF0IjoxNTUxOTUxOTk4fQ.2jf3kl_uKWRkwjOP6uQRJFqMlwSABcgqqcJofFH5XCo这串东西看起来好乱，那它是怎么生成的呢？
token，作为权限守护者，最重要的就是「安全」。
业务接口用来鉴权的 token，我们称之为 access token。越是权限敏感的业务，我们越希望 access token 有效期足够短，以避免被盗用。但过短的有效期会造成 access token 经常过期，过期后怎么办呢？
一种办法是，让用户重新登录获取新 token，显然不够友好，要知道有的 access token 过期时间可能只有几分钟。
另外一种办法是，再来一个 token，一个专门生成 access token 的 token，我们称为 refresh token。
有了 refresh token 后，几种情况的请求流程变成这样：
session 和 token 都是边界很模糊的概念，就像前面说的，refresh token 也可能以 session 的形式组织维护。
狭义上，我们通常认为 session 是「种在 cookie 上、数据存在服务端」的认证方案，token 是「客户端存哪都行、数据存在 token 里」的认证方案。对 session 和 token 的对比本质上是「客户端存 cookie / 存别地儿」、「服务端存数据 / 不存数据」的对比。
客户端存 cookie / 存别地儿
存 cookie 固然方便不操心，但问题也很明显：
存别的地方，可以解决没有 cookie 的场景；通过参数等方式手动带，可以避免 CSRF 攻击。
服务端存数据 / 不存数据
ps：最后一部分啦！全篇历经快三天的这一篇终于要结束了（昨天发烧了。哎～）
前面我们已经知道了，在同域下的客户端/服务端认证系统中，通过客户端携带凭证，维持一段时间内的登录状态。
但当我们业务线越来越多，就会有更多业务系统分散到不同域名下，就需要「一次登录，全线通用」的能力，叫做「单点登录」。
简单的，如果业务系统都在同一一级域名下，比如wenku.baidu.com tieba.baidu.com，就好办了。可以直接把 cookie domain 设置为一级域名 baidu.com，百度也就是这么干的。
比如滴滴这么潮的公司，同时拥有didichuxing.com xiaojukeji.com didiglobal.com等域名，种 cookie 是完全绕不开的。
这要能实现「一次登录，全线通用」，才是真正的单点登录。
这种场景下，我们需要独立的认证服务，通常被称为 SSO。
上面的过程看起来没问题，但在有些时候还是会出现问题的
比如说
对浏览器来说，SSO 域下返回的数据要怎么存，才能在访问 A 的时候带上？浏览器对跨域有严格限制，cookie、localStorage 等方式都是有域限制的。
这就需要也只能由 A 提供 A 域下存储凭证的能力。一般我们是这么做的：
时间总是过得那么快，又到了说再见的时候，但愿下次见到你，我还有勇气说出我爱你