全栈项目|小书架|服务器开发-JWT 详解
JWT
文章基本是官网内容的翻译,英文不错的同学可点击上面的链接直接看英文文档。
什么是 JWT
JWT
全称是JSON Web Token(JWT)
是一个开放标准(RFC 7519)
,它定义了一种紧凑且自包含的方式,用于在各方之间作为JSON
对象安全地传输信息。由于此信息是经过数字签名的,因此可以被验证和信任。
可以使用密钥(HMAC算法
)或使用RSA
或ECDSA
的公用/专用密钥对对JWT
进行签名。
什么时候使用 JWT 验证
- 授权
(Authorization)
这是使用JWT
的最常见情况。一旦用户登录,每个后续请求将包括JWT
,从而允许用户访问该令牌允许的路由,服务和资源。单一登录是当今广泛使用JWT
的一项功能,因为它的开销很小并且可以在不同的域中轻松使用。 - 信息交换
(Information Exchange)
JWT
是在各方之间安全地传输信息的好方法。因为可以对JWT
进行签名(例如,使用公钥/私钥对),所以您可以确保发件人是他们所说的人。另外,由于签名是使用Header
和payload
计算的,因此您还可以验证内容是否未被篡改。
JWT 的结构格式
由三部分组成,这些部分由点.
分隔,分别是:
Header
Payload
Signature
因此,JWT
通常如下所示。
xxxxx.yyyyy.zzzzz
Header
通常由两部分组成:
例如:
{
"alg": "HS256",
"typ": "JWT"
}
然后,将此JSON
通过Base64Url
编码以形成JWT
的第一部分。
Payload
令牌的第二部分是有效负载
,其中包含声明。声明是有关实体(通常是用户)和其他数据的声明。共有三种类型的索赔: registered、public、private claims
-
Registered claims
这些是一组预定义的权利要求,不是强制性的,而是建议使用的,以提供一组有用的可互操作的权利要求。其中一些是:iss
(发出者),exp
(到期时间),sub
(主题),aud
(受众) 等。
Tip: 请注意,声明名称仅是三个字符,因为JWT
是紧凑的。 -
Public claims
这些可以由使用JWT
的人员随意定义。但是为避免冲突,应在IANA JSON Web
令牌注册表中定义它们,或将其定义为包含抗冲突名称空间的URI
。 -
Private claims
这些是自定义声明,旨在在同意使用它们的各方之间共享信息,既不是注册声明也不是公共声明。
有效负载示例:
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
同样需要Base64Url
编码,以形成JWT
的第二部分。
Signature
签名(Signature)
用于验证消息在整个过程中没有更改,并且对于使用私钥进行签名的令牌,它还可以验证JWT
的发送者是它所说的真实身份。
例如,如果要使用HMAC SHA256
算法,则将通过以下方式创建签名:
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
将这三部分合并
输出是三个由.
分隔的Base64-URL
字符串,可以在HTML
和HTTP
环境中轻松传递这些字符串,与基于XML
的标准(例如SAML
)相比,它更紧凑。
下图显示了一个JWT
,它已对先前的Header
和Payload
进行了编码,并用一个Signature
。
可以在这个网页 jwt.io Debugger 验证和生成JWT
JWT 如何工作
在身份验证中,当用户使用其凭据成功登录时,将返回令牌。由于令牌是凭据,因此必须格外小心以防止安全问题。通常,令牌的有效时间不宜设置过长。
Tip: 由于缺乏安全性,您也不应该将敏感的会话数据存储在浏览器存储中。
每当用户想要访问受保护的路由或资源时,用户代理通常应在Bearer
模式中使用授权头发送JWT
。Header
的内容应如下所示:
Authorization: Bearer <token>
在某些情况下,接口访问并不需要身份授权。服务器的受保护路由将在Authorization Header
中检查JWT令牌
是否有效,如果存在且有效,则将允许用户访问受保护的资源。
如果JWT
包含必要的数据,则可以减少查询数据库中某些操作的需求。
如果令牌是在Authorization Header
中发送的,则跨域资源共享 (CORS) 不会成为问题,因为它不使用cookie
。
下图显示了如何获取JWT
并将其用于访问API或资源
:
- 应用程序或客户端向授权服务器请求授权。生产
JWT令牌
。 - 授予授权后,授权服务器会将访问令牌返回给应用程序。
- 应用程序使用访问令牌来访问受保护的资源(例如API)。
- 服务器检查
JWT令牌
是否有效,返回对应结果给客户端
下图详细的流程:
ps:请注意,使用签名令牌,令牌或令牌中包含的所有信息都会暴露给用户或其他方,即使他们无法更改它。这意味着您不应将机密信息放入令牌中。
为什么需要 JWT
对比 Simple Web Tokens (SWT) 和Security Assertion Markup Language Tokens (SAML),看看使用JSON Web Tokens (JWT) 有什么好处。
- 由于
JSON
不如XML
冗长,因此在编码时JSON
的大小也较小,从而使JWT
比SAML
更紧凑。这使得JWT
是在HTML
和HTTP环境
中传递的不错的选择。 - 在安全方面,
SWT
只能使用HMAC算法
进行对称签名。但是JWT
和SAML令牌
可以使用X.509证书形式
的公用/专用密钥对进行签名。与签名JSON
的简单性相比,使用XML Digital Signature
签名XML
而不引入模糊的安全漏洞是非常困难的。 -
JSON
解析器在大多数编程语言中都很常见,因为它们直接映射到对象。相反,XML
没有自然的文档到对象映射。与SAML
断言相比,这使使用JWT
更加容易。 - 关于用法,
JWT
是在Internet
规模上使用的。这强调了在多个平台(尤其是移动平台)上对JSON Web令牌
进行客户端处理的简便性。
如果您想了解有关JSON Web令牌的更多信息,甚至开始使用它们在自己的应用程序中执行身份验证,请浏览到 Auth0上的JSON Web令牌登录 页面。
咨询请加微信:轻撩即可。