停止使用 JSON Web代币进行身份验证?
- “由于可扩展性,JWTokens是被推荐的认证方法。”
- “JWTokens更易于使用。”
- “JWToken是无状态的,所以我们不需要使用服务器上的内存。”
我确信他们的意图是好的,但是他们共享了一种不安全的用户身份认证和授权用户的方式,至少对于web应用程序是这样的。
免责声明:我并不主张我们应该完全停止使用JWT或类似机制。然而,我看到许多教程为了简单起见,以糟糕的方式实现了它们。
我们当然可以安全地使用JWT代币,但是,我们可能不应该从头实现它们,因为广泛地保护它们会变得很复杂。
JWT通常实现的方式(在教程中)
让我们看一下使用JWT对用户进行身份验证的流程。
- 用户输入他们的用户名和密码——当用户单击登录按钮时,将向服务器发送一个请求,用数据库验证用户的凭据。
- 服务器成功地验证了用户的身份——服务器现在使用一个密码创建并签署一个JWT,并在响应中返回它。
教程通常将到期时间设置为一周到30天。
- 客户端在响应中接收JWT——开发人员(在像chrome这样的客户端中)接收它,应用一些逻辑,然后存储它,通常是在本地存储。
- 客户端使用存储在代币中的信息来有条件地渲染——通常,教程使用像用户的电子邮件、用户名和布尔字段,如isAdmin。
- 客户端将代币添加为每个请求的标头——如果代币存在于本地存储中,则用户的会话是活动的。
服务器现在可以通过解密每个请求的签名代币来检查用户的身份。
代币将一直有效到到期。
以这种方式使用JWT的所有问题。
响应包含JWT。
我们遇到的第一个危险信号是在响应中返回代币。因此,前端代码可以自由地读取和存储代币。
访问代币会使跨站点脚本攻击能够窃取用户的身份并代表他们发送请求。因为我们没有关于用户的会话信息,所以可能没有办法知道。
JWT在到期之前一直有效
由于JWT认证是无状态的,一旦服务器签署了有效的代币,就没有办法撤销用户的会话。
因此,使用长到期窗口