发展史

1.很久以前，Web基本上只是浏览文档。既然是浏览，作为一个服务器，就没有必要记录某段时间内谁浏览了哪些文档。每个请求都是一个新的HTTP协议，即请求加响应。特别是，我不必记住谁刚刚发送了HTTP请求，每个请求对我来说都是全新的。这段时间很高

2.然而，随着交互式Web应用的兴起，如网上购物网站、需要登录的网站等。马上面临一个问题，那就是要管理会话，我们必须记住谁登录了系统，谁把商品放在了自己的购物车里，也就是说我必须区分每个人，这是不小的挑战，因为HTTP请求是无状态的。因此，想出的方法是给你发送一个会话id。说白了就是随机串。每个人都会收到不同的信息。每次你给我发一个HTTP请求，把这个字符串一起给我，这样我就可以分辨谁是谁了。

3.这样，大家都很骄傲，但服务器却不骄傲。每个人只需要保存自己的会话id，而服务器需要保存每个人的会话id！如果接入服务器多，就会有几千甚至几十万台。

这对服务器来说是一个巨大的开销，严重限制了服务器的扩展能力。比如我用两台机器组成一个集群，小F通过机器A登录系统，那么会话id就会保存在机器A上，如果小F的下一个请求转发给机器B呢？机器b没有小F的会话id.

有时会使用一个小技巧：会话粘性，也就是让F的请求停留在机器A上，但它不起作用。如果A机挂机，那就得去b机。

我必须复制会话，并在两台机器之间移动会话id。我累坏了。

后来出现了一个叫Memcached的技巧：会话id集中存储在一个地方，所有的机器都来这个地方访问数据，所以不需要复制，但是增加了单点故障的可能性。如果负责会话的机器死了，大家都要重新登录，估计会被骂死。

我还试图将这种单点机器带出集群以提高可靠性，但无论如何，这个小会话对我来说是一个沉重的负担

所以有人一直在想，我为什么要救这个可恶的会话，让每个客户端都救有多好？

但是，如果没有保存这些会话id，如何验证客户端发送给我的sessionid确实是我生成的？如果我们不验证，就不知道他们是不是合法的登录用户，没有善意的人可以伪造会话id，为所欲为。

嗯，对了，重点是验证！

例如，由于F已经登录了系统，我将向他发送一个包含F的用户id的令牌。下次F通过Http请求访问我时，我不能通过Http头带来这个令牌。

但是这个和会话id没有本质区别，任何人都可以伪造，所以我得想办法防止别人伪造。

然后在数据上签名。例如，我使用HMAC-SHA256算法，添加一个只有我知道的密钥，对数据进行签名，并将这个签名与数据一起用作令牌。因为别人不知道钥匙，所以不能伪造代币。

我不保存这个令牌。当F将这个令牌发送给我时，我使用相同的HMAC-SHA256算法和相同的密钥再次计算数据的签名，并将其与令牌中的签名进行比较。如果是一样的，我知道F已经登录了，可以直接获取F的用户id，如果是不一样的，数据部分肯定是被篡改了。我会告诉发件人：对不起，没有认证。

Token中的数据是明文存储的(虽然我会用Base64编码，但是没有加密)，别人还是可以看到的，所以不能把密码之类的敏感信息存储在里面。

当然，如果一个人的令牌被别人偷了，我也没办法。我也认为小偷是合法用户，这其实和一个人的会话id被别人窃取是一样的。

这样，我不保存会话id，我只是生成token，然后验证token，我用我的CPU计算时间来获取我的会话存储空间！

会话id的负担减轻了，可以说一切都很容易。现在我的机器集群可以横向扩展，用户访问量增加，直接添加机器就可以了。这种无国籍的感觉真的很棒！

饼干

Cookie是一个非常具体的东西，指的是一种可以永久存储在浏览器中的数据，它只是浏览器实现的一种数据存储功能。

Cookies由服务器生成并发送到浏览器。浏览器将kv中的cookie保存到某个目录下的文本文件中，下次请求同一个网站时将cookie发送给服务器。由于客户端存在cookie，浏览器增加了一些限制，以保证cookie不会被恶意使用，也不会占用太多的磁盘空间，所以每个域的cookie数量是有限的。

会议

会话实际上就是会话。这类似于和某人说话。你怎么知道是张三在和你说话，而不是李四？必须有一些特征(外观等。)对方这才表明自己是张三。

会话也是类似的原理。服务器需要知道谁在向自己发送请求。为了进行这种区分，服务器应该给每个客户端分配一个不同的“身份”，然后每次客户端向服务器发送请求时，都会带来这个“身份”，服务器就会知道请求来自谁。客户保存这个“身份”的方式有很多。对于浏览器客户端，默认情况下每个人都使用cookie。

服务器使用会话将用户的信息临时保存在服务器上，用户离开网站后会话将被销毁。这种存储用户信息的方式比cookie安全，但是session有一个缺陷：如果web服务器负载均衡，那么当下一个操作请求到达另一个服务器时，session就会丢失。

代币

基于令牌的身份验证在网络领域随处可见。在大多数使用网络应用编程接口的互联网公司中，令牌是处理多用户身份验证的最佳方式。

以下功能将允许您在程序中使用基于令牌的身份验证

1.无状态且可扩展

2.支持移动设备

3.跨程序调用

4.安全

使用基于令牌的身份验证的老大哥

您见过的大多数应用编程接口和网络应用程序都使用令牌。例如脸书、推特、谷歌、GitHub等。

令牌的起源

在介绍基于令牌的身份验证的原理和优点之前，让我们先来看一下之前的身份验证是如何完成的。

基于服务器的身份验证

我们都知道HTTP协议是无状态的，这意味着程序需要验证每一个请求，从而识别客户端的身份。

在此之前，程序使用存储在服务器上的登录信息来识别请求。这种方法通常通过存储会话来实现。

随着Web、应用和移动终端的兴起，这种认证方式逐渐暴露出问题。尤其是在可扩展性方面。

基于服务器的身份认证暴露的一些问题

1.Seesion:每次经过身份验证的用户发起请求时，服务器都需要创建一条记录来存储信息。当越来越多的用户发送请求时，内存开销也会增加。

2.可伸缩性：使用Seesion将登录信息存储在服务器的内存中会带来可伸缩性问题。

3.CORS(跨域资源共享):当我们需要跨多个移动设备使用数据时，跨域资源共享将是一个令人头疼的问题。当使用Ajax抓取另一个域的资源时，可以禁止请求。

4.CSRF(跨站请求伪造):当用户访问银行网站时，很容易受到跨站请求伪造的攻击，可以用来访问其他网站。

在这些问题中，可扩展行是最突出的。因此，我们有必要寻求一种更有效的方法。

基于令牌的认证原理

基于令牌的身份验证是无状态的，我们不在服务器或会话中存储用户信息。

这个概念解决了在服务器端存储信息时的许多问题

NoSession意味着您的程序可以根据需要增加或减少机器，而不用担心用户是否登录。

基于令牌的认证的令牌过程如下：

1.用户通过用户名和密码发送请求。

2.程序验证。

3.程序向客户端返回一个签名的令牌。

4.客户端存储令牌，用于每次发送请求。

5.服务器验证令牌并返回数据。

每个请求都需要一个令牌。令牌应该在HTTP的头部发送，以确保Http请求是无状态的。我们还设置了服务器属性访问控制允许源： *，这样服务器就可以接收来自所有域的请求。要点是，当ACAO报头标有*时，它不能携带像HTTP身份验证、客户端SSL证书和cookies这样的证书。

实施思路：

1.用户登录进行验证，验证成功后将令牌返回给客户端。

2.客户端接收数据并将其保存在客户端

3.每次客户端访问应用编程接口时，都会携带令牌到服务器。

4.服务器端采用过滤检查。如果验证成功，将返回请求的数据，如果验证失败，将返回错误代码

在我们验证了程序中的信息并获得令牌后，我们可以通过这个令牌做很多事情。

我们甚至可以创建一个基于权限的令牌，并将其发送给第三方应用程序，第三方应用程序可以获取我们的数据(当然，只有当我们允许特定的令牌时)

代币的优势

无状态且可扩展

存储在客户端的令牌是无状态的，可以扩展。基于这种无状态且未存储的会话信息，负载平衡器可以将用户信息从一个服务传输到其他服务器。如果我们将经过身份验证的用户信息保存在会话中，则每个请求都要求用户向经过身份验证的服务器发送身份验证信息(称为会话关联性)。当用户数量较大时，可能会造成一定的拥堵。但别担心。使用令牌后，这些问题得到了解决，因为令牌保存了用户的身份验证信息。

安全

在请求中发送令牌而不是cookie可以防止CSRF(跨站点请求伪造)。即使客户端使用cookie来存储令牌，cookie也只是一种存储机制，并不用于身份验证。没有将信息存储在会话中，我们对会话的操作就更少了。令牌具有时效性，用户需要在一段时间后重新进行身份验证。我们不必等到令牌自动过期。令牌可以被撤销。具有相同身份验证的特定令牌或一组令牌可以通过令牌撤销而无效。

可扩展性()

令牌可以创建与其他程序共享权限的程序。例如，你可以用自己的大号(Fackbook或Twitter)连接一个休闲社交账户。当通过该服务登录推特时，我们可以将这些缓冲区附加到推特的数据流中(我们允许缓冲区发布到我们的推特流中)。

使用令牌时，您可以向第三方应用程序提供可选权限。当用户希望另一个应用程序访问他们的数据时，我们可以构建自己的应用编程接口，并获得具有特殊权限的令牌。

多平台跨领域

先来说说CORS(跨域资源共享)。在扩展应用和服务时，我们需要介入各种设备和应用。

让我们的应用编程接口只服务于数据，我们也可以做出设计选择来服务于来自CDN的资产。这消除了CORS在我们为应用程序设置快速头配置后提出的问题。

只要用户拥有经过身份验证的令牌，就可以在任何域上请求数据和资源。

访问控制允许源： *基于标准

创建令牌时，可以设置一些选项。我们将在下面的文章中更详细地描述它，但是标准用法将在JSON网络令牌中得到反映。

最新的程序和文档是针对JSON网络令牌的。它支持多种语言。这意味着您可以在将来的使用中真正更改您的身份验证机制。

以上就是本文的全部内容。希望对大家的学习有帮助，支持我们。