共计 4843 个字符，预计需要花费 13 分钟才能阅读完成。
很久很久以前，Web 基本上就是文档的浏览而已，既然是浏览，作为服务器，不须要记录谁在某一段时间里都浏览了什么文档，每次申请都是一个新的 HTTP 协定，就是申请加响应，尤其是我不必记住是谁刚刚发了 HTTP 申请，每个申请对我来说都是全新的。这段时间很嗨皮。
然而随着交互式 Web 利用的衰亡，像在线购物网站，须要登录的网站等等，马上就面临一个问题，那就是要治理会话，必须记住哪些人登录零碎，哪些人往本人的购物车中放商品，也就是说我必须把每个人辨别开，这就是一个不小的挑战，因为 HTTP 申请是无状态的，所以想出的方法就是给大家发一个会话标识 (session id), 说白了就是一个随机的字串，每个人收到的都不一样，每次大家向我发动 HTTP 申请的时候，把这个字符串给一并捎过去，这样我就能辨别开谁是谁了。
这样大家很嗨皮了，可是服务器就不嗨皮了，每个人只须要保留本人的 session id，而服务器要保留所有人的 session id！如果拜访服务器多了，就得由成千上万，甚至几十万个。
这对服务器说是一个微小的开销，重大的限度了服务器扩大能力，比如说我用两个机器组成了一个集群，小 F 通过机器 A 登录了零碎，那 session id 会保留在机器 A 上，假如小 F 的下一次申请被转发到机器 B 怎么办？机器 B 可没有小 F 的 session id 啊。
有时候会采纳一点小手腕：session sticky，就是让小 F 的申请始终粘连在机器 A 上，然而这也不论用，要是机器 A 挂掉了，还得转到机器 B 去。
那只好做 session 的复制了，把 session id 在两个机器之间搬来搬去，快累死了。
起初有个叫 Memcached 的支了招：把 session id 集中存储到一个中央，所有的机器都来拜访这个中央的数据，这样一来，就不必复制了，然而减少了单点失败的可能性，要是那个负责 session 的机器挂了，所有人都得从新登录一遍，预计得被人骂死。
也尝试把这个单点的机器也搞出集群，减少可靠性，但不论如何，这小小的 session 对我来说是一个惨重的累赘
于是有人就始终在思考，我为什么要保留这可恶的 session 呢，只让每个客户端去保留该多好？
可是如果不保留这些 session id , 怎么验证客户端发给我的 session id 确实是我生成的呢？如果不去验证，咱们都不晓得他们是不是非法登录的用户，那些不怀好意的家伙们就能够伪造 session id , 随心所欲了。
嗯，对了，关键点就是验证！
比如说，小 F 曾经登录了零碎，我给他发一个令牌 (token)，里边蕴含了小 F 的 user id，下一次小 F 再次通过 Http 申请拜访我的时候，把这个 token 通过 Http header 带过去不就能够了。
不过这和 session id 没有本质区别啊，任何人都能够能够伪造，所以我得想点儿方法，让他人伪造不了。
那就对数据做一个签名吧，比如说我用 HMAC-SHA256 算法，加上一个只有我才晓得的密钥，对数据做一个签名，把这个签名和数据一起作为 token，因为密钥他人不晓得，就无奈伪造 token 了。
这个 token 我不保留，当小 F 把这个 token 给我发过去的时候，我再用同样的 HMAC-SHA256 算法和同样的密钥，对数据再计算一次签名，和 token 中的签名做个比拟，如果雷同，我就晓得小 F 曾经登录过了，并且能够间接取到小 F 的 user id , 如果不雷同，数据局部必定被人篡改过，我就通知发送者：对不起，没有认证。
Token 中的数据是明文保留的（尽管我会用 Base64 做下编码，但那不是加密），还是能够被他人看到的，所以我不能在其中保留像明码这样的敏感信息。
当然，如果一个人的 token 被他人偷走了，那我也没方法，我也会认为小偷就是非法用户，这其实和一个人的 session id 被他人偷走是一样的。
这样一来，我就不保留 session id 了，我只是生成 token , 而后验证 token，我用我的 CPU 计算工夫获取了我的 session 存储空间！
解除了 session id 这个累赘，能够说是无事一身轻，我的机器集群当初能够轻松地做程度扩大，用户访问量增大，间接加机器就行。这种无状态的感觉切实是太好了！
Cookie 是一个十分具体的货色，指的就是浏览器外面能永恒存储的一种数据，仅仅是浏览器实现的一种数据存储性能。
Cookie 由服务器生成，发送给浏览器，浏览器把 cookie 以 kv 模式保留到某个目录下的文本文件内，下一次申请同一网站时会把该 cookie 发送给服务器。因为 cookie 是存在客户端上的，所以浏览器退出了一些限度确保 cookie 不会被歹意应用，同时不会占据太多磁盘空间，所以每个域的 cookie 数量是无限的。
Session 从字面上讲，就是会话。这个就相似于你和一个人交谈，你怎么晓得以后和你交谈的是张三而不是李四呢？对方必定有某种特色（长相等）表明他就是张三。
Session 也是相似的情理，服务器要晓得以后发申请给本人的是谁。为了做这种辨别，服务器就要给每个客户端调配不同的“身份标识”，而后客户端每次向服务器发申请的时候，都带上这个“身份标识”，服务器就晓得这个申请来自于谁了。至于客户端怎么保留这个“身份标识”，能够有很多种形式，对于浏览器客户端，大家都默认采纳 cookie 的形式。
服务器应用 session 把用户的信息长期保留在了服务器上，用户来到网站后 session 会被销毁。这种用户信息存储形式绝对 cookie 来说更平安，可是 session 有一个缺点：如果 web 服务器做了负载平衡，那么下一个操作申请到了另一台服务器的时候 session 会失落。
在基于 Session 的身份验证中，服务器将在用户登录后为用户创立一个 Session。而后，Session ID 会被存储在用户浏览器的 Cookie 中。当用户放弃登录状态时，Cookie 将与每个后续申请一起被发送进来。而后，服务器能够将存储在 Cookie 上的 Session ID 与存储在内存中或者数据库中的 Session 信息进行比拟，以验证用户的身份，返回给用户客户端响应信息的时候会附带用户以后的状态。
对照上面的示意图应该更容易了解。
在 Web 畛域基于 Token 的身份验证随处可见。在大多数应用 Web API 的互联网公司中，tokens 是多用户下解决认证的最佳形式。
大部分你见到过的 API 和 Web 利用都应用 tokens。例如 Facebook, Twitter, Google+, GitHub 等。
以下几点个性会让你在程序中应用基于 Token 的身份验证：
- 无状态、可扩大
- 反对挪动设施
- 跨程序调用
- 平安
在介绍基于 Token 的身份验证的原理与劣势之前，无妨先看看之前的认证都是怎么做的。
基于服务器的验证：
咱们都是晓得 HTTP 协定是无状态的，这种无状态意味着程序须要验证每一次申请，从而分别客户端的身份。
在这之前，程序都是通过在服务端存储的登录信息来分别申请的。这种形式个别都是通过存储 Session 来实现。
随着 Web，应用程序，曾经挪动端的衰亡，这种验证的形式逐步暴露出了问题。尤其是在可扩展性方面。
基于服务器验证形式裸露的一些问题：
1.Seesion：每次认证用户发动申请时，服务器须要去创立一个记录来存储信息。当越来越多的用户发申请时，内存的开销也会一直减少。
2. 可扩展性：在服务端的内存中应用 Seesion 存储登录信息，随同而来的是可扩展性问题。
3.CORS(跨域资源共享)：当咱们须要让数据跨多台挪动设施上应用时，跨域资源的共享会是一个让人头疼的问题。在应用 Ajax 抓取另一个域的资源，就能够会呈现禁止申请的状况。
4.CSRF(跨站申请伪造)：用户在拜访银行网站时，他们很容易受到跨站申请伪造的攻打，并且可能被利用其拜访其余的网站。
在这些问题中，可扩大行是最突出的。因而咱们有必要去寻求一种更有卓有成效的办法。
基于 Token 的身份验证是无状态的，咱们不将用户信息存在服务器或 Session 中。
这种概念解决了在服务端存储信息时的许多问题。NoSession 意味着你的程序能够依据须要去增减机器，而不必去放心用户是否登录。
基于 Token 的身份验证的过程如下: - 用户通过用户名和密码发送申请。
- 程序验证。
- 程序返回一个签名的 token 给客户端。
- 客户端贮存 token, 并且每次用于每次发送申请。
- 服务端验证 token 并返回数据。
每一次申请都须要 token。token 应该在 HTTP 的头部发送从而保障了 Http 申请无状态。咱们同样通过设置服务器属性 Access-Control-Allow-Origin:，让服务器能承受到来自所有域的申请。须要次要的是，在 ACAO 头部表明 (designating) 时，不得带有像 HTTP 认证，客户端 SSL 证书和 cookies 的证书。
实现思路：
5. 用户登录校验，校验胜利后就返回 Token 给客户端。
6. 客户端收到数据后保留在客户端。
7. 客户端每次拜访 API 是携带 Token 到服务器端。
8. 服务器端采纳 filter 过滤器校验。校验胜利则返回申请数据，校验失败则返回错误码。
当咱们在程序中认证了信息并获得 token 之后，咱们便能通过这个 Token 做许多的事件。
咱们甚至能基于创立一个基于权限的 token 传给第三方应用程序，这些第三方程序可能获取到咱们的数据（当然只有在咱们容许的特定的 token）
无状态、可扩大
在客户端存储的 Token 是无状态的，并且可能被扩大。基于这种无状态和不存储 Session 信息，负载负载均衡器可能将用户信息从一个服务传到其余服务器上。
如果咱们将已验证的用户的信息保留在 Session 中，则每次申请都须要用户向已验证的服务器发送验证信息 (称为 Session 亲和性)。用户量大时，可能会造成 一些拥挤。
然而不要焦急。应用 Token 之后这些问题都迎刃而解，因为 Token 本人 hold 住了用户的验证信息。
安全性
申请中发送 token 而不再是发送 cookie 可能避免 CSRF(跨站申请伪造)。即便在客户端应用 cookie 存储 token，cookie 也仅仅是一个存储机制而不是用于认证。不将信息存储在 Session 中，让咱们少了对 session 操作。
Token 是有时效的，一段时间之后用户须要从新验证。咱们也不肯定须要等到 Token 主动生效，Token 有撤回的操作，通过 token revocataion 能够使一个特定的 Token 或是一组有雷同认证的 token 有效。
可扩展性
Token 可能创立与其它程序共享权限的程序。例如，能将一个轻易的社交帐号和本人的大号 (Fackbook 或是 Twitter) 分割起来。当通过服务登录 Twitter(咱们将这个过程 Buffer) 时，咱们能够将这些 Buffer 附到 Twitter 的数据流上 (we are allowing Buffer to post to our Twitter stream)。
应用 Token 时，能够提供可选的权限给第三方应用程序。当用户想让另一个应用程序拜访它们的数据，咱们能够通过建设本人的 API，得出非凡权限的 tokens。
多平台跨域
咱们提前先来议论一下 CORS(跨域资源共享)，对应用程序和服务进行扩大的时候，须要染指各种各种的设施和应用程序。
Having our API just serve data, we can also make the design choice to serve assets from a CDN. This eliminates the issues that CORS brings up after we set a quick header configuration for our application.
只有用户有一个通过了验证的 token，数据和资源就可能在任何域上被申请到。
基于规范
创立 Token 的时候，你能够设定一些选项。咱们在后续的文章中会进行更加详尽的形容，然而规范的用法会在 JSON Web Token 体现。
最近的程序和文档是供应 JSON Web Token 的。它反对泛滥的语言。这象征在将来的应用中你能够真正的转换你的认证机制。（end）
