登录时,将从服务器发送JWT访问令牌,并保存在RN中的AsyncStorage中。
现在,我希望用户保持登录5年,直到他们:
> < li>
注销
管理员撤销了他们的令牌
他们在3台设备上登录,在其中一台设备上更改密码,这应该从其他2台设备上注销他们,直到他们在这些设备上再次登录
丢失他们的电话,并从另一个设备登录以从所有设备注销
看起来我不得不在数据库中存储JWT令牌(我知道这不是JWT令牌的重点,根据我的阅读,这违背了它们的目的),但我需要知道用户在他们不同设备上的令牌,以便能够撤销它们。
让我感到困惑的一件事是,访问令牌应该是短暂的,比如 60 分钟,而刷新令牌的生存期应该很长,比如我的情况是 5 年。
我不明白的是,为什么我们不能使用访问令牌来拥有5年的生命周期(对于每个设备),将它们保存在数据库中的用户,以便我们可以根据上述点识别他们的令牌并撤销他们的令牌?刷新令牌的意义是什么,在这种情况下甚至需要吗?
注意:我还读到我们不能撤销访问令牌,只能撤销刷新令牌,所以我真的很困惑。我是否必须向RN发送接入令牌和刷新令牌,并且仅将刷新令牌用于授权承载报头,并且仅将刷新令牌保存在DB中?如果访问令牌不是数据库中的令牌,那么它有什么意义呢?
我认为这应该是一些简单的实现,但我的标准是5年登录,并能够根据上述要点撤销令牌。
这种情况的正确解决办法是什么?
访问令牌是短暂的,默认情况下是24小时。但是为什么呢?为什么不是5年?
>
任何拥有访问令牌的人都可以保证访问用户(最初向其颁发访问令牌的用户)可以访问的任何内容。这意味着服务器无法区分该用户和其他拥有访问令牌的用户。
没有注销。我的意思是,您可以让前端重定向到登录页面以让他输入凭据,但真正注销不会在服务器中发生。从技术上讲,用户可以使用相同的访问令牌继续获取访问权限(直到过期)
访问令牌不能被撤销。访问令牌只有在到期时才会失效。任何人都可以使用它,直到令牌到期。例如,如果到期设置为5年,而我碰巧得到了你的令牌,我可以拥有你所有的访问权限,直到它到期,在这种情况下是5年。这正是将到期时间设置为小于24小时更有意义的地方。
现在让我们解决您的疑问。“我想让用户登录,直到他”
在用户登录后向其发送刷新令牌。非常安全地存储访问令牌和刷新令牌。在他的访问令牌过期后,使用刷新令牌来获得新的访问令牌。循环这个直到他退出。当他注销时,删除前端的访问令牌和刷新令牌,并撤销服务器端的刷新令牌。(同样,如果他以某种方式获得了访问令牌,他仍然可以访问他的帐户,直到它过期)
正如我之前所说,服务器不能撤销访问令牌,一旦发布其有效期至到期,无论发生什么-
与2相同。更改密码后,撤销所有发出的刷新令牌(如果您不希望用户再次登录,请撤销除当前设备之外的所有刷新令牌)。您在所有设备上的应用程序将被迫使用刷新令牌获取新的访问令牌,但由于您撤销了它,用户除了使用他的凭据登录之外别无选择。
与3相同。更改密码会触发所有设备的注销,这里您只需要添加一个“注销所有设备”按钮,该按钮将发送一个服务器请求,该请求将撤销除当前设备外的所有刷新令牌。
警告:当前用户会话无法关闭;您需要等待用户退出应用程序,以便删除当前的访问令牌。解决方法是在他关闭应用程序(或者甚至最小化应用程序)时立即删除访问令牌,或者将访问令牌到期时间设置为30分钟,前提是您可以容忍每次使用刷新令牌获取新的访问令牌所导致的延迟。您需要在时间和安全性之间做出权衡,反之亦然,具体取决于您的应用规格。
“没关系,但我不想首先使用刷新令牌”(备选解决方案):
我不鼓励存储令牌,因为它通过增加由于查询数据库而增加的响应时间来破坏扩展和防止轻松DDoS的目的。但是,由于 Redis 是在内存上运行的非常快的键值存储,因此有些人更喜欢在其中存储访问令牌。那么这是怎么回事呢?
设置:用户登录后,颁发访问令牌。将其存储在 Redis 中,然后将其发送给用户。
>
检查JWT签名
如果成功,请检查 Redis 以获取令牌。如果存在,请授予访问权限。如果没有,请让用户重新登录。请注意,这比仅使用 JWT 授予访问权限要慢一些,但是嘿,您没有在其中存储 Postgres 或 Mongo,这可能需要几毫秒才能响应;Redis 是一个键值存储 - 因为它位于内存(而不是存储)上 - 比那些快得多。
当且仅当两个条件都满足时,才授予访问权限:JWT有效。JWT存在于Redis中
回答您的问题:
现在可以注销了。当用户点击注销时,从Redis中删除访问令牌。即使他有访问令牌,他也无法登录。访问令牌现在实际上是无效的。
服务器成功授予用户访问权限后,您应允许用户发出请求,删除具有相同user-id(或uid)的所有其他令牌,这将允许注销
密码更改后,发出这样的请求。
在从其他设备注销时,发出此类请求。
最后遗漏了1。保持登录状态,直到用户注销:既然您有权使不使用 Redis 时没有的访问令牌失效,您可以拥有 5 年有效的访问令牌,前提是您实施其他必需的安全措施以防止滥用访问令牌。
我最近一直在搜索刷新令牌和旋转访问令牌,我突然想到了一些东西。 为什么不使用一个令牌而不是访问令牌和刷新令牌?在该令牌有效载荷(声明)中包含一个验证日期,并将验证期设置得很低(就像访问令牌一样),将到期日期设置得很高(就像刷新令牌一样)。 如果验证日期超过服务器上的日期但未过期,服务器将颁发新令牌并使旧令牌无效(通过任何方式,例如令牌黑名单等,就像 AT 过期和使用刷新令牌颁发新令牌一样),如果令
在我最近的遭遇中,我试图实现在前端安全存储的JWT令牌。我以前的方法是在易受XSS攻击的sessionStorage中存储以及。现在,当过期时,我将调用endpoint来获取新的 之后,我们更改实现以防止XSS和CSRF。接下来,Local存储与Cookie 建议将访问令牌存储在内存中,并将刷新令牌存储在cookie中。所以从FE,我们无法访问cookie。(HTTPOnly cookie)和 现
我有一个关于spring-security-oauth2 2.0.7配置的问题。我正在通过GlobalAuthenticationConfigurerAdapter使用LDAP进行身份验证: 虽然refresh令牌在spring-security-oauth2的2.0.6版中运行良好,但在2.0.7版中就不再运行了。正如这里所读的,应该设置以便在刷新期间尝试获取新的访问令牌时使用。 据我理解,这与
授权服务器可以给Web应用客户端和本机应用程序客户端颁发刷新令牌。 刷新令牌在传输和储存时必须保持机密性,并只与授权服务器和刷新令牌被颁发的客户端共享。授权服务器必须维护刷新令牌和它被颁发给的客户端之间的绑定。刷新令牌必须只能使用带有RFC2818定义的服务器身份验证的1.6所述的TLS 传输。 授权服务器必须验证刷新令牌和客户端身份之间的绑定,无论客户端身份是否能被验证。当无法进行客户端身份验证
刷新令牌是用于获取访问令牌的凭据。刷新令牌由授权服务器颁发给客户端,用于在当前访问令牌失效或过期时,获取一个新的访问令牌,或者获得相等或更窄范围的额外的访问令牌(访问令牌可能具有比资源所有者所授权的更短的生命周期和更少的权限)。颁发刷新令牌是可选的,由授权服务器决定。如果授权服务器颁发刷新令牌,在颁发访问令牌时它被包含在内(即图1中的步骤D)。 刷新令牌是一个代表由资源所有者给客户端许可的授权的字
我对oauth2中的刷新令牌有点困惑。如它所说的访问令牌限制了黑客可以使用用户凭证的1小时的时间窗口,刷新令牌是万岁令牌,可以用来重新创建访问令牌。 我很困惑,如果有人从cookie中窃取了访问令牌,他也可以窃取刷新令牌,并可以使用刷新令牌创建新的访问令牌,因为我在JQuery中有ajax请求(客户端)