乐趣区

关于jwt:JSON-Web-Token-的结构是什么

jiezi

JSON Web Tokens 由应用 (.) 离开的 3 个局部组成的，这 3 个局部别离是：

  • 头部（Header）
  • 负载（Payload）
  • 签名（Signature）

正是因为下面的组织模式，因而一个 JWT 通常看起如上面的表现形式。

xxxxx.yyyyy.zzzzz

让咱们针对下面的模式来具体的剖析下。

头部（Header）

在头部的数据中 _通常_ 蕴含有 2 局部的内容：token 的类型，这里应用的是字符 JWT，和应用的的签名加密算法，例如 SHA256 或者 RSA。

例如上面的格局：

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

而后，将下面的 JSON 数据格式应用 Base64Url 算法进行哈希，这样你就失去了 JWT 的第一局部。

负载（Payload）

JWT 的第二局部为负载，在负载中是由一些 claims 组成的。Claims 是一些实体（通常指用户）和其余的一一些信息。

有上面 3 种类型的 claims _registered_，_public_ 和 _private_。

Registered claims：这些 claims 是事后定义的，这些配置的内容不是必须的然而是举荐应用的，因而提供了一系列约定俗成应用的。比方：iss（issuer），exp（expiration time）, sub（subject），aud（audience）和其余的一些更多的配置。

请留神，这些约定俗称的配置只有 3 个字符，以便于压缩数据量。

Public claims：这些数据能够由应用 JWT 的用户自在去定义，然而为了防止抵触，你须要参考在 IANA JSON Web Token Registry 中对它们进行定义，或者将这些内容定义为 URI，并且须要防止可能呈现的抵触。

Private claims：这些内容是自定义的内容，这部分的内容被用于在数据传输短间进行转换的数据。这些数据是没有在 registered 和 public 两头没有定义的内容。

一个示例的负载：

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

负载（payload）

中的数据也是通过 Base64Url 进行加密的，这部分加密的内容组成了 JWT 的第二局部。

请留神：针对令牌这部分的签名曾经被防备篡改。然而这部分还是能够被解密的，因而请不要将任何秘钥放到这部分的数据中，除非你的秘钥是曾经加密过的秘钥。

签名（Signature）

为了创立一个加密局部，你须要有曾经编码过的头部和负载，而后你还须要一个秘钥（secret）和一个曾经在头部中指定的加密算法来进行签名。

例如，如果你心愿应用 HMAC SHA256 算法来进行签名，那么这个算法中应用的数据为：

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

签名的作用次要用于校验传输的令牌（Token）数据没有在过程中被篡改。

如果你的令牌是通过公有秘钥进行签名的，那么也能够对 JWT 进行校验，以确定 JWT 的发送方应用是非法的签名。

将所有内容整合在一起

将这个 3 局部的内容应用 Base64-URL 编码后整合到一起，将每局部的数据间接应用 点号（.）进行分隔，以确保令牌数据可能比拟容易的在网络 HTTP 和 HTML 环境中进行传输。

针对应用 XML 的令牌，例如 SAML 来说，JWT 显得更加简洁和高效。

上面是应用了头部信息，负载信息和数字签名而后组合到一起的一个 JWT 令牌示例：

如果你想应用 JWT，并且对一个已有的 JWT 令牌进行解密的话，你可用应用 https://jwt.io/#debugger-io 网站上提供的工具来对 JWT 字符串进行节目，校验和生产一个 JWT 令牌。

https://www.ossez.com/t/json-web-token/531

退出移动版