JWT
官方文档说JWT
最常用于身份验证。
身份验证是确定某人或某事实际上是宣称是谁或者是什么的过程。
现在,如果我的服务器从客户端获取请求,并且该请求的标头包含JWT
。我将使用我的密钥验证JWT
令牌。
如果token
有效,我可以肯定地说:
John123
,则他们为John123
提供了正确的密码(服务器验证了这一点,否则服务器返回错误响应)。 如果token
有效,我无法肯定地说:
John123
(在请求正文中传递{userid:John123}
)并且他们向我们提供了有效的JWT
,我无法肯定地说他们的说法是正确的。因为用户Alice123
可能会进入localstorage
John123
并偷走令牌并将其设置为localstorage
。现在我的问题是JWT
如何真正验证用户实际上是他们声称的那样。我在这里缺少什么?我是否需要保留客户JWT
,userid
和ip
的映射。
答案 0 :(得分:4)
您遗失的一步是,即使在验证传入的JWT的真实性和声明(例如到期日期)之后,您仍可能必须访问您的用户数据库以确保该帐户处于活动状态且仍然存在。因此,JWT本身并不能解决整个问题。
关于你最后的实际问题,你通常不知道JWT的持有者到底是谁。如果爱丽丝窃取了约翰的电话,那么事实上她可能会伪装成他。但请记住,如果她做了这么激烈的事情,那么她可能也有他的信用卡和银行卡,也许还有一些其他密码。没有认证过程是完全安全的。
对于较少形式的盗窃,JWT仍然很强大。例如,如果有人试图设置中间人攻击以嗅探您的JWT,那么假设您的应用使用SSL加密JWT,则无法正常工作。当然,JWT的真正原因在于它们已经使用服务器已知的密钥进行签名,以防止承载者篡改它们。
答案 1 :(得分:1)
JWT不会验证用户是否是他们声称的用户,因为JWT不是身份验证框架。如果您使用JWT作为访问令牌,则您/您的身份验证中间件应确保仅依赖令牌本身中的信息来识别用户而不是请求正文中的任何信息。
通常,您会将用户ID或名称存储在令牌中。 sub
claim可以用于此。
“sub”(主题)声明标识了作为的主体 JWT的主题。 JWT中的声明通常是声明 关于这个问题。
认证中间件通常只验证JWT本身没有被修改。但是你不会认识到Alice是否使用了John的令牌。