JSON Web Token(JWT)是一个开放式标准(RFC 7519),它定义了一种紧凑且自包含的方式,用于在各方之间以JSON对象安全传输信息。 这些信息可以通过数字签名进行验证和信任。 可以使用秘密(使用HMAC算法)或使用RSA的公钥/私钥对对JWT进行签名。
虽然JWT可以加密以提供各方之间的保密性,但我们将重点关注已签名的令牌。 签名的令牌可以验证其中包含的索赔的完整性,而加密令牌隐藏来自其他方的索赔。 当令牌使用公钥/私钥对进行签名时,签名还证明只有持有私钥的方是签名方。
我们来进一步解释一些概念:
Compact:
由于它们尺寸较小,JWT可以通过URL,POST参数或HTTP标头内发送。 另外,尺寸越小意味着传输速度越快。
Self-contained:
有效载荷(Playload)包含有关用户的所有必需信息,避免了多次查询数据库。
Authentication(鉴权):
这是使用JWT最常见的情况。 一旦用户登录,每个后续请求都将包含JWT,允许用户访问该令牌允许的路由,服务和资源。 单点登录是当今广泛使用JWT的一项功能,因为它的开销很小,并且能够轻松地跨不同域使用。
Information Exchange(信息交换):
JSON Web Tokens是在各方之间安全传输信息的好方式。 因为JWT可以签名:例如使用公钥/私钥对,所以可以确定发件人是他们自称的人。 此外,由于使用标头和有效载荷计算签名,因此您还可以验证内容是否未被篡改。
在紧凑的形式中,JWT包含三个由点(.)分隔的部分,它们分别是:
Header
Payload
Signature
JWT结构通常如下所示:
xxxxx.yyyyy.zzzzz下面我们分别来介绍这三个部分:
HeaderHeader通常由两部分组成:令牌的类型,即JWT。和常用的散列算法,如HMAC SHA256或RSA。
例如:
Header部分的JSON被Base64Url编码,形成JWT的第一部分。
Payload这里放声明内容,可以说就是存放沟通讯息的地方,在定义上有3种声明(Claims):
Registered claims(注册声明):
这些是一组预先定义的声明,它们不是强制性的,但推荐使用,以提供一组有用的,可互操作的声明。 其中一些是:iss(发行者),exp(到期时间),sub(主题),aud(受众)等。
Public claims(公开声明):
这些可以由使用JWT的人员随意定义。 但为避免冲突,应在IANA JSON Web令牌注册表中定义它们,或将其定义为包含防冲突命名空间的URI。
Private claims(私有声明):
这些是为了同意使用它们但是既没有登记,也没有公开声明的各方之间共享信息,而创建的定制声明。
Playload示例如下:
{ "sub": "1234567890", "name": "John Doe", "admin": true }Playload部分的JSON被Base64Url编码,形成JWT的第二部分。
++Notice:++请注意,对于已签名的令牌,此信息尽管受到篡改保护,但任何人都可以阅读。 除非加密,否则不要将秘密信息放在JWT的有效内容或标题元素中。这也是很多文章争论jwt安全性原因,不要用 JWT 取代 Server-side 的 Session状态机制。详情请阅读这篇文章:Stop Using Jwt For Sessions.
Signature第三部分signature用来验证发送请求者身份,由前两部分加密形成。
要创建签名部分,您必须采用编码标头,编码有效载荷,秘钥,标头中指定的算法并签名。
例如,如果你想使用HMAC SHA256算法,签名将按照以下方式创建:
JWT输出的是三个由点分隔的Base64-URL字符串,可以在HTML和HTTP环境中轻松传递,而与基于XML的标准(如SAML)相比,它更加紧凑。
以下JWT示例,它具有先前的标头和有效负载编码,并且使用秘钥进行签名。
我们可以使用jwt.io调试器来解码,验证和生成JWT:
在身份验证中,当用户使用他们的凭证成功登录时,JSON Web Token将被返回并且必须保存在本地(通常在本地存储中,但也可以使用Cookie),而不是在传统方法中创建会话 服务器并返回一个cookie。
关于存储令牌(Token)的方式,必须考虑安全因素。
参考: #Where to Store Tokens#
无论何时用户想要访问受保护的路由或资源,用户代理都应使用承载方案发送JWT,通常在请求头中的Authorization字段,使用Bearer schema:
Authorization: Bearer <token>