简单了解JWT
JWT官方文档:https://jwt.io/introduction
1 、JWT官方定义
JWT(Json Web Token)翻译过来是:JSON网络令牌。
它是一个开放标准 ( RFC 7519 ),它定义了一种紧凑且自包含的方式,用于在各方之间作为 JSON 对象安全地传输信息。该信息可以被验证和信任,因为它是经过数字签名的。JWT 可以使用秘密(使用HMAC算法)或使用RSA或ECDSA的公钥/私钥对进行签名。
尽管 JWT 可以加密以在各方之间提供保密,但我们将重点关注签名令牌。签名令牌可以验证其中包含的声明的完整性,而加密令牌则对其他方隐藏这些声明。
紧凑:尺寸小,用越少的表示信息。
自包含:有效载荷(Playload)包含有关用户的所有必需信息。
2、什么时候使用JWT
- 授权:最常用。用户登录后,每个后续请求都将包含 JWT,允许用户访问该令牌允许的路由、服务和资源。特点是开销小,轻松跨域。
- 信息交换:JTW是一种在各方之间安全传输信息的好方法。因为 JWT 可以被签名——例如,使用公钥/私钥对——你可以确定发件人就是他们所说的那样。此外,由于使用标头和有效负载计算签名,因此您还可以验证内容是否未被篡改。
3、JWT结构
在其紧凑形式中,JSON Web Tokens 由用点 ( .
)分隔的三个部分组成,它们是:
- Header 标题
- Payload 有效载荷
- signature 签名
因此,JWT 通常如下所示。
xxxxx.yyyyy.zzzzz
JWT第一部分:Header
Header 通常由两部分组成:令牌的类型,即 JWT,以及正在使用的签名算法,例如 HMAC SHA256 或 RSA。
例如:
{
"alg": "HS256",
"typ": "JWT"
}
然后,这个 JSON 被Base64Url编码以形成 JWT 的第一部分。
**JWT第二部分:Payload **
令牌的第二部分是负载,其中包含声明。声明是关于实体(通常是用户)和附加数据的声明。共有三种类型的声明:注册声明、公共声明和私人声明。
-
注册声明:这些是一组预定义的声明,这些声明不是强制性的,而是推荐的,以提供一组有用的、可互操作的声明。其中一些是: iss(发行者)、 exp(到期时间)、 sub(主题)、 aud(受众)等。
请注意,声明名称只有三个字符,因为 JWT 是紧凑的。
-
公共声明:这些可以由使用 JWT 的人随意定义。但是为了避免冲突,它们应该在IANA JSON Web Token Registry中定义或定义为包含抗冲突命名空间的 URI。
-
私人权利:这些都是使用它们同意并既不是当事人之间建立共享信息的自定义声明注册或公众的权利要求。
一个示例有效载荷可能是:
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
然后对有效负载进行Base64Url编码以形成 JSON Web 令牌的第二部分。
请注意,对于已签名的令牌,此信息虽然受到防篡改保护,但任何人都可以读取。除非加密,否则不要将机密信息放在 JWT 的负载或标头元素中。
所以不要将重要的信息,比如密码,放到payload中。
**JWT第三部分:Signature **
要创建签名部分,您必须获取编码的标头、编码的有效载荷、秘密、标头中指定的算法,并对其进行签名。
例如,如果要使用 HMAC SHA256 算法,则签名将通过以下方式创建:
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
签名用于验证消息在此过程中没有更改,并且在使用私钥签名的令牌的情况下,它还可以验证 JWT 的发送者是它所说的那个人。
4、一个JWT
输出是三个由点分隔的 Base64-URL 字符串,可以在 HTML 和 HTTP 环境中轻松传递,同时与基于 XML 的标准(如 SAML)相比更加紧凑。
下面显示了一个 JWT,它对前面的标头和有效负载进行了编码,并使用机密进行了签名。
5、JWT是怎么工作的
大白话,就是说,用户通过账号密码进行登录,服务器验证成功后,生成一个token令牌返回,用户保存好token,在token有效期间,访问时,将token放到请求头中,服务器进行验证,确保能否访问。
在身份验证中,当用户使用其凭据成功登录时,将返回 JSON Web Token。由于令牌是凭证,因此必须非常小心以防止出现安全问题。通常,您不应将令牌保留的时间超过所需的时间。
关于存储令牌(Token)的方式,必须考虑安全因素。
每当用户想要访问受保护的路由或资源时,用户代理应该发送 JWT,通常在使用Bearer模式的Authorization标头中。标题的内容应如下所示:
Authorization: Bearer <token>
在某些情况下,这可以是无状态授权机制。服务器的受保护路由将检查Authorization
标头中的有效 JWT ,如果存在,则用户将被允许访问受保护的资源。如果 JWT 包含必要的数据,则可能会减少为某些操作查询数据库的需要,尽管情况并非总是如此。
如果令牌在Authorization
标头中发送,跨源资源共享 (CORS) 不会成为问题,因为它不使用 cookie。
请注意,使用签名令牌,令牌中包含的所有信息都会暴露给用户或其他方,即使他们无法更改它。这意味着您不应将秘密信息放入令牌中。