您的 JWT 已经是您的身份验证证明。所以你必须在每个请求中发送它,但你可以简化服务器端的身份验证逻辑。
在登录时,您必须检查您可以依赖 JWT 签名和expiryDate 的凭据。如果签名仍然正确,则令牌有效,您无需再进行身份验证。
关于您的横向身份验证。
如果需要对调用的服务进行身份验证,则必须检查 JWT 对每个请求的有效性(通常工作得相当快)。如果有开放的 api 调用,你当然可以忽略服务器端的 JWT。
在一天结束时,您的“会话”没有区别,它还会发送一些映射您的会话上下文的“秘密”密钥。因此,它也将被验证。
对于某些后端,您还可以使用 JWT 作为会话密钥来参与其中。
示例:
假设您有两个 api 根:
api/secured/*
api/open/*
(请注意,secured 和 open 仅用于演示目的)
secured 部分将包含您要进行身份验证的所有服务。
open 部分可以包含不敏感数据以及您的登录服务:
api/open/login -> returns your token
api/open/token/* -> refresh, check re-issue whatever you might need
现在假设用户访问了您的网站。如果他在没有正确 JWT 的情况下尝试访问任何 api/secured/* URL,您将需要提供身份验证错误。
在这种情况下,您可以将他重定向到您的登录名并在验证他身份后创建一个令牌。
现在,当他调用api/secured/* URL 时,您的客户端实现必须提供 JWT(Cookie、请求标头等)。
根据您的框架、语言等,您现在可以在服务器端提供一个拦截器/过滤器/处理程序,它将检查:
- 如果 JWT 存在
- 如果签名有效(否则令牌是伪造的)
- 如果 JWT 仍然有效(过期日期)
那么你就可以采取相应的行动了。
总结一下:
除非您想创建新令牌,否则无需“验证”。
在所有其他情况下,检查 JWT 的有效性就足够了