Understanding JWT

Understanding JWT

本文关键字:JWT Understanding      更新时间:2023-09-26

我花了几个星期的时间来研究JWT对象。前提是有意义的,但我困惑的是安全方面。如果我是一个Javascript客户端(例如Firebase),并希望使用Open Auth向api发送安全请求,我会用密钥加密我的消息。然而,由于客户端源可能被查看,我如何保护我的密钥,使恶意请求无法通过。我错过什么了吗?有办法保护钥匙吗?

Joel,我想你走错方向了;)

可以在OAuth协议中使用JWT来实现一些人所谓的"无状态身份验证",这意味着在(客户端或用户)成功身份验证后,身份验证服务器将发出一个签名的令牌(例如客户端应用程序或用户),而不需要存储有关它的信息,这在使用不透明令牌时是必需的。

签名令牌可以被你的JS客户端用来调用特定的REST-API端点(在所谓的资源服务器上),该端点将根据JWT的内容(声明)验证令牌的签名并授权你的请求或不授权。

您的客户端应用程序以及资源服务器都能够内省令牌并验证其签名,因为它们要么与身份验证服务器有共享密钥(谁首先使用该密钥对令牌进行签名),要么知道与身份验证服务器用于签名令牌的私钥对应的公钥(正如Florent在他的评论中提到的)。

jwt也可以加密,如果资源服务器或认证服务器需要敏感信息,但不希望存储/访问数据,这是很有用的。只要您没有使用的加密密钥,您就无法内省它。

…长话短说,OAuth协议描述了针对资源或身份验证服务器的客户端身份验证。JWT可用于传输认证证明(作为Authorization报头中的承载令牌)。然而,在OAuth流中使用JWT的想法并不是"向api发送安全请求"。

使用接收方的公钥执行加密过程。您的客户端没有要生成和管理的私钥。

如果您想要接收和解密这样的JWT,那么您的客户端必须仅为会话创建一个密钥对(私有和公共),然后与服务器交换公钥。

在构建api服务器时,我更喜欢客户端在自己的服务器上进行加密过程,然后发送加密数据。

如果加密必须以某种方式在web客户端完成,我希望密钥非常短暂&基于时间,并且API服务器和客户端都有商定的特殊算法来再次生成该密钥。因此,如果密钥以某种方式被破解,攻击者将无法长期受益。