【问题标题】:JWT and Session: how JWT should be properly used instead of SessionJWT 和 Session:如何正确使用 JWT 而不是 Session
【发布时间】:2018-11-06 20:02:51
【问题描述】:

我正在开发一个使用 PHP 和 Angular 的项目。对于用户登录,我们使用 JWT。如果每次用户浏览一个组件时我们需要将令牌发送到服务器代码以检查用户是否仍然登录,我们仍然无法理解为什么我们应该使用 JWT 而不是 Sessions。

用户名和密码将被发送到服务器代码,在那里进行身份验证过程,然后生成一个令牌并将其发送回 Angular,然后保存在本地存储中。

关于如何正确使用 JWT 的任何评论。

编辑

我的问题是关于当用户浏览网站并从组件进入另一个时检查 JWT 的过程。

【问题讨论】:

  • 我的问题是关于当用户浏览网站并从组件进入另一个时检查 JWT 的过程。

标签: session jwt


【解决方案1】:

如果您将会话用于您的应用程序......那么,虽然水平扩展共享会话数据成为一种负担......你需要一个专门的服务器......Jwt 是无状态的并且没有这样的要求。它包含以下数据

标头 - 有关签名算法、负载类型 (JWT) 等 JSON 格式的信息

签名 - 嗯……签名

有效负载 - JSON 格式的实际数据(或您喜欢的声明)

【讨论】:

  • 我的问题是关于当用户浏览网站并从组件进入另一个时检查 JWT 的过程。
【解决方案2】:

您的 JWT 已经是您的身份验证证明。所以你必须在每个请求中发送它,但你可以简化服务器端的身份验证逻辑。

在登录时,您必须检查您可以依赖 JWT 签名和expiryDate 的凭据。如果签名仍然正确,则令牌有效,您无需再进行身份验证。

关于您的横向身份验证。 如果需要对调用的服务进行身份验证,则必须检查 JWT 对每个请求的有效性(通常工作得相当快)。如果有开放的 api 调用,你当然可以忽略服务器端的 JWT。

在一天结束时,您的“会话”没有区别,它还会发送一些映射您的会话上下文的“秘密”密钥。因此,它也将被验证。 对于某些后端,您还可以使用 JWT 作为会话密钥来参与其中。

示例:

假设您有两个 api 根:

api/secured/*
api/open/*

(请注意,securedopen 仅用于演示目的)

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、请求标头等)。 根据您的框架、语言等,您现在可以在服务器端提供一个拦截器/过滤器/处理程序,它将检查:

  1. 如果 JWT 存在
  2. 如果签名有效(否则令牌是伪造的)
  3. 如果 JWT 仍然有效(过期日期)

那么你就可以采取相应的行动了。

总结一下: 除非您想创建新令牌,否则无需“验证”。 在所有其他情况下,检查 JWT 的有效性就足够了

【讨论】:

  • 有没有实际的例子。
  • 举一个实际的例子,我需要更多的上下文。我会举一个例子,也许这已经可以帮助你了
  • 如何检查token的有效性?
  • 有很多库支持这个。您只需将令牌和用于生成它的密钥传递给他们,它将使用内容和签名进行验证。如果你想要一个自制的解决方案,你也可以简单地将令牌保存在数据库或服务器上下文中并进行简单的比较
  • 还有一件事:你能为此提议一个库吗?
猜你喜欢
  • 2019-05-14
  • 2020-10-14
  • 1970-01-01
  • 1970-01-01
  • 2020-06-21
  • 2022-01-13
  • 2018-02-14
  • 2020-11-04
  • 2016-03-03
相关资源
最近更新 更多