JSON Web Token(JWT)是一种使用JSON格式传递数据的网络令牌技术,它是一个开放的行业标准(RFC 7519),它定义了一种简洁的、自包含的协议格式,用于在通信双方传递json对象,传递的信息经过数字签名可以被验证和信任,它可以使用HMAC算法或使用RSA的公钥/私钥对来签名,防止内容篡改。官网:https://jwt.io/
什么时候你应该用JSON Web Token?
下列场景中使用JSON Web Token是很有用的:
Authorization (授权) : 这是使用JWT的最常见场景。一旦用户登录,后续每个请求都将包含JWT,允许用户访问该令牌允许的路由、服务和资源。单点登录是现在广泛使用的JWT的一个特性,因为它的开销很小,并且可以轻松地跨域使用。Information Exchange (信息交换) : 对于安全的在各方之间传输信息而言,JSON Web Tokens无疑是一种很好的方式。因为JWT可以被签名,例如,用公钥/私钥对,你可以确定发送人就是它们所说的那个人。另外,由于签名是使用头和有效负载计算的,您还可以验证内容没有被篡改。
JSON Web Tokens是如何工作的?
在认证的时候,当用户用他们的凭证成功登录以后,一个JSON Web Token将会被返回。此后,token就是用户凭证了,你必须非常小心以防止出现安全问题。一般而言,你保存令牌的时候不应该超过你所需要它的时间。
无论何时用户想要访问受保护的路由或者资源的时候,用户代理(通常是浏览器)都应该带上JWT,典型的,通常放在Authorization header中,用Bearer schema。
header应该看起来是这样的:
Authorization: Bearer
服务器上的受保护的路由将会检查Authorization header中的JWT是否有效,如果有效,则用户可以访问受保护的资源。如果JWT包含足够多的必需的数据,那么就可以减少对某些操作的数据库查询的需要,尽管可能并不总是如此。
如果token是在授权头(Authorization header)中发送的,那么跨源资源共享(CORS)将不会成为问题,因为它不使用cookie。
使用JWT可以实现无状态认证,那什么是无状态认证?
传统的基于session的方式是有状态认证,用户登录成功将用户的身份信息存储在服务端,这样加大了服务端的存储压力,并且这种方式不适合在分布式系统中应用。
如下图,当用户访问应用服务,每个应用服务都会去服务器查看session信息,如果session中没有该用户则说明用户没有登录,此时就会重新认证,而解决这个问题的方法是Session复制、Session黏贴。
如果是基于令牌技术在分布式系统中实现认证则服务端不用存储session,可以将用户身份信息存储在令牌中,用户认证通过后认证服务颁发令牌给用户,用户将令牌存储在客户端,去访问应用服务时携带令牌去访问,服务端从jwt解析出用户信息。这个过程就是无状态认证。
1、jwt基于json,非常方便解析。
2、可以在令牌中自定义丰富的内容,易扩展。
3、通过非对称加密算法及数字签名技术,JWT防止篡改,安全性高。
4、资源服务使用JWT可不依赖认证服务即可完成授权。
缺点:
1、JWT令牌较长,占存储空间比较大。
下边是一个JWT令牌的示例:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOlsicmVzMSJdLCJ1c2VyX 25hbWUiOiJ6aGFuZ3NhbiIsInNjb3BlIjpbImFsbCJdLCJleHAiOjE2NjQyNTQ2NzI sImF1dGhvcml0aWVzIjpbInAxIl0sImp0aSI6Ijg4OTEyYjJkLTVkMDUtNGMxNC1iY mMzLWZkZTk5NzdmZWJjNiIsImNsaWVudF9pZCI6ImMxIn0.wkDBL7roLrvdBG2oGnX eoXq-zZRgE9IVV2nxd-ez_oA
JWT令牌由三部分组成,每部分中间使用点(.)分隔,比如:xxxxx.yyyyy.zzzzz
头部包括令牌的类型(即JWT)及使用的哈希算法(如HMAC SHA256或RSA) 一个例子如下:
下边是Header部分的内容
{ "alg": "HS256", "typ": "JWT" }
将上边的内容使用Base64Url编码,得到一个字符串就是JWT令牌的第一部分。
第二部分是负载,内容也是一个json对象,它是存放有效信息的地方,它可以存放jwt提供的信息字段,比如:iss(签发者),exp(过期时间戳), sub(面向的用户)等,也可自定义字段。
此部分不建议存放敏感信息,因为此部分可以解码还原原始内容。
最后将第二部分负载使用Base64Url编码,得到一个字符串就是JWT令牌的第二部分。
一个例子:
{ "sub": "1234567890", "name": "456", "admin": true }
第三部分是签名,此部分用于防止jwt内容被篡改。
这个部分使用base64url将前两部分进行编码,编码后使用点(.)连接组成字符串,最后使用header中声明的签名算法进行签名。
一个例子:
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
base64UrlEncode(header):jwt令牌的第一部分。
base64UrlEncode(payload):jwt令牌的第二部分。
secret:签名所使用的密钥。
第三部分使用签名算法对第一部分和第二部分的内容进行签名,常用的签名算法是 HS256,常见的还有md5,sha 等,签名算法需要使用密钥进行签名,密钥不对外公开,并且签名是不可逆的,如果第三方更改了内容那么服务器验证签名就会失败,要想保证验证签名正确必须保证内容、密钥与签名前一致。
从上图可以看出认证服务和资源服务使用相同的密钥,这叫对称加密,对称加密效率高,如果一旦密钥泄露可以伪造jwt令牌。
JWT还可以使用非对称加密,认证服务自己保留私钥,将公钥下发给受信任的客户端、资源服务,公钥和私钥是配对的,成对的公钥和私钥才可以正常加密和解密,非对称加密效率低但相比对称加密非对称加密更安全一些。
使用刷新令牌可以缓解CSRF攻击。第一条规定: 刷新令牌由auth服务器作为HttpOnly cookie发送到客户端,并由浏览器在/refresh_token API调用中自动发送。因为客户端Javascript不能读取或窃取HttpOnly cookie,所以这比将其作为普通cookie或在LocalStorage中持久化要好一些。这种方法也可以免受CSRF攻击,因为即使表单提交攻击可以调用/
我在做一个全堆栈的web应用程序。我的前端由angular-cli组成,后端由node+Express构建。
基于我在网上找到的一些示例,我为我的Asp.netCore REST服务构建了一些JWT中间件。我得到的响应如下所示: 我了解如何创建access_token: 问题是我如何创建refresh_token?我到处找了找,找不到多少留档。基本上所有的参考都说“它是存储在数据库中的令牌,具有更长的TTL,您可以从中创建新的access_token”。 那么,refresh_token是否与access
问题内容: 我们正在使用JSF 1.x,并已启用服务器端状态保存。我们有一个问题,一个实施为Web机器人的恶意用户可以提交一个页面,而没有提交期望采用表格形式的所有字段。这导致一些验证器没有被调用,应该被调用,等等。 我们希望防止用户能够从表单中添加/删除字段并提交表单(如果他们想提交表单,则所有期望的字段都在此)。过去,我使用页面上字段ID的MD5哈希值以及另存为页面上隐藏字段的未知短语和会话过
我一直在使用令牌进行身份验证。然而,我不明白令牌(JWT)与cookie有何不同。两者都将存储用户信息(作为令牌中的声明),定义持久性,并将与每个客户端请求一起发送到服务器。 除了上面提到的几个问题- 谢谢
我开始学习基于令牌的身份验证,并尝试学习如何在Laravel5中实现它。我遇到了两种非常流行的技术来实现这一点,但我感到困惑,因为我对这两种技术都是新手。 Medium的这篇文章说我应该使用LucadeGasperi/oauth2-server-laravel,从Github上的明星数量和引向它的引用数量来看,我确信它在社区中是一个非常受欢迎的包。这一个应该帮助我实现OAuth。 谁能给我指出每一
问题内容: 我必须为我的OJT公司编程一个应用程序管理系统。前端将在C#中完成,后端将在SQL中完成。 现在,我从来没有做过这样的项目。在学校里,我们只有关于SQL的基本课程。不知何故,我们的老师完全没有讨论SQL注入,而我直到现在才通过网上阅读与之接触。 所以无论如何,我的问题是:如何防止C#中的SQL注入?我模糊地认为,可以通过适当地屏蔽应用程序的文本字段来做到这一点,以使其仅接受指定格式的输
我试图理解为什么JWT认证是无状态的。在有状态认证中,会有一个会话id。这里有一张JWT的代币,上面有签名。所以身份验证服务器发布JWT令牌,但是我可以说后续请求中JWT令牌的验证是由endpoint服务器(应用服务器)而不是身份验证服务器来完成的吗?我相信这是可能的,因为JWT是用截止日期(还有一些其他信息)签名的,并且认证服务器的公共证书对所有endpoint服务器都是可用的。 因此,认证服务