JWT(Json Web Token)简介

什么是JWT?

JSON Web Token(JWT)是一个开放的标准(RFC 7519),该标准定义了一个在两者之间安全的使用 JSON 对象传递信息的方式,这种方式紧凑并且自成一体。这个信息可以被验证和信任因为它是一种数字签名。JWTs 可以通过使用密匙(用哈希算法)或者用 RSA 加密算法的公私密匙签署。

  • 紧凑:因为它的大小,它可以通过一个 URL、POST 参数、或者放在 HTTP 头部 进行发送。另外它的大小可以使其传播迅速。
  • 自成一体:这个载体(payload)包含所有的用户请求信息,避免频繁的查询数据库。

应该在什么时候使用 JWT?

这里有一些使用 JSON Web Tokens 的场景:

  • 登陆验证:这是使用 JWT 的典型场景,一旦用户登录之后,每个后续的请求将包含 JWT,通过这个令牌允许用户访问路由、服务和资源。单点登录现在被广泛使用,因为它的开销很小,并且它能够很容易地使用在不同领域的系统之间。
  • 信息交流:JSON Web Token 是在不同部分传递信息的好方法,因为它们可以被签署,例如使用 public/private key,可以确定的是发送者是谁。另外,签名是使用 Header(头部)和 Payload(载荷)计算得出的,可以验证内容没有发生改变。

JWT 的结构?

JSON Web Tokens 由三个部分组成并使用(.)作为间隔:

  • Header
  • Payload
  • Signature
    因此,一个 JWT 通常看起来像下面这样:
    xxxxx.yyyyy.zzzzz

让我们分解这几部分。

头部由两部分组成:token 的类型:JWT,加密算法:如 HMAC SHA256 或 RSA。
例如:

1
2
3
4
{
"alg": "HS256",
"typ": "JWT"
}

然后,这个 JSON 被使用 Base64Url 编码形成 JWT 的第一部分。

Payload

token 的第二部分是载体(payload),载体包含一些声明(claims)。这些声明包含一个实体(特点,用户)和附加的数据。声明(claims)有三种类型:reserved,public,private。

  • Reserved claims:这是一组预定义的声明,建议这个声明但不强制要求,这里提供了一组有用的、能共用的声明。例如:iss(issuer),exp(expiration time),sub(subject),aud (audience)等等。
    注意:这些声明的名字只有 3 个字,因为 JWT 是紧凑的
  • Public claims:这些可以通过 JWTs 随意定义。但为了避免冲突,他们应该使用 IANA JSON Web Token Registry 定义或使用 URL 定义。
  • Private claims:这是为了双方同意分享数据创建的自定义声明。
    例子:
1
2
3
4
5
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}

然后,这个 JSON 被使用 Base64Url 编码形成 JWT 的第二部分。

Signature

要创建签名部分,你必须提供 Header 编码、Payload 编码、密匙,在首部指定算法。
例如:如果你想使用 HMAC SHA256 算法, 签名将以下面的方式进行创建:

1
2
3
4
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)

签名被用于验证 JWT 中的发送者是谁,并确保信息在传输途中没有发生改变。

把三部分组合起来

输出三个用点分割开的 Base64 编码的字符串,可以很容易在 HTML 和 HTTP 环境中使用,与像 SAML 这种基于 XML-based 的标准更加紧凑。
下面展示了一个 JWT。

如果你想使用 JWT 并实践这些概念,你可以使用 jwt.io Debugger 进行解码、验证并生成 JWTs。

JWT 是怎么工作的?

在身份验证中,当用户成功的使用他的凭证登录后,服务器将返回一个 JSON Web Token,保存到本地(通常存储在 local storage,但也可以使用 cookies)。而不是像传统方法那样,在服务器上创建一个 session,返回cookie。

当用户想访问一个受保护的路由或资源时,应该使用 JWT,通常在 Authorization header 使用 Bearer schema。因此头部的内容应该像下面这样。

1
Authorization: Bearer <token>

这是一个无状态的验证机制,因为用户的状态不保存在服务器中。服务器中受保护的路由,会检查在 Authorization header 是否有一个有效的 JWT,如果有的话,用户会被允许通过。JWTs 是自成一体的,包含了所有的必要的信息,减少了返回信息和转发到数据库的必要。

这允许完全依赖数据 API,它是无状态的并且甚至可以发送请求到下游服务。它不关心是哪个域在使用你的 APIs,跨域资源共享(CORS)将不再是一个问题,因为它不使用 cookies。

下图显示了这个过程:

为什么要使用 JWT?

我们谈谈 JSON Web Tokens(JWT)的好处,并与 Simple Web Tokens (SWT)Security Assertion Markup Language Tokens (SAML) 进行对比。

由于 JSON 比 XML 更简洁,当它被编码之后它的体积更小,使得 JWT 与 SAML 相比更紧凑。在 HTML 和 HTTP 环境中进行传递时,JWT 是一个好的选择。

JSON 解析器在大多数编程语言常见的,因为它们直接映射为对象,反之 XML 不能直接进行文件到对象的映射。这使得 JWT 比 SAML 更容易声明。

至于作用范围,JWT 适用于大规模的互联网范围。突出展现了其跨平台的易用性,尤其是在移动设备上的应用。

JWT 和 SAML 编码后的长度的比较

如果你想了解更多 JSON Web Tokens 并开始在你的应用中使用它们进行认证,打开在 Auth0 的 JSON Web Token landing page

相关

0%