jwt-autorefresh

如果你正在使用node (React / Redux / Universal JS)，你可以安装npm i -S jwt-autorefresh。

这个库计划在访问令牌到期之前的用户计算的秒数刷新JWT令牌(基于令牌中编码的exp声明)。它有一个广泛的测试套件，并检查相当多的条件，以确保任何奇怪的活动都伴随着关于来自您的环境的错误配置的描述性消息。

完整的示例实现

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())

免责声明:我是维护者

这个方法怎么样:

对于每个客户端请求，服务器将令牌的过期时间与(currentTime - lastAccessTime)进行比较。 如果expirationTime < (currentTime - lastAccessedTime)，则将上一次lastAccessedTime更改为currentTime。 如果浏览器上的不活动时间超过了过期时间，或者如果浏览器窗口被关闭并且过期时间为> (currentTime - lastAccessedTime)，那么服务器可以使令牌过期并要求用户再次登录。

在这种情况下，刷新令牌不需要额外的端点。 将感激任何反馈。

在你自己处理认证的情况下(即不使用Auth0这样的提供者)，以下方法可能有效:

Issue JWT token with relatively short expiry, say 15min. Application checks token expiry date before any transaction requiring a token (token contains expiry date). If token has expired, then it first asks API to 'refresh' the token (this is done transparently to the UX). API gets token refresh request, but first checks user database to see if a 'reauth' flag has been set against that user profile (token can contain user id). If the flag is present, then the token refresh is denied, otherwise a new token is issued. Repeat.

例如，当用户重置密码时，数据库后端的'reauth'标志将被设置。当用户下次登录时，该标志将被删除。

此外，假设您有一个策略，用户必须至少每72小时登录一次。在这种情况下，API令牌刷新逻辑还将从用户数据库检查用户的最后登录日期，并在此基础上拒绝/允许令牌刷新。

今天，许多人选择使用jwt进行会话管理，却没有意识到他们为了简单而放弃了什么。我的回答详细阐述了问题的第二部分:

那么真正的好处是什么呢?为什么不只有一个令牌(不是JWT)并将过期时间保存在服务器上呢? 还有其他选择吗?使用JWT不适合这种情况吗?

jwt能够支持基本的会话管理，但有一些限制。由于是自描述令牌，它们在服务器端不需要任何状态。这使得他们很有吸引力。例如，如果服务没有持久层，它就不需要仅仅为了会话管理而引入持久层。

然而，无国籍也是他们缺点的主要原因。由于它们只发布一次，内容固定且到期，因此您无法使用典型的会话管理设置完成您想做的事情。

也就是说，您不能按需使它们失效。这意味着您无法实现安全注销，因为没有办法使已经发出的令牌过期。出于同样的原因，您也不能实现空闲超时。一个解决方案是保留一个黑名单，但这会引入状态。

我写了一篇文章详细解释了这些缺点。需要明确的是，您可以通过添加更复杂的内容(滑动会话、刷新令牌等)来解决这些问题。

至于其他选项，如果您的客户端仅通过浏览器与您的服务交互，我强烈建议使用基于cookie的会话管理解决方案。我还列出了目前在web上广泛使用的认证方法。

services.Configure (Configuration.GetSection(“ApplicationSettings”));

        services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2); 

        services.AddDbContext<AuthenticationContext>(options =>
        options.UseSqlServer(Configuration.GetConnectionString("IdentityConnection")));

        services.AddDefaultIdentity<ApplicationUser>()
            .AddEntityFrameworkStores<AuthenticationContext>();

        services.Configure<IdentityOptions>(options =>
        {
            options.Password.RequireDigit = false;
            options.Password.RequireNonAlphanumeric = false;
            options.Password.RequireLowercase = false;
            options.Password.RequireUppercase = false;
            options.Password.RequiredLength = 4;
        }
        );

        services.AddCors();

        //Jwt Authentication

        var key = Encoding.UTF8.GetBytes(Configuration["ApplicationSettings:JWT_Secret"].ToString());

        services.AddAuthentication(x =>
        {
            x.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
            x.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
            x.DefaultScheme = JwtBearerDefaults.AuthenticationScheme;
        }).AddJwtBearer(x=> {
            x.RequireHttpsMetadata = false;
            x.SaveToken = false;
            x.TokenValidationParameters = new Microsoft.IdentityModel.Tokens.TokenValidationParameters
            {
                ValidateIssuerSigningKey = true,
                IssuerSigningKey = new SymmetricSecurityKey(key),
                ValidateIssuer = false,
                ValidateAudience = false,
                ClockSkew = TimeSpan.Zero
            };
        });
    }

JWT的想法很好，你把你需要的东西放进JWT，然后无状态化。 两个问题:

糟糕的JWT标准化。 JWT是不可能失效的，如果创建快速到期，它会迫使用户频繁登录。

1的解。使用自定义JSON:

 {"userId": "12345", "role": "regular_user"}

使用对称(AES)算法加密它(它比使用非对称算法签名更快)，并将其放入快速过期的cookie中。我仍然会称它为JWT，因为它是JSON，并且在Web应用程序中用作令牌。现在，服务器检查cookie是否存在，其值是否可以解密。

2的解。使用刷新令牌:

将userId作为12345，对其加密，并将其放入长期过期的cookie中。不需要在DB中为刷新令牌创建一个特殊字段。

现在，每次访问令牌(JWT) cookie过期时，服务器都会检查刷新令牌cookie，解密，获取值，并在DB中查找用户。如果找到用户，则生成一个新的访问令牌，否则(或者如果刷新令牌也过期)强制用户登录。

最简单的替代方法是使用刷新令牌作为访问令牌，即根本不使用JWT。

使用JWT的优点是，在它的过期时间内，服务器不会访问DB。即使我们在cookie中放入一个过期时间只有2分钟的访问令牌，对于像eBay这样繁忙的应用程序，它也会导致每秒避免数千DB的点击。