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
            };
        });
    }

我通过在令牌数据中添加一个变量来解决这个问题:

softexp - I set this to 5 mins (300 seconds)

我将expiresIn选项设置为我想要的时间，然后用户将被迫再次登录。我的设定是30分钟。这必须大于softexp的值。

当我的客户端应用程序发送请求到服务器API(令牌是必需的，例如。客户列表页面)，服务器根据其原始到期值(expiresIn)检查所提交的令牌是否仍然有效。如果它是无效的，服务器将响应此错误的状态，例如。INVALID_TOKEN。

如果基于expiredIn值令牌仍然有效，但它已经超过了softexp值，服务器将对此错误响应一个单独的状态，例如。EXPIRED_TOKEN:

(Math.floor(Date.now() / 1000) > decoded.softexp)

在客户端，如果它收到EXPIRED_TOKEN响应，它应该通过向服务器发送更新请求来自动更新令牌。这对用户是透明的，并自动被客户端应用程序照顾。

服务器中的更新方法必须检查令牌是否仍然有效:

jwt.verify(token, secret, (err, decoded) => {})

如果上述方法失败，服务器将拒绝更新令牌。

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

免责声明:我是维护者

实际上，我使用Guzzle客户端在PHP中实现了这一点，为api制作了一个客户端库，但这个概念应该适用于其他平台。

基本上，我发行了两个代币，一个短的(5分钟)，一个长的，一周后到期。如果客户机库接收到对某个请求的401响应，则使用中间件尝试对短令牌进行一次刷新。然后，它将再次尝试原始请求，如果它能够刷新，就会获得正确的响应，对用户透明。如果失败了，它会把401发给用户。

如果短令牌过期了，但仍然是可信的，而长令牌是有效且可信的，它将使用长令牌验证的服务上的一个特殊端点刷新短令牌(这是它唯一可以用于的事情)。然后，它将使用短令牌来获得一个新的长令牌，从而在每次刷新短令牌时将其延长一周。

这种方法还允许我们在最多5分钟内撤销访问，这对于我们的使用是可以接受的，而不必存储令牌黑名单。

后期编辑:在我脑海中记忆犹新的几个月后重新阅读这篇文章，我应该指出，你可以在刷新短令牌时撤销访问权，因为它为更昂贵的调用提供了机会(例如调用数据库来查看用户是否已被禁止)，而无需为每一次对你的服务的调用付费。

问得好——问题本身包含了丰富的信息。

文章“刷新令牌:何时使用它们以及它们如何与jwt交互”为这种场景提供了一个很好的想法。一些要点是:-

刷新令牌携带获取新访问所需的信息 令牌。 刷新令牌也会过期，但寿命相当长。 刷新令牌通常需要严格的存储要求 确保它们不会泄露。 它们还可以被授权服务器列入黑名单。

也可以看看auth0/angular-jwt angularjs

用于Web API。在AngularJS应用程序中启用OAuth刷新令牌使用ASP .NET Web API 2和Owin

我知道这是一个老问题，但我同时使用会话和令牌身份验证。我的应用程序是微服务的组合，所以我需要使用基于令牌的身份验证，这样每个微服务都不需要访问集中的数据库进行身份验证。我向我的用户发出2个jwt(由不同的秘密签名):

A standard JWT, used to authenticate requests. This token expires after 15 minutes. A JWT that acts as a refresh token that is placed in a secure cookie. Only one endpoint (actually it is its own microservice) accepts this token, and it is the JWT refresh endpoint. It must be accompanied by a CSRF token in the post body to prevent CRSF on that endpoint. The JWT refresh endpoint stores a session in the database (the id of the session and the user are encoded into the refresh JWT). This allows the user, or an admin, to invalidate a refresh token as the token must both validate and match the session for that user.

这工作得很好，但比使用基于会话的认证和cookie和CSRF令牌要复杂得多。因此，如果你没有微服务，那么基于会话的认证可能是可行的方法。