问JWT和Session:如何正确使用JWT而不是Session

EN

您的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

现在假设用户访问了您的站点。如果他试图在没有适当的api/secured/*的情况下访问任何JWT，您将需要证明身份验证错误。在这种情况下，您可以将他重定向到您的登录，并在验证他的身份后创建一个令牌。

现在，当他调用JWT时，您的客户端实现必须提供api/secured/* (Cookie、请求头等)。根据您的框架、语言等，您现在可以在服务器端提供一个拦截器/过滤器/处理程序，它将检查：

如果存在联合小波变换，则返回

• 如果签名有效(否则令牌是伪造的)，则返回

• 如果联合变换仍然有效，则返回

然后你就可以采取相应的行动了。

所以总结一下:除非你想创建一个新的令牌，否则不需要“认证”。在所有其他情况下，检查JWT的有效性就足够了

如果您的应用程序使用会话...然后，虽然水平扩展共享会话数据成为一种负担，但....you要么需要专门的服务器。Jwt是无状态，没有这样的要求。它包含以下数据

Header-有关签名算法、有效负载类型(JWT)等信息，采用JSON格式

签名:好吧.签名

有效负载- JSON格式的实际数据(如果您喜欢，也可以称为声明)