JWT 简介(JSON Web Token)【译】
前言
最近在做api鉴权的时候了解到了jwt这个标准协议,非常适合用来做鉴权介质,刚好在jwt.io 网站上就有对jwt的权威简介,这里对原文使用浏览器进行机翻,再人工修改了一些翻译错误并进行适当精简,留作日后回顾。
什么是JSON Web Token?
JSON Web Token(JWT)是一个开放标准(RFC 7519),它定义了一种紧凑且独立的方式,用于在各方之间作为JSON对象安全地传输信息。此信息可以通过数字签名进行验证和信任。JWT可以使用使用HMAC算法或使用RSA或ECDSA的公钥/私钥对进行签名。
虽然JWT可以加密以在各方之间提供保密,但我们这里只讲签名令牌。签名令牌可以验证其中包含的声明的完整性,而加密令牌则隐藏其他方的声明。当使用公钥/私钥对签名令牌时,签名还证明只有持有私钥的一方是签署它的一方。
什么时候应该使用JSON Web Token?
以下是JSON Web令牌有用的一些场景:
授权:这是使用JWT的最常见方案。一旦用户登录,每个后续请求将包含JWT,允许用户访问该令牌允许的路由、服务和资源。Single Sign On是一种现在广泛使用JWT的功能,因为它的开销很小,并且能够在不同的域名中轻松使用(跨域)。
信息交换:JSON Web令牌是在各方之间安全传输信息的好方法。因为JWT可以被签名,例如,使用公钥/私钥对你可以确定发件人的真实性。此外,由于使用header 和 payload 计算签名,你还可以验证内容是否未被篡改。
什么是JSON Web令牌结构?
在紧凑的形式中,JSON Web Tokens由点(.)分隔的三个部分组成,它们是:
- Header (头)
- Payload (负载)
- Signature (签名)
因此,JWT通常如下所示。
xxxxx.yyyyy.zzzzz
让我们分解不同的部分。
(头部)Header
Header 通常由两部分组成:令牌的类型,即JWT,以及正在使用的签名算法,例如HMAC SHA256或RSA。
例如:
{
"alg": "HS256",
"typ": "JWT"
}
然后,这个JSON被编码为 Base64Url,形成 JWT 的第一部分。
Payload
令牌的第二部分是 Payload,其中包含 claims(声明)。claims 是关于实体(通常是用户)和其他数据的声明。claims 有三种类型:已注册,公开和私人 claims。
已注册的声明:这些是一组预定义声明,不是强制性的,但建议使用,以提供一组有用的,可互操作的声明。其中一些是: iss(签发者), exp(到期时间),sub(主题), aud(读者)等等。
请注意,声明名称只有三个字符,因为 JWT 追求紧凑。
公开声明:这些可以由使用JWT的人随意定义。但为避免冲突,应到 IANA JSON Web Token Registry 中定义它们,或者将其定义为包含防冲突命名空间的URI。
私有声明:可以创建自定义的声明用于在多方之间共享信息。
示例有效负载可以是:
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
然后,有效负载经过Base64Url编码,形成JSON Web令牌的第二部分。
请注意,对于签名令牌,此信息虽然可以防止被篡改,但任何人都可以读取。除非加密,否则不要将秘密信息放在JWT的Payload或Header中。
Signature
要创建签名部分,你必须使用编码过的Header和Payload还有Header指定的算法,并它们进行签名。
例如,如果要使用HMAC SHA256算法,将按以下方式创建签名:
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
签名用于验证消息在此过程中未被更改,并且,在使用私钥签名的令牌的情况下,它还可以验证JWT的发件人是否是它所声明的人。
整合三个部分
最终输出的是三个由点(.)分隔的Base64-URL字符串,可以在HTML和HTTP环境中轻松传递,而与基于XML的标准(如SAML)相比更加紧凑。
下面显示了一个JWT。
如果你想使用JWT并将这些概念付诸实践,你可以使用jwt.io Debugger来解码,验证和生成JWT。
JSON Web令牌如何工作?
在身份验证中,当用户使用其凭据成功登录时,将返回JSON Web Token。由于令牌是凭证,因此必须非常小心以防止出现安全问题。一般情况下,你不应该让令牌保留的时间过久。
每当用户想要访问受保护的路由或资源时,用户代理通常应该使用Authorization头发送JWT。如下所示:
Authorization: Bearer <token>
这在一些场景中可以实现无状态授权机制。服务器的受保护路由将检查Authorization标头中的有效JWT ,如果存在,则允许用户访问受保护资源。如果JWT包含必要的数据,则可以减少查询数据库以进行某些操作的需要。
如果在Authorization头中发送令牌,则跨域资源共享(CORS)将不会成为问题,因为它不使用cookie。
下图显示了如何获取JWT并用于访问API或资源:
- 应用程序或客户端向授权服务器请求授权。
- 授予授权后,授权服务器会向应用程序返回访问令牌。
- 应用程序使用访问令牌来访问受保护资源(如API)。
请注意,使用签名令牌,令牌中包含的所有信息都会向用户或其他方公开,即使他们无法更改。这意味着你不应该在令牌中放置秘密信息。