我花了几个星期的时间试图围绕 JWT 对象进行研究。这个前提是有道理的，但我感到困惑的是安全方面。如果我是 Javascript 客户端（例如 Firebase）并且想使用 Open Auth 向 api 发送安全请求，我会使用密钥加密我的消息。但是，由于可以查看客户端源，我如何保护我的密钥，以免恶意请求通过。我是不是错过了什么。有没有办法保护密钥？
【问题讨论】：
标签： javascript jwt
乔尔，我认为你的方向错了；）
可以在 OAuth 协议中使用 JWT 来实现某些人可能称之为“Stateless Authentication”的功能，这意味着身份验证服务器将在成功身份验证后（例如客户端应用程序或用户）颁发签名令牌（对于客户端或用户）而不存储关于它的信息，这在使用不透明令牌时是必需的。
您的 JS 客户端可以使用已签名的令牌，例如根据 JWT 的内容（声明）调用某个 REST-API 端点（在所谓的资源服务器上），该端点将验证令牌的签名并授权或不授权您的请求。
您的客户端应用程序和资源服务器都能够内省令牌并验证其签名，因为它们要么与身份验证服务器（首先使用该秘密对令牌进行签名）共享秘密，要么知道与身份验证服务器用于签署令牌的私钥相对应的公钥（正如 Florent 在他的评论中提到的那样）。
JWT 也可以加密，如果资源服务器或身份验证服务器需要敏感信息但不想存储/访问数据，这很有用。只要您没有使用过的加密密钥，您就无法对其进行自省。
...长话短说，OAuth 协议描述了针对资源或身份验证服务器的客户端身份验证。 JWT 可用于传输身份验证证明（作为 Authorization 标头中的 Bearer 令牌）。但是，在 OAuth 流程中使用 JWT 的想法并不是“向 api 发送安全请求”。
【讨论】：
在搭建api服务器时，我更喜欢客户端在自己的服务器上进行加密处理，然后发送加密数据。一切都在 https 下。
如果加密必须以某种方式在 Web 客户端完成，我更喜欢密钥非常短暂且基于时间，并且 api 服务器和客户端都有商定的特殊算法来再次生成该密钥。因此，如果密钥以某种方式被黑客入侵，攻击者将无法长期受益。
【讨论】：
使用接收者的公钥执行加密过程。 您的客户没有要生成和管理的私钥。
如果您想接收和解密此类 JWT，那么您的客户端必须仅为会话创建一个密钥对（私有和公共），然后与服务器交换公钥。
【讨论】：