我确信我在这里错过了一些非常简单的东西，但我刚刚开始学习JWT令牌的认证，据我所知，JWT令牌的结构是。
Base64UrlEncode(Header) + '.' + Base64UrlEncode(Payload) + '.' + CreateSignature(Header, Payload, Secret_Key)
我的理解是你把这个发给客户端 它允许客户端在需要的时候把这个发给服务器 这时你要解密Signature，以确保它没有被人用你的私钥篡改过。
我感到困惑的部分是为什么你需要第一部分的 Base64UrlEncode(Header) + '.' + Base64UrlEncode(Payload) + '.' 很容易被转换为明文，那么？
既然你要在服务器上解密，你就不能只传递签名，用你的密匙解密，然后读取有效载荷，而其他人则不能？
这似乎是比较安全的，因为第一部分可以很容易地转换回纯文本，并给攻击者提供信息，如 token expiration, userId 和类似的，存储在有效载荷中。
我错过了什么？
签名不包含有效载荷。签名可以是简单的jwt的哈希值（SHA256）的消息验证码（HMAC）。因此，如果你只发送签名，那将作为一个普通的会话id工作，服务器仍然必须存储状态，否定了jwt的任何好处。
你是对的，默认情况下jwt是不加密的。虽然用base64编码，但从安全角度来看，它只是纯文本，不应该包含敏感（秘密）信息。签名提供的唯一保护是，当服务器收到回传的信息时，它可以通过检查签名来确保jwt中的信息没有在客户端被修改。
未加密的令牌允许客户端检查其内容，并计算出到期时间、何时需要获取新的令牌或登录用户的ID。拥有jwt的用户无论如何都会有这样的信息，其他人是不应该拥有jwt的，因为他们可以利用jwt进行认证，冒充用户。
然而，在特殊情况下，你可能仍然希望包含敏感信息（即秘密），你想在服务器上接收回来，但不想透露给客户端。为此，您可以使用加密的jwt（jwe）。缺点是这个令牌对客户端来说是不透明的，你可能不得不实现应用端点来检索所有必要的信息。