PROSAGA码农传奇-云鉴权-JWT（JSON Web Token）自动延长到期时间

11 条回复

0#
回复此人
小它．Little it | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 在后端没有任何额外安全存储的情况下，使JWT无效的替代解决方案是实现新的 <code> jwt_version </code> users表上的整数列。如果用户希望注销或使现有令牌过期，他们只需增加 <code> jwt_version </code> 领域。 </p> <P> 生成新的JWT时，编码 <code> jwt_version </code> 进入JWT有效负载，如果新的JWT应该替换所有其他有效负载，可以选择预先增加该值。 </p> <P> 在验证JWT时， <code> jwt_version </code> 田野与之相比较 <code> user_id </code> 授权仅在匹配时授予。 </p> </DIV>

编辑
1#
回复此人
喜欢一个人丶 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 我通过在令牌数据中添加一个变量来解决这个问题： </p> <pre> <code> softexp - I set this to 5 mins (300 seconds) </code> </pre> <P> 我设置 <code> expiresIn </code> 在用户被迫再次登录之前，我所需时间的选项。我的设定为30分钟。这必须大于。的值 <code> softexp </code> 。 </p> <P> 当我的客户端应用程序向服务器API（需要令牌，例如客户列表页面）发送请求时，服务器会根据其原始到期时间检查提交的令牌是否仍然有效（ <code> expiresIn </code> ）价值。如果它无效，服务器将以特定于此错误的状态进行响应，例如。 <code> INVALID_TOKEN </code> 。 </p> <P> 如果令牌仍然有效，则基于 <code> expiredIn </code> 价值，但它已经超过了 <code> softexp </code> 值，服务器将以此错误的单独状态响应，例如。 <code> EXPIRED_TOKEN </code> ： </p> <pre> <code> (Math.floor(Date.now() / 1000) > decoded.softexp) </code> </pre> <P> 在客户端，如果收到 <code> EXPIRED_TOKEN </code> 响应，它应该通过向服务器发送续订请求自动更新令牌。这对用户是透明的，并自动处理客户端应用程序。 </p> <P> 服务器中的续订方法必须检查令牌是否仍然有效： </p> <pre> <code> jwt.verify(token, secret, (err, decoded) => {}) </code> </pre> <P> 如果上述方法失败，服务器将拒绝续订令牌。 </p> </DIV>

编辑
2#
回复此人
老夫的少女心吖 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 在后端使用RESTful apis将应用程序移动到HTML5时，我正在修补。我想出的解决方案是： </p> <OL> <LI> 成功登录后，将向客户端发出一个会话时间为30分钟（或通常的服务器端会话时间）的令牌。 </LI> <LI> 创建客户端计时器以调用服务以在令牌到期之前续订令牌。新令牌将替换将来调用中的现有令牌。 </LI> </醇> <P> 如您所见，这减少了频繁的刷新令牌请求。如果用户在触发续订令牌呼叫之前关闭浏览器/应用程序，则先前令牌将及时到期，用户必须重新登录。 </p> <P> 可以实现更复杂的策略以满足用户不活动（例如忽略打开的浏览器选项卡）。在这种情况下，续订令牌调用应包括预期的到期时间，该时间不应超过定义的会话时间。应用程序必须相应地跟踪最后的用户交互。 </p> <P> 我不喜欢设置长期到期的想法，因此这种方法可能不适用于需要较少频繁身份验证的本机应用程序。 </p> </DIV>

编辑
3#
回复此人
晴天？霹雳 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <H3> <a href="https://npmjs.com/package/jwt-autorefresh" rel="nofollow"> 智威汤逊 - 自动刷新 </A> </H3> <P> 如果您使用的是节点（React / Redux / Universal JS），则可以安装 <code> npm i -S jwt-autorefresh </code> 。 </p> <P> 此库根据用户计算的访问令牌到期之前的秒数（基于令牌中编码的exp声明）计划刷新JWT令牌。它有一个广泛的测试套件，可以检查很多条件，以确保任何奇怪的活动都伴随着有关环境配置错误的描述性消息。 </p> <P> 的<strong> 完整的示例实现 </强> </p> <pre class="lang-js prettyprint-override"> <code> import autorefresh from 'jwt-autorefresh' /** Events in your app that are triggered when your user becomes authorized or deauthorized. */ import { onAuthorize, onDeauthorize } from './events' /** Your refresh token mechanism, returning a promise that resolves to the new access tokenFunction (library does not care about your method of persisting tokens) */ const refresh = () => { const init = { method: 'POST' , headers: { 'Content-Type': `application/x-www-form-urlencoded` } , body: `refresh_token=${localStorage.refresh_token}&grant_type=refresh_token` } return fetch('/oauth/token', init) .then(res => res.json()) .then(({ token_type, access_token, expires_in, refresh_token }) => { localStorage.access_token = access_token localStorage.refresh_token = refresh_token return access_token }) } /** You supply a leadSeconds number or function that generates a number of seconds that the refresh should occur prior to the access token expiring */ const leadSeconds = () => { /** Generate random additional seconds (up to 30 in this case) to append to the lead time to ensure multiple clients dont schedule simultaneous refresh */ const jitter = Math.floor(Math.random() * 30) /** Schedule autorefresh to occur 60 to 90 seconds prior to token expiration */ return 60 + jitter } let start = autorefresh({ refresh, leadSeconds }) let cancel = () => {} onAuthorize(access_token => { cancel() cancel = start(access_token) }) onDeauthorize(() => cancel()) </code> </pre> <P> 的<strong> 免责声明：我是维护者 </强> </p> </DIV>

编辑
4#
回复此人
晴天 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 在您自己处理auth的情况下（即不使用Auth0之类的提供程序），以下内容可能有效： </p> <OL> <LI> 发出JWT令牌，到期时间相对较短，比如15分钟。 </LI> <LI> 应用程序在任何需要令牌的交易（令牌包含到期日期）之前检查令牌到期日期。如果令牌已过期，则它首先要求API“刷新”令牌（这对UX是透明的）。 </LI> <LI> API获取令牌刷新请求，但首先检查用户数据库以查看是否已针对该用户配置文件设置了“reauth”标志（令牌可以包含用户ID）。如果该标志存在，则拒绝令牌刷新，否则发出新令牌。 </LI> <LI> 重复。 </LI> </醇> <P> 例如，当用户重置密码时，将设置数据库后端中的“reauth”标志。用户下次登录时会删除该标志。 </p> <P> 此外，假设您有一项政策，用户必须至少每72小时登录一次。在这种情况下，您的API令牌刷新逻辑还将检查用户从用户数据库的上次登录日期，并在此基础上拒绝/允许令牌刷新。 </p> </DIV>

编辑
5#
回复此人
Jacob | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 我实际上是在PHP中使用Guzzle客户端为api创建了一个客户端库，但这个概念应该适用于其他平台。 </p> <P> 基本上，我发行了两个令牌，一个短的（5分钟）和一个长的，在一周后到期。如果客户端库收到对某个请求的401响应，则使用中间件尝试刷新短令牌。然后它将再次尝试原始请求，如果能够刷新，则对用户透明地获得正确的响应。如果失败，它只会将401发送给用户。 </p> <P> 如果短令牌已过期，但仍然是可信的并且长令牌有效且可信，则它将使用长令牌进行身份验证的服务上的特殊端点刷新短令牌（这是唯一可以使用的）。然后它将使用短令牌获取新的长令牌，从而每次刷新短令牌时将其延长一周。 </p> <P> 这种方法还允许我们在最多5分钟内撤销访问权限，这对于我们的使用是可以接受的，而不必存储令牌的黑名单。 </p> <P> 延迟编辑：重新阅读这几个月后，我应该指出你可以在刷新短令牌时撤销访问权限，因为它提供了更昂贵的调用的机会（例如，调用数据库以查看用户是否已被禁止），无需在每次拨打您的服务时付费。 </p> </DIV>

编辑
6#
回复此人
文艺青年 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 好问题 - 问题本身就有丰富的信息。 </p> <P> 这篇文章 <a href="https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/" rel="noreferrer"> 刷新令牌：何时使用它们以及它们如何与JWT交互 </A> 为这种情况提供了一个好主意。一些要点是： - </p> <UL> <LI> 刷新令牌包含获取新访问权所需的信息令牌。 </LI> <LI> 刷新令牌也可以过期但是相当长寿。 </LI> <LI> 刷新令牌通常受到严格的存储要求确保它们不会泄露。 </LI> <LI> 它们也可以被授权服务器列入黑名单。 </LI> </UL> <P> 另外看一看 <a href="https://github.com/auth0/angular-jwt" rel="noreferrer"> auth0 /角JWT </A> angularjs </p> <P> 对于Web API。读 <a href =“http://bitoftech.net/2014/07/16/enable-oauth-refresh-tokens-angularjs-app-using-asp-net-web-api-2-owin/"rel =”noreferrer “> 使用ASP .NET Web API 2和Owin在AngularJS App中启用OAuth刷新令牌 </A> </p> </DIV>

编辑
7#
回复此人
Autistic | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 以下是撤销JWT访问令牌的步骤： </p> <P> 1）登录时，发送2个令牌（访问令牌，刷新令牌）以响应客户端。 <BR/> 2）访问令牌将具有较少的到期时间，刷新将具有较长的到期时间。 <BR/> 3）客户端（前端）将刷新令牌存储在其本地存储中并访问令牌中的令牌。 <BR/> 4）客户端将使用访问令牌来调用apis。但是当它到期时，从本地存储中选择刷新令牌并调用auth server api以获取新令牌。 <BR/> 5）您的auth服务器将暴露api，它将接受刷新令牌并检查其有效性并返回新的访问令牌。 <BR/> 6）刷新令牌过期后，用户将被注销。 </p> <P> 如果您需要更多详细信息，请告诉我，我也可以共享代码（Java + Spring启动）。 </p> </DIV>

编辑
8#
回复此人
biu~ | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 这种方法怎么样： </p> <UL> <LI> 对于每个客户端请求，服务器将令牌的expirationTime与（currentTime - lastAccessTime）进行比较 </LI> <LI> 如果的<strong> 到期时间＆lt; （currentTime - lastAccessedTime） </强> ，它将最后的lastAccessedTime更改为currentTime。 </LI> <LI> 如果浏览器不活动超过expirationTime的时间或浏览器窗口关闭时的<strong> expirationTime＆gt; （currentTime - lastAccessedTime） </强> ，然后服务器可以使令牌过期并要求用户再次登录。 </LI> </UL> <P> 在这种情况下，我们不需要额外的终点来刷新令牌。非常感谢任何feedack。 </p> </DIV>

编辑
9#
回复此人
谦成 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 我在Auth0工作，我参与了刷新令牌功能的设计。 </p> <P> 这一切都取决于应用程序的类型，这是我们推荐的方法。 </p> <H3> Web应用程序 </H3> <P> 一个好的模式是在令牌过期之前刷新令牌。 </p> <P> 将令牌过期设置为一周，并在每次用户打开Web应用程序时每隔一小时刷新令牌。如果用户未打开应用程序超过一周，则必须再次登录，这是可接受的Web应用程序UX。 </p> <P> 要刷新令牌，您的API需要一个新端点，该端点接收有效的，未过期的JWT，并返回带有新过期字段的相同签名JWT。然后，Web应用程序将令牌存储在某处。 </p> <H3> 移动/本机应用程序 </H3> <P> 大多数本机应用程序只登录一次。 </p> <P> 我们的想法是刷新令牌永不过期，并且可以始终为有效的JWT进行交换。 </p> <P> 令牌永不过期的问题是的<strong> 决不 </强> 从不意味着。如果丢失手机怎么办？因此，它需要以某种方式由用户识别，并且应用程序需要提供撤销访问的方法。我们决定使用设备的名称，例如“maryo的iPad”。然后，用户可以转到该应用程序并撤消对“maryo的iPad”的访问权限。 </p> <P> 另一种方法是撤消特定事件上的刷新令牌。一个有趣的事件是更改密码。 </p> <P> 我们认为JWT对这些用例没用，所以我们使用随机生成的字符串，然后将它存储在我们这边。 </p> </DIV>

编辑

登录后才能参与评论