JWT规范及使用

JWT结构

JWT由三部分组成：

• Header
• Payload
• Signature

JWT通常如下所示：

xxxxx.yyyyy.zzzzz

JWT结构部分说明

Header

报头通常由两部分组成：TOKEN的类型，即JWT，以及所使用的签名算法，如HMAC SHA256或RSA。

例如：

{ "alg": "HS256", "typ": "JWT" }

然后，该JSON是Base64Url编码的，以形成JWT的第一部分。

Payload

TOKEN的第二部分为payload，它包含声明。声明是关于实体(通常是用户)和附加数据的声明。

有三种类型的声明：注册声明（registered）、公有声明（public）和私有声明（private ）。

注册声明（registered）

这些是一组预定义的声明，它们不是强制性的，而是推荐的，以提供一组有用的、可互操作的声明要求。其中包括:iss(发行人)、exp(到期时间)、sub(主题)、aud(受众)等。

更多的声明请查阅：https://tools.ietf.org/html/rfc7519#section-4.1

注意：声明名只有三个字符长，因为JWT是为了紧凑。

公有声明（public）

这些可以由使用JWTs的人随意定义。但是为了避免冲突，应该在IANA JSON Web令牌注册表中定义它们，或者将它们定义为包含抗冲突名称空间的URI。

私有声明（private ）

这些自定义索赔是为了在同意使用它们的各方之间共享信息而创建的，它们既不是注册的，也不是公开的声明。

举个例子，payload可以是这样的：

{ "sub": "1234567890", "name": "John Doe", "admin": true }

然后，该JSON是Base64Url编码的，以形成JWT的第二部分。

 

请注意，对于已签名的令牌，该信息虽然受到保护，不会被篡改，但任何人都可以读懂。不要将机密信息放在JWT的有效负载或头元素中，除非它被加密了。

Signature

要创建签名部分，您必须获取已编码的header、已编码的payload、一个密钥、头中指定的算法，并对其进行签名。

例如，使用HMAC SHA256算法时，签名的生成方式如下：

HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

签名用于验证消息在整个过程中没有被更改，而且，在使用私钥签名的令牌的情况下，它还可以验证JWT的发送方是它所声称的那个人。

 

将这三部分结构放在一起

输出是三个用点分隔的Base64-URL字符串，它们可以很容易地在HTML和HTTP环境中传递，同时与基于xml的标准(如SAML)相比更紧凑。

下面展示了一个JWT，它对前面的头和有效负载进行了编码，并使用secret对其进行了签名。

 

 如果您想使用JWT并将这些概念付诸实践，可以使用JWT。解码、验证和生成JWTs的io调试器。

https://jwt.io/#debugger-io

JWT是如何工作的

在身份验证中，当用户使用他们的凭据成功登录时，将返回一个JSON Web令牌。由于令牌是凭据，必须非常小心地防止安全问题。一般来说，您不应该保存token超过要求的时间。

由于缺乏安全性，您也不应该在浏览器存储中存储敏感会话数据。

当用户希望访问受保护的路由或资源时，用户代理应该发送JWT，通常在授权头中使用承载模式。头文件的内容应该如下所示：

Authorization: Bearer <token>

在某些情况下，这可以是一种无状态授权机制。服务器受保护的路由将在授权报头中检查有效的JWT，如果存在，则允许用户访问受保护的资源。如果JWT包含必要的数据，则可能减少对数据库查询某些操作的需求，尽管情况可能并不总是这样。

如果令牌是在授权头中发送的，那么跨源资源共享(CORS)就不是问题，因为它不使用cookie。

下面的图表显示了JWT是如何被获取和使用来访问api或资源的：

 

1. 应用程序或客户机向授权服务器请求授权。这是通过一个不同的授权流执行的。例如，一个典型的OpenID Connect兼容的web应用程序将使用授权代码流通过/oauth/authorize端点。
2. 授予授权后，授权服务器向应用程序返回一个访问令牌（TOKEN）。
3. 应用程序使用访问令牌访问受保护的资源(如API)。

请注意，对于已签名的令牌，令牌中包含的所有信息都将暴露给用户或其他各方，即使他们无法更改它。这意味着您不应该在令牌中放置秘密信息。

我们为什么要使用JWT

让我们来谈谈与简单Web令牌(SWT)和安全断言标记语言令牌(SAML)相比，JSON Web令牌(JWT)的好处。

由于JSON比XML更简洁，因此在编码时它的大小也更小，这使得JWT比SAML更紧凑。这使得JWT成为在HTML和HTTP环境中传递的良好选择。

在安全方面，SWT只能通过使用HMAC算法的共享秘密进行对称签名。但是，JWT和SAML令牌可以使用X.509证书形式的公钥/私钥对进行签名。与签名JSON的简单性相比，使用XML数字签名在不引入隐蔽的安全漏洞的情况下签名XML是非常困难的。

JSON解析器在大多数编程语言中都很常见，因为它们直接映射到对象。相反，XML没有自然的文档到对象映射。这使得使用JWT比使用SAML断言更容易。

关于使用，JWT是在互联网规模上使用的。这突出了JSON Web令牌在多个平台上(尤其是移动平台)客户端处理的易用性。

 

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