JSON Web Tokens 由使用 (.
) 分开的 3 个部分组成的,这 3 个部分分别是:
正是因为上面的组织形式,因此一个 JWT 通常看起如下面的表现形式。
xxxxx.yyyyy.zzzzz
让我们针对上面的形式来具体的分析下。
在头部的数据中 通常 包含有 2 部分的内容:token 的类型,这里使用的是字符 JWT,和使用的的签名加密算法,例如 SHA256 或者 RSA。
例如下面的格式:
{
"alg": "HS256",
"typ": "JWT"
}
然后,将上面的 JSON 数据格式使用 Base64Url 算法进行哈希,这样你就得到了 JWT 的第一部分。
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
}
中的数据也是经过 Base64Url 进行加密的,这部分加密的内容组成了 JWT 的第二部分。
请注意:针对令牌这部分的签名已经被防范篡改。但是这部分还是可以被解密的,因此请不要将任何秘钥放到这部分的数据中,除非你的秘钥是已经加密过的秘钥。
为了创建一个加密部分,你需要有已经编码过的头部和负载,然后你还需要一个秘钥(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 令牌。
网站声明:如果转载,请联系本站管理员。否则一切后果自行承担。
添加我为好友,拉您入交流群!
请使用微信扫一扫!