Недавно участвовал в преобразовании старой и новой единой точки, всегда хотел, чтобы подвести итог, я обнаружил, что эта статья является более целесообразным.
Составитель следующим образом:
С появлением интерактивных веб-приложений, как онлайн торговый сайт, сайт и т.д. необходимо войти в систему, и сразу же столкнулся с проблемой, которая заключается в управлении сессии, которые должны помнить, чтобы войти систему.
Поскольку запрос HTTP является лицом без гражданства, так придумать способы, чтобы дать каждому, чтобы отправить идентификатор сеанса (с идентификатором сессии), различен для каждого человека получил, каждый раз, когда запущенное ко мне, когда HTTP запрос, это идентификатор сеанса Параллельное более.
Каждому человеку необходимо только сохранить идентификатор сеанса, идентификатор сеанса и сервера, который вы хотите, чтобы спасти всех!
Если доступ к серверу и больше, и сделали сотни тысяч, даже сотни тысяч. Говорят , что это будет огромный накладные расходы сервера , сильно ограничивает масштабируемость сервера.
Если я использую две машины образуют кластер:
Небольшой F через машину вошли в систему, она будет сохранять идентификатор сеанса на машине А, при условии небольшого запроса F направляется к машине B, как это сделать?
Session ID машина B может не маленький F ах. Иногда использует небольшой трюк: сеанс липкий, это сделать небольшой запрос F был торчащий на машине А,
Но это не будет работать , если машина похмелья, пришлось идти к машине B идти. Это должно было сделать копию сессии, идентификатор сеанса , перемещаются между двумя машинами быстро исчерпываются.
Позже, человек по имени Memcached поддержки переезда:
Идентификатор сеанса хранится централизованно в одном месте, все машины используются для доступа к данным этого места, таким образом, вы не копировать, но это увеличивает вероятность единой точки отказа, если сеанс отвечает за машину повесила трубку, все Я должен был повторно войти еще раз, она оценивается мази людей.
Также попробуйте поставить эту машину также придумать с одной точки кластера, повысить надежность, но независимо от того, что эта маленькая сессия для меня тяжелым бременем.
Таким образом, некоторые люди думали о том, почему я хочу сохранить эту неприятную сессию, просто пусть каждый клиент, чтобы сохранить хороший?
Но если вы не сохранить идентификатор сессии, как проверить идентификатор сеанса клиента присланный мне на самом деле это сделать мое поколение? Если вы не подтвердите, что мы не знаем, что они являются законным пользователь не вошел в систему, эти ребята могут подделать вредоносный идентификатор сессии, делать все, что они хотят.
Ах, да, ключевым моментом является то, чтобы проверить !
Например, небольшой F вошел в систему, я послал ему маркер (маркер), который содержит предлагаемый идентификатор пользователя небольшой F, в следующий раз, когда я посещаю небольшой F снова через запрос HTTP, когда этот маркер через HTTP-заголовок с не над ним. Но это идентификатор сессии и нет существенной разницы ах, кто-то может быть подделан, так что я должен сделать что-то, так что другие не могут подделку.
Затем данные, чтобы сделать его подпись, я, например, алгоритм HMAC-SHA256, плюс я только знаю, ключ, данные сделать подпись, подпись и данные вместе, как знак, потому что другие не знают ключ маркер не может быть подделан.
Этот маркер не сохранить, когда этот небольшой знак для F меня, я повторно использовать один и тот же алгоритм HMAC-SHA256 и тот же ключ, данные пересчитаны раз подпись, а подпись лексемы сделать сравнение, Если да, то я знаю , что маленький F вошел снова, и может быть принят непосредственно к идентификатору пользователя маленького F, если не идентичны, то часть данных , конечно , была подделана, я скажу отправителю: к сожалению, нет сертификации.
Токен данные хранятся в виде обычного текста (хотя я буду делать дальше с кодировке Base64, но не зашифрованы), он все еще можно увидеть другие, поэтому я не могу, в котором для сохранения конфиденциальной информации, такой как пароли.
当然， 如果一个人的token 被别人偷走了， 那我也没办法， 我也会认为小偷就是合法用户， 这其实和一个人的session id 被别人偷走是一样的。
这样一来， 我就不保存session id 了， 我只是生成token , 然后验证token ， 我用我的CPU计算时间获取了我的session 存储空间 ！
解除了session id这个负担， 可以说是无事一身轻， 我的机器集群现在可以轻松地做水平扩展， 用户访问量增大， 直接加机器就行。 这种无状态的感觉实在是太好了！
Cookie
cookie 是一个非常具体的东西，指的就是浏览器里面能永久存储的一种数据，仅仅是浏览器实现的一种数据存储功能。
cookie由服务器生成，发送给浏览器，浏览器把cookie以kv形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该cookie发送给服务器。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的。
Session
session 从字面上讲，就是会话。这个就类似于你和一个人交谈，你怎么知道当前和你交谈的是张三而不是李四呢？对方肯定有某种特征（长相等）表明他就是张三。
session 也是类似的道理，服务器要知道当前发请求给自己的是谁。为了做这种区分，服务器就要给每个客户端分配不同的“身份标识”，然后客户端每次向服务器发请求的时候，都带上这个“身份标识”，服务器就知道这个请求来自于谁了。至于客户端怎么保存这个“身份标识”，可以有很多种方式，对于浏览器客户端，大家都默认采用 cookie 的方式。
服务器使用session把用户的信息临时保存在了服务器上，用户离开网站后session会被销毁。这种用户信息存储方式相对cookie来说更安全，可是session有一个缺陷：如果web服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候session会丢失。
Token
在Web领域基于Token的身份验证随处可见。在大多数使用Web API的互联网公司中，tokens 是多用户下处理认证的最佳方式。
以下几点特性会让你在程序中使用基于Token的身份验证
1.无状态、可扩展
2.支持移动设备
3.跨程序调用
4.安全
那些使用基于Token的身份验证的大佬们
大部分你见到过的API和Web应用都使用tokens。例如Facebook, Twitter, Google+, GitHub等。
Token的起源
在介绍基于Token的身份验证的原理与优势之前，不妨先看看之前的认证都是怎么做的。
基于服务器的验证
我们都是知道HTTP协议是无状态的，这种无状态意味着程序需要验证每一次请求，从而辨别客户端的身份。
在这之前，程序都是通过在服务端存储的登录信息来辨别请求的。这种方式一般都是通过存储Session来完成。
随着Web，应用程序，已经移动端的兴起，这种验证的方式逐渐暴露出了问题。尤其是在可扩展性方面。
基于服务器验证方式暴露的一些问题
Seesion：每次认证用户发起请求时，服务器需要去创建一个记录来存储信息。当越来越多的用户发请求时，内存的开销也会不断增加。•可扩展性：在服务端的内存中使用Seesion存储登录信息，伴随而来的是可扩展性问题。•CORS(跨域资源共享)：当我们需要让数据跨多台移动设备上使用时，跨域资源的共享会是一个让人头疼的问题。在使用Ajax抓取另一个域的资源，就可以会出现禁止请求的情况。•CSRF(跨站请求伪造)：用户在访问银行网站时，他们很容易受到跨站请求伪造的攻击，并且能够被利用其访问其他的网站。
在这些问题中，可扩展行是最突出的。因此我们有必要去寻求一种更有行之有效的方法。
基于Token的验证原理
基于Token的身份验证是无状态的，我们不将用户信息存在服务器或Session中。
这种概念解决了在服务端存储信息时的许多问题
NoSession意味着你的程序可以根据需要去增减机器，而不用去担心用户是否登录。
基于Token的身份验证的过程如下:
•用户通过用户名和密码发送请求。
•程序验证。
•程序返回一个签名的token 给客户端。
•客户端储存token,并且每次用于每次发送请求。
•服务端验证token并返回数据。
每一次请求都需要token。token应该在HTTP的头部发送从而保证了Http请求无状态。我们同样通过设置服务器属性Access-Control-Allow-Origin:* ，让服务器能接受到来自所有域的请求。需要主要的是，在ACAO头部标明(designating)*时，不得带有像HTTP认证，客户端SSL证书和cookies的证书。
实现思路：
•用户登录校验，校验成功后就返回Token给客户端。
•客户端收到数据后保存在客户端•客户端每次访问API是携带Token到服务器端。
•服务器端采用filter过滤器校验。校验成功则返回请求数据，校验失败则返回错误码
当我们在程序中认证了信息并取得token之后，我们便能通过这个Token做许多的事情。
我们甚至能基于创建一个基于权限的token传给第三方应用程序，这些第三方程序能够获取到我们的数据（当然只有在我们允许的特定的token）
Tokens的优势——无状态、可扩展
在客户端存储的Tokens是无状态的，并且能够被扩展。基于这种无状态和不存储Session信息，负载负载均衡器能够将用户信息从一个服务传到其他服务器上。
如果我们将已验证的用户的信息保存在Session中，则每次请求都需要用户向已验证的服务器发送验证信息(称为Session亲和性)。用户量大时，可能会造成一些拥堵。
但是不要着急。使用tokens之后这些问题都迎刃而解，因为tokens自己hold住了用户的验证信息。
安全性
请求中发送token而不再是发送cookie能够防止CSRF(跨站请求伪造)。即使在客户端使用cookie存储token，cookie也仅仅是一个存储机制而不是用于认证。不将信息存储在Session中，让我们少了对session操作。
token是有时效的，一段时间之后用户需要重新验证。我们也不一定需要等到token自动失效，token有撤回的操作，通过token revocataion可以使一个特定的token或是一组有相同认证的token无效。
可扩展性
Tokens能够创建与其它程序共享权限的程序。例如，能将一个随便的社交帐号和自己的大号(Fackbook或是Twitter)联系起来。当通过服务登录Twitter(我们将这个过程Buffer)时，我们可以将这些Buffer附到Twitter的数据流上(we are allowing Buffer to post to our Twitter stream)。
使用tokens时，可以提供可选的权限给第三方应用程序。当用户想让另一个应用程序访问它们的数据，我们可以通过建立自己的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，数据和资源就能够在任何域上被请求到。
- Access-Control-Allow-Origin: *
基于标准
创建token的时候，你可以设定一些选项。我们在后续的文章中会进行更加详尽的描述，但是标准的用法会在JSON Web Tokens体现。
最近的程序和文档是供给JSON Web Tokens的。它支持众多的语言。这意味在未来的使用中你可以真正的转换你的认证机制。