|
|
@@ -29,6 +29,7 @@ xxxxx.yyyyy.zzzzz
|
|
|
让我们分解不同的部分。
|
|
|
|
|
|
<b>Header(标头)</b>
|
|
|
+
|
|
|
标头通常由两部分组成：令牌的类型（即JWT）和所使用的签名算法，例如HMAC SHA256或RSA。
|
|
|
|
|
|
例如：
|
|
|
@@ -37,12 +38,13 @@ xxxxx.yyyyy.zzzzz
|
|
|
"alg": "HS256",
|
|
|
"typ": "JWT"
|
|
|
}
|
|
|
-然后，此JSON被Base64Url编码以形成JWT的第一部分。
|
|
|
+然后，此JSON被<b>Base64Url</b>编码以形成JWT的第一部分。
|
|
|
|
|
|
<b>Payload(有效载荷)</b>
|
|
|
+
|
|
|
令牌的第二部分是有效负载，其中包含声明。声明是有关实体（通常是用户）和其他数据的声明。索赔有以下三种类型：注册的，公共的和私人索赔。
|
|
|
|
|
|
-已注册的权利要求：这些是一组非强制性的但建议使用的预定义权利要求，以提供一组有用的，可互操作的权利要求。其中一些是： iss（发布者）， exp（到期时间）， sub（主题）， aud（受众群体）等。
|
|
|
+已注册的权利要求：这些是一组非强制性的但建议使用的预定义权利要求，以提供一组有用的，可互操作的权利要求。其中一些是： <b>iss</b>（发布者）， <b>exp</b>（到期时间）， <b>sub</b>（主题）， <b>aud</b>（受众群体）等。
|
|
|
|
|
|
请注意，声明名称仅是三个字符，因为JWT是紧凑的。
|
|
|
|
|
|
@@ -57,7 +59,7 @@ xxxxx.yyyyy.zzzzz
|
|
|
"name": "John Doe",
|
|
|
"admin": true
|
|
|
}
|
|
|
-然后，对有效负载进行Base64Url编码，以形成JSON Web令牌的第二部分。
|
|
|
+然后，对有效负载进行<b>Base64Url</b>编码，以形成JSON Web令牌的第二部分。
|
|
|
|
|
|
请注意，对于已签名的令牌，此信息尽管可以防止篡改，但任何人都可以读取。除非将其加密，否则请勿将机密信息放入JWT的有效负载或报头元素中。
|
|
|
|
|
|
@@ -92,13 +94,13 @@ HMACSHA256(
|
|
|
|
|
|
由于缺乏安全性，您也不应该将敏感的会话数据存储在浏览器中。
|
|
|
|
|
|
-每当用户想要访问受保护的路由或资源时，用户代理通常应使用承载模式在授权标头中发送JWT 。标头的内容应如下所示：
|
|
|
+每当用户想要访问受保护的路由或资源时，用户代理通常应使用授权<b>Authorization</b>在<b>Bearer</b>承载模式标头中发送JWT 。标头的内容应如下所示：
|
|
|
|
|
|
Authorization: Bearer <token>
|
|
|
|
|
|
-在某些情况下，这可以是无状态授权机制。服务器的受保护路由将在Authorization标头中检查有效的JWT ，如果存在，则将允许用户访问受保护的资源。如果JWT包含必要的数据，则可以减少查询数据库中某些操作的需求，尽管这种情况并非总是如此。
|
|
|
+在某些情况下，这可以是无状态授权机制。服务器的受保护路由将在<b>Authorization</b>标头中检查有效的JWT ，如果存在，则将允许用户访问受保护的资源。如果JWT包含必要的数据，则可以减少查询数据库中某些操作的需求，尽管这种情况并非总是如此。
|
|
|
|
|
|
-如果令牌是在Authorization标头中发送的，则跨域资源共享（CORS）不会成为问题，因为它不使用cookie。
|
|
|
+如果令牌是在<b>Authorization</b>标头中发送的，则跨域资源共享（CORS）不会成为问题，因为它不使用cookie。
|
|
|
|
|
|
下图显示了如何获取JWT并将其用于访问API或资源：
|
|
|
<img src="{{ "/images/jwt/client-credentials-grant.png" | prepend: site.baseurl }}?{{ site.time | date: "%Y%m%d%H%M" }}" alt=""/>
|
shimingxy