我不是密码学专家，因此(我希望)我的回答可以帮助那些既不是密码学专家的人。

在编程中使用密码学有两种可能的方式:

签署/验证 加密/解密

当我们希望确保数据来自可信来源时，我们使用签名。 当我们想要保护数据时，我们使用加密。

签名/验证使用非对称算法，即我们使用一个密钥(私有)进行签名，而数据接收者使用另一个(公共)密钥进行验证。

对称算法使用相同的密钥对数据进行加密和解密。

加密可以使用对称和非对称算法。 相对简单的文章主题

以上是常识，以下是我的观点。

当JWT用于简单的客户端到服务器标识时，不需要签名或非对称加密。JWT可以使用AES加密，这是快速和超级安全的。如果服务器可以解密它，这意味着服务器是加密它的人。

总结:未加密的JWT是不安全的。在没有第三方参与的情况下，可以使用对称加密来代替签名。

只有服务器上的JWT的privateKey才能解密加密的JWT。那些知道privateKey的人将能够解密加密的JWT。

将私钥隐藏在服务器的安全位置，并且永远不要告诉任何人私钥。

json web令牌(JWT)中的内容本质上并不安全，但有一个内置的功能用于验证令牌的真实性。JWT是用句点分隔的三个散列。第三个是签名。在公钥/私钥系统中，颁发者使用私钥签署令牌签名，该私钥只能由其对应的公钥验证。

理解发布者和验证者之间的区别是很重要的。令牌的接收者负责验证它。

There are two critical steps in using JWT securely in a web application: 1) send them over an encrypted channel, and 2) verify the signature immediately upon receiving it. The asymmetric nature of public key cryptography makes JWT signature verification possible. A public key verifies a JWT was signed by its matching private key. No other combination of keys can do this verification, thus preventing impersonation attempts. Follow these two steps and we can guarantee with mathematical certainty the authenticity of a JWT.

更多阅读:公钥如何验证签名?

我不是密码学专家，因此(我希望)我的回答可以帮助那些既不是密码学专家的人。

在编程中使用密码学有两种可能的方式:

签署/验证 加密/解密

当我们希望确保数据来自可信来源时，我们使用签名。 当我们想要保护数据时，我们使用加密。

签名/验证使用非对称算法，即我们使用一个密钥(私有)进行签名，而数据接收者使用另一个(公共)密钥进行验证。

对称算法使用相同的密钥对数据进行加密和解密。

加密可以使用对称和非对称算法。 相对简单的文章主题

以上是常识，以下是我的观点。

当JWT用于简单的客户端到服务器标识时，不需要签名或非对称加密。JWT可以使用AES加密，这是快速和超级安全的。如果服务器可以解密它，这意味着服务器是加密它的人。

总结:未加密的JWT是不安全的。在没有第三方参与的情况下，可以使用对称加密来代替签名。

让我们从头开始讨论:

JWT is a very modern, simple and secure approach which extends for Json Web Tokens. Json Web Tokens are a stateless solution for authentication. So there is no need to store any session state on the server, which of course is perfect for restful APIs. Restful APIs should always be stateless, and the most widely used alternative to authentication with JWTs is to just store the user's log-in state on the server using sessions. But then of course does not follow the principle that says that restful APIs should be stateless and that's why solutions like JWT became popular and effective.

现在让我们来了解一下Json Web Tokens的身份验证是如何工作的。假设我们的数据库中已经有一个注册用户。因此，用户的客户端首先发出带有用户名和密码的post请求，然后应用程序检查用户是否存在，如果密码正确，那么应用程序将仅为该用户生成一个唯一的Json Web Token。

令牌是使用存储在服务器上的秘密字符串创建的。接下来，服务器将JWT发送回客户端，客户端将其存储在cookie或本地存储中。

就像这样，用户通过身份验证并登录到我们的应用程序，而不会在服务器上留下任何状态。

所以服务器实际上不知道哪个用户实际登录了，但当然，用户知道他已经登录了，因为他有一个有效的Json Web Token，这有点像护照，可以访问应用程序的受保护部分。

再一次，为了确保你们理解了。一个用户一旦得到他唯一有效的Json Web令牌就登录了，这个令牌没有保存在服务器上的任何地方。所以这个过程是完全无状态的。

然后，每次用户想要访问一个受保护的路由，例如他的用户配置文件数据。他将他的Json Web Token与请求一起发送，所以这有点像出示他的护照来访问那条路线。

一旦请求到达服务器，我们的应用程序将验证Json Web令牌是否有效，如果用户确实是他所说的那个人，那么请求的数据将被发送到客户端，如果不是，那么将会有一个错误告诉用户他不允许访问该资源。

所有这些通信都必须通过https进行，所以安全加密的Http，以防止任何人可以访问密码或Json Web令牌。只有这样我们才有一个真正安全的系统。

So a Json Web Token looks like left part of this screenshot which was taken from the JWT debugger at jwt.io. So essentially, it's an encoding string made up of three parts. The header, the payload and the signature Now the header is just some metadata about the token itself and the payload is the data that we can encode into the token, any data really that we want. So the more data we want to encode here the bigger the JWT. Anyway, these two parts are just plain text that will get encoded, but not encrypted.

所以任何人都可以解码并阅读它们，我们不能在这里存储任何敏感数据。但这根本不是问题，因为在第三部分，在签名部分，才是真正有趣的地方。签名是使用头、有效负载和保存在服务器上的秘密创建的。

这整个过程被称为签署Json Web令牌。签名算法使用报头、有效负载和秘密来创建唯一的签名。所以只有这个数据加上这个秘密才能创建这个签名，对吧? 然后加上头部和有效载荷，这些签名形成了JWT， 然后被发送到客户端。

一旦服务器接收到JWT以授予对受保护路由的访问权，它就需要验证它，以确定用户是否真的是他所声称的那个人。换句话说，它将验证是否没有人更改标记的标头和有效负载数据。同样，此验证步骤将检查是否没有第三方实际更改Json Web Token的报头或有效负载。

那么，这种验证实际上是如何工作的呢?其实很简单。一旦接收到JWT，验证将使用它的头部和有效负载，以及仍然保存在服务器上的秘密，基本上创建一个测试签名。

但是JWT第一次创建时生成的原始签名仍然在令牌中，对吗?这就是验证的关键。因为现在我们所要做的就是将测试签名与原始签名进行比较。 如果测试签名与原始签名相同，则意味着有效负载和报头没有被修改。

Because if they had been modified, then the test signature would have to be different. Therefore in this case where there has been no alteration of the data, we can then authenticate the user. And of course, if the two signatures are actually different, well, then it means that someone tampered with the data. Usually by trying to change the payload. But that third party manipulating the payload does of course not have access to the secret, so they cannot sign the JWT. So the original signature will never correspond to the manipulated data. And therefore, the verification will always fail in this case. And that's the key to making this whole system work. It's the magic that makes JWT so simple, but also extremely powerful.

你可以去jwt。Io，粘贴您的令牌并读取内容。一开始，这对很多人来说是不和谐的。

简而言之，智威汤逊并不关心加密问题。它关心验证。也就是说，它总是可以得到“这个令牌的内容是否已被操纵”的答案?这意味着用户对JWT令牌的操作是无效的，因为服务器将知道并忽略令牌。服务器在向客户端发出令牌时根据有效负载添加签名。随后，它验证有效载荷和匹配签名。

合乎逻辑的问题是，它不关心加密内容的动机是什么?

The simplest reason is because it assumes this is a solved problem for the most part. If dealing with a client like the web browser for example, you can store the JWT tokens in a cookie that is secure (is not transmitted via HTTP, only via HTTPS) and httpOnly (can't be read by Javascript) and talks to the server over an encrypted channel (HTTPS). Once you know you have a secure channel between the server and client you can securely exchange JWT or whatever else you want. This keeps thing simple. A simple implementation makes adoption easier but it also lets each layer do what it does best (let HTTPS handle encryption). JWT isn't meant to store sensitive data. Once the server receives the JWT token and validates it, it is free to lookup the user ID in its own database for additional information for that user (like permissions, postal address, etc). This keeps JWT small in size and avoids inadvertent information leakage because everyone knows not to keep sensitive data in JWT.

这与cookie本身的工作方式没有太大区别。cookie通常包含未加密的有效载荷。如果你使用的是HTTPS，那么一切都很好。如果不是，建议对敏感cookie本身进行加密。如果不这样做，就可能会受到中间人攻击——代理服务器或ISP读取cookie，然后假装是你，重新播放它们。出于类似的原因，JWT应该始终通过HTTPS之类的安全层进行交换。