作者:Prosper Otemuyiwa
译者:java达人
来源:https://ponyfoo.com/articles/json-web-tokens-vs-session-cookies
什么是JWT
JSON Web Token(JWT)是一种开放标准(RFC 7519),它定义了一种紧凑且独立的方式,可以将各方之间的信息作为JSON对象进行安全传输。 该信息可以验证和信任,因为是经过数字签名的。 JWT可以使用秘钥(使用HMAC算法)或使用RSA的公钥/私钥对进行签名。
JWT剖析
JWT基本上由.分隔的三部分组成,分别是头部,有效载荷和签名。 查看这篇优秀的文章(https://auth0.com/learn/json-web-tokens/),对JWT结构进行全面的理解。
JWT工作原理
在身份验证中,当用户使用其凭据成功登录时,将返回JSON WEB TOKEN,该token必须在本地保存(通常在本地存储中,但也可以使用Cookie),而不是像传统方法那样,在服务器创建session并返回cookie。
每当用户想要访问受保护的路径时,它应该发送JWT,通常在Authorization头中使用Bearer。 头部的内容格式如下:
Authorization: Bearer <token>
这是一种无状态认证机制,因为用户状态永远不会保存在服务器内存中。 服务器的受保护路径将在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:
{
"sub": "1234567890",
"name": "Prosper Otemuyiwa",
"admin": true,
"role": "manager",
"company": "Auth0"
}
编码时,JWT的大小将是SESSION ID(标识符)的几倍,从而在每个HTTP请求中,JWT比SESSION ID增加更多的开销。而对于session,每个请求在服务器上需要查找和反序列化session。
JWT通过将数据保留在客户端的方式以空间换时间。你应用程序的数据模型是一个重要的影响因素,因为通过防止对服务器数据库不间断的调用和查询来减少延迟。需要注意的是不要在JWT中存储太多的claim,以避免发生巨大的,过度膨胀的请求。
值得一提的是,token可能需要访问后端的数据库。特别是刷新token的情况。他们可能需要访问授权服务器上的数据库以进行黑名单处理。获取有关刷新token和何时使用它们的更多信息。另外,请查看本文,了解有关黑名单的更多信息(https://auth0.com/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达人
ID:java_daren
(扫码或长按识别)