在澄清了一些想法之后，这个问题更侧重于正确使用JWT .
设's talk about only encoded (not encrypted) JWTs, and let'仅考虑使用对称密钥的 HMAC ，让我们称之为 p@$$w0rd ，它将用于签署JWT .
We know that JWTs should not contain sensitive information as they do not hide any data as payload is only Base64 encoded, they are only supposed to verify through the signature that information is coming from correct client.
在我们的例子中，我们发送 role 是为了显示/隐藏Web应用程序中的某些元素 .
在具有 admin 角色的用户中，将看到创建/修改/删除用户等的链接作为示例 .
Scenario
A - > admin 用户，在登录时从服务器（颁发者）请求JWT
Server - >向JWT提出 userID ， userName ， role 的索赔，并附有截止日期 .
A - >应该在对 server 的所有进一步API请求时发送此JWT令牌，服务器将使用此令牌进行身份验证 .
B - >是非管理员用户，并遵循相同的过程 .
B 知道 A 是管理员用户，并且知道它也是 userID 和 userName . 这很有可能，没有敏感信息 .
JWT仅声明Base64编码，如果客户端也知道 secret p@$$w0rd ，则客户端可以轻松生成令牌 . 我们知道验证程序 server 只重新编码已编码的JWT（来自客户端）以匹配它使用秘密发送的 upon login .
通过 https ，我们可以确定第三方或中间的人无法知道这个秘密或任何其他信息，所以让我们把它放在一边 .
#1
B 是恶意用户修改它自己的令牌并将角色更改为 admin 的角色，并且只允许管理员用户进行API调用 .
Server 可以轻易地使此令牌无效，因为重新散列将失败，因为发送到 B 的原始令牌已被修改，当我们修改令牌时，签名也会因为有效负载而改变 .
#2
B 是恶意用户创建一个令牌以匹配 A 的令牌与 A 的所有详细信息，并且只允许管理员用户使用API请求 .
server 将成功验证该令牌并且知道它是 A .
How to prevent this?
-
我们是否应该使用
id声明作为有效载荷的一部分，这是唯一且不容易猜到的？由于这个B无法导出正确的声明集来创建确切的A标记 . 虽然这种方法更多地涉及为每个用户存储这个额外的ID并在服务器上进行身份验证 . -
我们是否应该透露用于签署JWT的
secret密钥，所以
客户端可以创建令牌吗？
我们知道，与 Basic Authorization 相比，JWT肯定是一种更好的身份验证方式， Basic Authorization 也会在每个具有更大攻击窗口的API请求中发送用户的Base64编码 password .
1 回答
选项＃2 - 如果客户端以任何方式不安全，如果客户端是Web应用程序，则永远不要将对称密钥公开给客户端 . 不要给出对称密钥是个好主意 . JWT应该在服务器上制造，即用对称密钥预先签名，然后提供给客户端 . 客户端可以通过某种形式的身份验证通过安全API请求JWT，或者您可以通过其他方式创建JWT并向客户端发送 .
我们两个都做 . 已经过身份验证的域用户可以通过API调用请求到期的JWT . 域外的用户可以通过可以访问API调用的域上的已批准管理员专门为他们提供JWT . 在任何时候都没有露出对称键 .
此过程开始复制OAuth的某些方面，因此您可能需要调查OAuth服务器/供应商，这就是我们要去的地方 .