什么是JWT

JSON Web Token(JWT)是一种开放标准(RFC 7519)，它定义了一种紧凑且独立的方式，可以将各方之间的信息作为JSON对象进行安全传输。 该信息可以验证和信任，因为是经过数字签名的。 JWT可以使用秘钥(使用HMAC算法)或使用RSA的公钥/私钥对进行签名。

JWT剖析

JWT基本上由.分隔的三部分组成，分别是头部，有效载荷和签名。 查看这篇优秀的文章(#/learn/json-web-tokens/)，对JWT结构进行全面的理解。

JWT工作原理

在身份验证中，当用户使用其凭据成功登录时，将返回JSON WEB TOKEN，该token必须在本地保存(通常在本地存储中，但也可以使用Cookie)，而不是像传统方法那样，在服务器创建session并返回cookie。

每当用户想要访问受保护的路径时，它应该发送JWT，通常在Authorization头中使用Bearer。 头部的内容格式如下：

这是一种无状态认证机制，因为用户状态永远不会保存在服务器内存中。 服务器的受保护路径将在Authorization头中检查有效的JWT，如果存在，那么用户将被允许访问。 由于JWT是独立的，所有必要的信息都在其中，减少了对数据库的来回访问。

这允许用户完全依赖无状态的数据API，甚至向下游服务发出请求。 由于不使用Cookie，跨域资源共享(CORS)不成问题，所以你的API使用什么域名都没关系。

验证流程

为什么要使用JWT

你使用JSON Web Token有以下几个原因：

它们易于水平扩展

它们更容易维护和调试

他们有能力创建真正的RESTful服务

它们内置的过期机制。

JSON Web token是独立的。

上面突出的要点将在下一节中详细解释。

JWTs vs. Sessions

在JSON Web Token出现之前，我们采用主要基于服务器的身份验证。 众所周知，HTTP协议是无状态的，这意味着如果我们使用用户名和密码验证用户，那么在下一个请求中，应用程序将不知道我们是谁。 我们必须再次验证。 因此，需要确保在用户登录后，仍然可以在每个后续HTTP请求中验证用户的身份验证状态。

用户的凭据作为POST请求发送到服务器。 服务器认证用户。 如果凭据有效，则服务器将携带Cookie进行响应，该cookie在用户浏览器上设置，并包含一个SESSION ID以标识该用户。 用户session通过文件或服务器数据库存储在内存中。 在本节中，我将详细阐述几点，这些要点将作为在实践中比较JWT与Session的理论基础。

1. 可扩展性：随着应用程序的扩大和用户数量的增加，你必将开始水平或垂直扩展。session数据通过文件或数据库存储在服务器的内存中。在水平扩展方案中，你必须开始复制服务器数据，你必须创建一个独立的中央session存储系统，以便所有应用程序服务器都可以访问。否则，由于session存储的缺陷，你将无法扩展应用程序。解决这个挑战的另一种方法是使用 sticky session。你还可以将session存储在磁盘上，使你的应用程序在云环境中轻松扩展。这类解决方法在现代大型应用中并没有真正发挥作用。建立和维护这种分布式系统涉及到深层次的技术知识，并随之产生更高的财务成本。在这种情况下，使用JWT是无缝的;由于基于token的身份验证是无状态的，所以不需要在session中存储用户信息。我们的应用程序可以轻松扩展，因为我们可以使用token从不同的服务器访问资源，而不用担心用户是否真的登录到某台服务器上。你也可以节省成本，因为你不需要专门的服务器来存储session。为什么?因为没有session!

注意：如果你正在构建一个小型应用程序，这个程序完全不需要在多台服务器上扩展，并且不需要RESTful API的，那么session机制是很棒的。 如果你使用专用服务器运行像Redis那样的工具来存储session，那么session也可能会为你完美地运作!

2.安全性：JWT签名旨在防止在客户端被篡改，但也可以对其进行加密，以确保token携带的claim 非常安全。JWT主要是直接存储在web存储(本地/session存储)或cookies中。 JavaScript可以访问同一个域上的Web存储。这意味着你的JWT可能容易受到XSS(跨站脚本)攻击。恶意JavaScript嵌入在页面上，以读取和破坏Web存储的内容。事实上，很多人主张，由于XSS攻击，一些非常敏感的数据不应该存放在Web存储中。一个非常典型的例子是确保你的JWT不将过于敏感/可信的数据进行编码，例如用户的社会安全号码。

最初，我提到JWT可以存储在cookie中。事实上，JWT在许多情况下被存储为cookie，并且cookies很容易受到CSRF(跨站请求伪造)攻击。预防CSRF攻击的许多方法之一是确保你的cookie只能由你的域访问。作为开发人员，不管是否使用JWT，确保必要的CSRF保护措施到位以避免这些攻击。

现在，JWT和session ID也会暴露于未经防范的重放攻击。建立适合系统的重放防范技术，完全取决于开发者。解决这个问题的一个方法是确保JWT具有短期过期时间。虽然这种技术并不能完全解决问题。然而，解决这个挑战的其他替代方案是将JWT发布到特定的IP地址并使用浏览器指纹。

注意：使用HTTPS / SSL确保你的Cookie和JWT在客户端和服务器传输期间默认加密。这有助于避免中间人攻击!

3. RESTful API服务：现代应用程序的常见模式是从RESTful API查询使用JSON数据。目前大多数应用程序都有RESTful API供其他开发人员或应用程序使用。由API提供的数据具有几个明显的优点，其中之一就是这些数据可以被多个应用程序使用。在这种情况下，传统的使用session和Cookie的方法在用户认证方面效果不佳，因为它们将状态引入到应用程序中。

RESTful API的原则之一是它应该是无状态的，这意味着当发出请求时，总会返回带有参数的响应，不会产生附加影响。用户的认证状态引入这种附加影响，这破坏了这一原则。保持API无状态，不产生附加影响，意味着维护和调试变得更加容易。

另一个挑战是，由一个服务器提供API，而实际应用程序从另一个服务器调用它的模式是很常见的。为了实现这一点，我们需要启用跨域资源共享(CORS)。Cookie只能用于其发起的域，相对于应用程序，对不同域的API来说，帮助不大。在这种情况下使用JWT进行身份验证可以确保RESTful API是无状态的，你也不用担心API或应用程序由谁提供服务。

4. 性能：对此的批判性分析是非常必要的。当从客户端向服务器发出请求时，如果大量数据在JWT内进行编码，则每个HTTP请求都会产生大量的开销。然而，在会话中，只有少量的开销，因为SESSION ID实际上非常小。看下面这个例子：

JWT有5个claim：

编码时，JWT的大小将是SESSION ID(标识符)的几倍，从而在每个HTTP请求中，JWT比SESSION ID增加更多的开销。而对于session，每个请求在服务器上需要查找和反序列化session。

JWT通过将数据保留在客户端的方式以空间换时间。你应用程序的数据模型是一个重要的影响因素，因为通过防止对服务器数据库不间断的调用和查询来减少延迟。需要注意的是不要在JWT中存储太多的claim，以避免发生巨大的，过度膨胀的请求。

值得一提的是，token可能需要访问后端的数据库。特别是刷新token的情况。他们可能需要访问授权服务器上的数据库以进行黑名单处理。获取有关刷新token和何时使用它们的更多信息。另外，请查看本文，了解有关黑名单的更多信息(#/blog/blacklist-json-web-token-api-keys/)。

注意：开发者需要找到一个平衡点，使JWT真正发挥它的价值!

5.下游服务: 现代web应用程序的另一种常见模式是，它们通常依赖于下游服务。例如，在原始请求被解析之前，对主应用服务器的调用可能会向下游服务器发出请求。这里的问题是，cookie不能很方便地流到下游服务器，也不能告诉这些服务器关于用户的身份验证状态。由于每个服务器都有自己的cookie方案，所以阻力很大，并且连接它们也是困难的。JSON Web Token再次轻而易举地做到了!

使用JWTs对Auth0进行身份验证

在Auth0中，我们将JWTs作为身份验证过程的结果发布。当用户使用Auth0登录时，将创建一个JWT，签名后将其发送给用户。Auth0支持使用HMAC和RSA算法对JWT进行签名。用户可以灵活地从仪表板中选择这两种算法中的任何一种。然后，该token将用于对api进行身份验证和授权，这将授予受保护路由和资源以访问权。

我们还使用JWT在Auth0 API v2中执行身份验证和授权，取代传统不透明API密钥的使用。对于授权，JSON Web token允许细粒度安全，这是指可以在token中指定一组特定权限，从而提高了调试能力。

结论

JSON Web Token(JWT)是轻量级的，方便地跨平台跨语言使用。 这是一个不需要session来验证和授权的聪明办法。 有若个个JWT库可用于签名和验证token。 使用token的原因还有很多，Auth0可以通过简单，安全的方式实现token认证。

我个人认为没有一个一刀切的方法。 使用什么方式，将始终取决于你的应用程序架构和用例。

感谢大家阅读由java培训机构分享的“什么是JWT VS Session”希望对各位学员有所帮助，更多精彩内容请关注Java培训官网

免责声明：本文由小编转载自网络，旨在分享提供阅读，版权归原作者所有，如有侵权请联系我们进行删除