注：本文隶属于《理解ASP.NET Core》系列文章，请查看置顶博客或点击此处查看全文目录

在开始之前，如果你还不了解基于Cookie的身份认证，那么建议你先阅读《基于Cookie的身份认证》后再阅读本文。

另外，为了方便大家理解并能够上手操作，我已经准备好了一个示例程序，请访问XXTk.Auth.Samples.JwtBearer.HttpApi获取源码。文章中的代码，基本上在示例程序中均有实现，强烈建议组合食用！

Jwt概述

Jwt是什么

Jwt是一个开放行业标准（RFC7519），英文为Json Web Token，译为“Json网络令牌”，它可以以紧凑、URL安全的方式在各方之间传递声明（claims）。

在Jwt中，声明会被编码为Json对象，用作Jws(Json Web Signature)结构的负载（payload），或作为Jwe（Json Web Encryption）结构的明文，这就使得声明可以使用MAC（Message Authentication Code）进行数字签名或完整性保护和加密。

获取更多信息请访问 https://jwt.io/
对jwt、jws、jwe有疑惑的请参考《一篇文章带你分清楚JWT,JWS与JWE》

Jwt解决了什么问题

跨站

传统的cookie只能实现跨域，而不能实现跨站（如my.abc.com和you.xyz.com），而Jwt原生支持跨域、跨站，因为它要求每次请求时，都要在请求头中携带token。

跨服务器

在当前应用基本都是集群部署的情况下，如果使用传统cookie + session的认证方式，为了实现session跨服务器共享，还必须引入分布式缓存中间件。而Jwt不需要分布式缓存中间件，因为它可以不存储在服务器端。

Native App友好

对于原生平台（如iOS、Android、WP）的App，没有浏览器的支持，Cookie丧失了它的优势，而使用Jwt就很简单。

Jwt的结构

先看一个Jwt示例：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjUwMDAiLCJpYXQiOjE2NDI3NDg5OTIsIm5iZiI6MTY0Mjc0ODk5MiwiZXhwIjoxNjQyNzQ4OTkyLCJhdWQiOiJodHRwOi8vbG9jYWxob3N0OjUwMDAiLCJuYW1lIjoieGlhb3hpYW90YW5rIn0.nqJpZl48gnP4fv7NdsSD9JOn0VWq045Zcbmb91HMhwY

看起来就是很长一段毫无意义的乱码，不过细心点，你会发现它被符号点（

）分隔为了3个部分，看起来就像这样：

xxxxx.yyyyy.zzzzz

从左到右这3个部分称为：头部（Header）、载荷（Payload）和签名（Signature）。

头部（Header）

Header主要用于说明token类型和签名算法。

{"alg": "HS256","typ": "JWT",}

```
alg
```
：签名算法，这里是 HMAC SHA256
```
typ
```
：token类型，这里是JWT

对Header去除所有换行和空格后，得到：

{"alg":"HS256","typ":"JWT"}

，接着对其进行Base64Url编码，即可获取到Token的第1部分：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

载荷（Payload）

Payload是核心，主要用于存储声明信息，如token签发者、用户Id、用户角色等。

{"iss": "http://localhost:5000","iat": 1642748992,"nbf": 1642748992,"exp": 1642748992,"aud": "http://localhost:5000","name": "xiaoxiaotank"}

其中，前五个是预定义的：

```
iss
```
：Issuer，即token的签发者。
```
iat
```
：Issued At，即token的签发时间
```
exp
```
：Expiration Time，即token的过期时间
```
aud
```
：Audience，即受众，指该token是服务于哪个群体的（群体范围），或该token所授予的有权限的资源是哪一块（资源的uri）
```
nbf
```
：Not Before，即在指定的时间点之前该token不可用

实际上，Jwt中的声明可以分为以下三种类型：

```
Registered Claim
```
：预定义声明，虽然并非强制使用，但是推荐使用，包括 iss(Issuer)、sub(Subject)、aud(Audience)、exp(Expiration Time)、nbf(Not Before)、iat(Issued At)和jti(JWT ID)。可以看到，这些声明名字都很短小，这是因为Jwt的核心目标是使表示紧凑。
```
Public Claim
```
: 公共声明，Jwt的使用者可以随便定义，但是要避免和预定义声明冲突。
```
Private Claim
```
: 私有声明，不同于公共声明的是，私有声明名称可能会发生冲突，应该谨慎使用。

对Payload（记得去除所有换行和空格）进行Base64Url编码，即可获取到Token的第2部分：

eyJpc3MiOiJodHRwOi8vbG9jYWxob3N0OjUwMDAiLCJpYXQiOjE2NDI3NDg5OTIsIm5iZiI6MTY0Mjc0ODk5MiwiZXhwIjoxNjQyNzQ4OTkyLCJhdWQiOiJodHRwOi8vbG9jYWxob3N0OjUwMDAiLCJuYW1lIjoieGlhb3hpYW90YW5rIn0

不要在Payload中存储任何敏感信息，因为Base64Url不是加密，只是编码，所以这部分对于客户端来说是明文。

签名（Signature）

Signature主要用于防止token被篡改。当服务端获取到token时，会按照如下算法计算签名，若计算出的与token中的签名一致，才认为token没有被篡改。

签名算法：

先将Header和Payload通过点（.）连接起来，即
```
Base64Url编码的Header.Base64Url编码的Payload
```
，记为 text
然后使用Header中指明的签名算法对text进行加密，得到一个二进制数组，记为 signBytes
最后对 signBytes 进行Base64Url编码，得到signature，即token的第三部分

nqJpZl48gnP4fv7NdsSD9JOn0VWq045Zcbmb91HMhwY

Jwt带来了什么问题

不安全

所谓的“不安全”，是指Jwt的Payload是明文（Base64Url编码），因此其不能存储敏感数据。

不过，我们可以针对生成的token，再进行一次加密，这样相对会更加安全一些。不过无论如何，还是不如将数据保存在服务端安全。

长度太长

通过前面的示例，你也看到了，虽然我们只在token中存储了少量必要信息，但是生成的token字符串长度仍然很长。而用户每次发送请求时，都会携带这个token，在一定程度上来看，开销是较大的，不过我们一般可以忽略这点性能开销。

无状态 & 一次性

jwt最大的特点是无状态和一次性，这也就导致如果我们想要修改里面的内容，必须重新签发一个新的token。因此，也就引出了另外的两个问题：

无法手动过期如果我们想要使已签发的jwt失效，除非达到它的过期时间，否则我们是无法手动让其失效的。
无法续签假设我们签发了一个有效时长30分钟的token，用户在这30分钟内持续进行操作，当达到token的有效期时，我们希望能够延长该token的有效期，而不是让用户重新登录。显然，要实现这个效果，必须要重新签发一个新的token，而不是在原token上操作。

Bearer概述

HTTP提供了一套标准的身份认证方案：当身份认证不通过时，服务端可以向客户端发送

质询(challenge)

，客户端根据质询提供身份验证凭证进行应答。

质询与应答的具体工作流程如下：当身份认证不通过时，服务端向客户端返回HTTP状态码

401（Unauthorized，未授权）

，并在

WWW-Authenticate

头中添加如何提供认证凭据的信息，其中至少包含有一种质询方式。然后客户端根据质询，在请求头中添加

Authorization

，它的值就是进行身份认证的凭证。

在HTTP标准认证方案中，大家可能比较熟悉的是

Basic

和

Digest

。

Basic

将用户名密码使用Base64编码后作为认证凭证，而

Digest

在

Basic

的基础上针对安全性进行了升级，使得用户密码更加安全。在前文介绍的Cookie认证属于Form认证，并不属于HTTP标准认证方案。

而今天提到的

Bearer

，也属于HTTP协议标准认证方案之一，详见：RFC 6570

+--------+                               +---------------+|        |--(A)- Authorization Request ->|   Resource    ||        |                               |     Owner     ||        |<-(B)-- Authorization Grant ---|               ||        |                               +---------------+|        ||        |                               +---------------+|        |--(C)-- Authorization Grant -->| Authorization || Client |                               |     Server    ||        |<-(D)----- Access Token -------|               ||        |                               +---------------+|        ||        |                               +---------------+|        |--(E)----- Access Token ------>|    Resource   ||        |                               |     Server    ||        |<-(F)--- Protected Resource ---|               |+--------+                               +---------------+Abstract Protocol Flow

Bearer认证中的凭据称为

Bearer Token

，或称为

access token

，标准请求格式为（添加到HTTP请求头中）：

Authorization: Bearer [Access Token]

另外，如果你对

Basic

和

Digest

感兴趣，推荐阅读以下几篇文章：

HTTP认证之基本认证——Basic（一）
HTTP认证之基本认证——Basic（二）
HTTP认证之摘要认证——Digest（一）
HTTP认证之摘要认证——Digest（二）

身份认证(Authentication)

前文已经讲述过的身份认证中间件就不赘述了，咱们直接进入JwtBearer。

首先，通过Nuget安装以下三个包：

Install-Package IdentityModelInstall-Package System.IdentityModel.Tokens.JwtInstall-Package Microsoft.AspNetCore.Authentication.JwtBearer

接着，通过

AddJwtBearer

扩展方法添加JwtBearer认证方案：

public class Startup{public void ConfigureServices(IServiceCollection services){services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme).AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, options =>{// 在这里对该方案进行详细配置});}}

同

CookieAuthenticationDefaults

类似，JwtBearer也提供了

JwtBearerDefaults

，不过它比较简单，就只有一个

AuthenticationScheme

：

public static class JwtBearerDefaults{public const string AuthenticationScheme = "Bearer";}

同样地，我们可以通过

options

针对Jwt的验证参数、验证处理器、事件回调等进行详细配置。它的类型为

JwtBearerOptions

，继承自

AuthenticationSchemeOptions

。下面会针对一些常用参数进行详细讲解（本文只介绍最简单的jwt签发和验证，不涉及认证授权认证中心）。

在开始之前，先自定义一个选项类

JwtOptions

，将常用参数配置化：

public class JwtOptions{public const string Name = "Jwt";public readonly static Encoding DefaultEncoding = Encoding.UTF8;public readonly static double DefaultExpiresMinutes = 30d;public string Audience { get; set; }public string Issuer { get; set; }public double ExpiresMinutes { get; set; } = DefaultExpiresMinutes;public Encoding Encoding { get; set; } = DefaultEncoding;public string SymmetricSecurityKeyString { get; set; }public SymmetricSecurityKey SymmetricSecurityKey => new(Encoding.GetBytes(SymmetricSecurityKeyString));}

现在，我们无需关注各个参数的具体值是多少，直接看下方的方案配置：

public class Startup{public void ConfigureServices(IServiceCollection services){services.Configure<JwtOptions>(Configuration.GetSection(JwtOptions.Name));var jwtOptions = Configuration.GetSection(JwtOptions.Name).Get<JwtOptions>();services.AddSingleton(sp => new SigningCredentials(jwtOptions.SymmetricSecurityKey, SecurityAlgorithms.HmacSha256Signature));services.AddScoped<AppJwtBearerEvents>();services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme).AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, options =>{options.TokenValidationParameters = new TokenValidationParameters{ValidAlgorithms = new[] { SecurityAlgorithms.HmacSha256, SecurityAlgorithms.RsaSha256 },ValidTypes = new[] { JwtConstants.HeaderType },ValidIssuer = jwtOptions.Issuer,ValidateIssuer = true,ValidAudience = jwtOptions.Audience,ValidateAudience = true,IssuerSigningKey = jwtOptions.SymmetricSecurityKey,ValidateIssuerSigningKey = true,ValidateLifetime = true,RequireSignedTokens = true,RequireExpirationTime = true,NameClaimType = JwtClaimTypes.Name,RoleClaimType = JwtClaimTypes.Role,ClockSkew = TimeSpan.Zero,};options.SaveToken = true;options.SecurityTokenValidators.Clear();options.SecurityTokenValidators.Add(new JwtSecurityTokenHandler());options.EventsType = typeof(AppJwtBearerEvents);});}}

其中，

TokenValidationParameters

是和token验证有关的参数配置，进行token验证时需要用到，下面看详细说明：

```
TokenValidationParameters.ValidAlgorithms
```
：有效的签名算法列表，即验证Jwt的Header部分的
```
alg
```
。默认为
```
null
```
，即所有算法均可。
```
TokenValidationParameters.ValidTypes
```
：有效的token类型列表，即验证Jwt的Header部分的
```
typ
```
。默认为
```
null
```
，即算有算法均可。
```
TokenValidationParameters.ValidIssuer
```
：有效的签发者，即验证Jwt的Payload部分的
```
iss
```
。默认为
```
null
```
。
```
TokenValidationParameters.ValidIssuers
```
：有效的签发者列表，可以指定多个签发者。
```
TokenValidationParameters.ValidateIssuer
```
：是否验证签发者。默认为
```
true
```
。注意，如果设置了
```
TokenValidationParameters.IssuerValidator
```
，则该参数无论是何值，都会执行。
```
TokenValidationParameters.ValidAudience
```
：有效的受众，即验证Jwt的Payload部分的
```
aud
```
。默认为
```
null
```
。
```
TokenValidationParameters.ValidAudiences
```
：有效的受众列表，可以指定多个受众。
```
TokenValidationParameters.ValidateAudience
```
：是否验证受众。默认为
```
true
```
。注意，如果设置了
```
TokenValidationParameters.AudienceValidator
```
，则该参数无论是何值，都会执行。
```
TokenValidationParameters.IssuerSigningKey
```
：用于验证Jwt签名的密钥。对于对称加密来说，加签和验签都是使用的同一个密钥；对于非对称加密来说，使用私钥加签，然后使用公钥验签。
```
TokenValidationParameters.ValidateIssuerSigningKey
```
：是否使用验证密钥验证签名。默认为
```
false
```
。注意，如果设置了
```
TokenValidationParameters.IssuerSigningKeyValidator
```
，则该参数无论是何值，都会执行。
```
TokenValidationParameters.ValidateLifetime
```
：是否验证token是否在有效期内，即验证Jwt的Payload部分的
```
nbf
```
和
```
exp
```
。
```
TokenValidationParameters.RequireSignedTokens
```
: 是否要求token必须进行签名。默认为
```
true
```
，即token必须签名才可能有效。
```
TokenValidationParameters.RequireExpirationTime
```
：是否要求token必须包含过期时间。默认为
```
true
```
，即Jwt的Payload部分必须包含
```
exp
```
且具有有效值。
```
TokenValidationParameters.NameClaimType
```
：设置 HttpContext.User.Identity.NameClaimType，便于 HttpContext.User.Identity.Name 取到正确的值
```
TokenValidationParameters.RoleClaimType
```
：设置 HttpContext.User.Identity.RoleClaimType，便于 HttpContext.User.Identity.IsInRole(xxx) 取到正确的值
```
TokenValidationParameters.ClockSkew
```
：设置时钟漂移，可以在验证token有效期时，允许一定的时间误差（如时间刚达到token中exp，但是允许未来5分钟内该token仍然有效）。默认为300s，即5min。本例jwt的签发和验证均是同一台服务器，所以这里就不需要设置时钟漂移了。
```
SaveToken
```
：当token验证通过后，是否保存到 Microsoft.AspNetCore.Authentication.AuthenticationProperties，默认
```
true
```
。该操作发生在执行完
```
JwtBearerEvents.TokenValidated
```
之后。
```
SecurityTokenValidators
```
：token验证器列表，可以指定验证token的处理器。默认含有1个
```
JwtSecurityTokenHandler
```
。
```
EventsType
```
：这里我重写了
```
JwtBearerEvents
```
。

下面来看事件回调：

public class AppJwtBearerEvents : JwtBearerEvents{public override Task MessageReceived(MessageReceivedContext context){// 从 Http Request Header 中获取 Authorizationstring authorization = context.Request.Headers[HeaderNames.Authorization];if (string.IsNullOrEmpty(authorization)){context.NoResult();return Task.CompletedTask;}// 必须为 Bearer 认证方案if (authorization.StartsWith("Bearer ", StringComparison.OrdinalIgnoreCase)){// 赋值tokencontext.Token = authorization["Bearer ".Length..].Trim();}if (string.IsNullOrEmpty(context.Token)){context.NoResult();return Task.CompletedTask;}return Task.CompletedTask;}public override Task TokenValidated(TokenValidatedContext context){return Task.CompletedTask;}public override Task AuthenticationFailed(AuthenticationFailedContext context){Console.WriteLine($"Exception: {context.Exception}");return Task.CompletedTask;}public override Task Challenge(JwtBearerChallengeContext context){Console.WriteLine($"Authenticate Failure: {context.AuthenticateFailure}");Console.WriteLine($"Error: {context.Error}");Console.WriteLine($"Error Description: {context.ErrorDescription}");Console.WriteLine($"Error Uri: {context.ErrorUri}");return Task.CompletedTask;}public override Task Forbidden(ForbiddenContext context){return Task.CompletedTask;}}

```
MessageReceived
```
：当收到请求时回调，注意，此时还未获取到token。我们可以在该方法内自定义token的获取方式，然后将获取到的token赋值到
```
context.Token
```
（不包含Scheme）。只要我们取到的token既非Null也非Empty，那后续验证就会使用该token
```
TokenValidated
```
：token验证通过后回调。
```
AuthenticationFailed
```
：由于认证过程中抛出异常，导致身份认证失败后回调。
```
Challenge
```
：质询时回调。
```
Forbidden
```
：当出现403（Forbidden，禁止）时回调。

其中，在

MessageReceived

中，针对默认获取token的逻辑进行了模拟。

用户登录和注销

用户登录

现在，我们来实现用户登录功能，当登录成功时，向客户端签发一个token。

[Route("api/[controller]")][ApiController]public class AccountController : ControllerBase{private readonly JwtBearerOptions _jwtBearerOptions;private readonly JwtOptions _jwtOptions;private readonly SigningCredentials _signingCredentials;public AccountController(IOptionsSnapshot<JwtBearerOptions> jwtBearerOptions,IOptionsSnapshot<JwtOptions> jwtOptions,SigningCredentials signingCredentials){_jwtBearerOptions = jwtBearerOptions.Get(JwtBearerDefaults.AuthenticationScheme);_jwtOptions = jwtOptions.Value;_signingCredentials = signingCredentials;}[AllowAnonymous][HttpPost("login")]public IActionResult Login([FromBody] LoginDto dto){if (dto.UserName != dto.Password){return Unauthorized();}var user = new UserDto(){Id = Guid.NewGuid().ToString("N"),UserName = dto.UserName};var token = CreateJwtToken(user);return Ok(new { token });}[NonAction]private string CreateJwtToken(UserDto user){var tokenDescriptor = new SecurityTokenDescriptor{Subject = new ClaimsIdentity(new List<Claim>{new Claim(JwtClaimTypes.Id, user.Id),new Claim(JwtClaimTypes.Name, user.UserName)}),Issuer = _jwtOptions.Issuer,Audience = _jwtOptions.Audience,Expires = DateTime.UtcNow.AddMinutes(_jwtOptions.ExpiresMinutes),SigningCredentials = _signingCredentials};var handler = _jwtBearerOptions.SecurityTokenValidators.OfType<JwtSecurityTokenHandler>().FirstOrDefault()?? new JwtSecurityTokenHandler();var securityToken = handler.CreateJwtSecurityToken(tokenDescriptor);var token = handler.WriteToken(securityToken);return token;}}

我们目光直接来到

CreateJwtToken

方法，可以看到熟悉的Subject、Issuer、Audience、Expires等。其中，Subject可以装载多个自定义声明，在生成token时，会将装载的所有声明展开平铺。而另一个需要注意的就是Expires，必须使用基于UTC的时间，默认有效期为1个小时。

下面我们一起生成一个token：

然后我们给

WeatherForecastController

增加授权（详细配置过程略），并带上token进行请求：

用户注销

当使用JwtBearer认证方案时，由于Jwt的“一次性”和“无状态”特征，用户注销一般是不会在服务端实现的，而是通过客户端来实现，比如客户端从localstorage中删除该token（当然，这只是一种“曲线救国”的实现方式）。

另外，如果你可以接受的话，可以在用户注销时，服务端将Jwt加入缓存黑名单，并将缓存过期时间设置为Jwt的过期时间。

优化改进

改用非对称加密进行Jwt签名和验签

在前面的示例中，我们使用的对称加密算法HmacSha256计算的签名。试想一下，公司内的多个业务项目都会使用该token，因此，为了让每个项目都可以进行身份认证，就需要将密钥分发给所有项目，这就产生了较大的风险。因此，使用非对称加密来计算签名，是一个更加合理地选择：我们使用私钥进行签名，然后只需要将公钥暴露出去用于验签，即可验证token是有效的（没有被篡改）。下面，我们就以RsaSha256为例改进我们的程序。

首先，我们先生成Rsa的密钥对，参考以下示例代码（可在源码

AccountController

中找到）：

public void GenerateRsaKeyParies(IWebHostEnvironment env){RSAParameters privateKey, publicKey;// >= 2048 否则长度太短不安全using (var rsa = new RSACryptoServiceProvider(2048)){try{privateKey = rsa.ExportParameters(true);publicKey = rsa.ExportParameters(false);}finally{rsa.PersistKeyInCsp = false;}}var dir = Path.Combine(env.ContentRootPath, "Rsa");if (!Directory.Exists(dir)){Directory.CreateDirectory(dir);}System.IO.File.WriteAllText(Path.Combine(dir, "key.private.json"), JsonConvert.SerializeObject(privateKey));System.IO.File.WriteAllText(Path.Combine(dir, "key.public.json"), JsonConvert.SerializeObject(publicKey));}

具体细节不必多说，然后就来改进我们的

JwtOptions

：

public class JwtOptions{public const string Name = "Jwt";public readonly static double DefaultExpiresMinutes = 30d;public string Audience { get; set; }public string Issuer { get; set; }public double ExpiresMinutes { get; set; } = DefaultExpiresMinutes;}

由于RSA签名算法的私钥和公钥都保存在另外一个文件中，而且一般这个也不会轻易更改，所以就不把它们加入到选项中了。

接着，修改我们的签名算法和验签算法：

public class Startup{public Startup(IConfiguration configuration, IWebHostEnvironment env){Configuration = configuration;Env = env;}public IConfiguration Configuration { get; }public IWebHostEnvironment Env { get; set; }public void ConfigureServices(IServiceCollection services){services.Configure<JwtOptions>(Configuration.GetSection(JwtOptions.Name));var jwtOptions = Configuration.GetSection(JwtOptions.Name).Get<JwtOptions>();var rsaSecurityPrivateKeyString = File.ReadAllText(Path.Combine(Env.ContentRootPath, "Rsa", "key.private.json"));var rsaSecurityPublicKeyString = File.ReadAllText(Path.Combine(Env.ContentRootPath, "Rsa", "key.public.json"));RsaSecurityKey rsaSecurityPrivateKey = new(JsonConvert.DeserializeObject<RSAParameters>(rsaSecurityPrivateKeyString));RsaSecurityKey rsaSecurityPublicKey = new(JsonConvert.DeserializeObject<RSAParameters>(rsaSecurityPublicKeyString));// 使用私钥加签services.AddSingleton(sp => new SigningCredentials(rsaSecurityPrivateKey, SecurityAlgorithms.RsaSha256Signature));services.AddScoped<AppJwtBearerEvents>();services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme).AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, options =>{options.TokenValidationParameters = new TokenValidationParameters{// ...// 使用公钥验签IssuerSigningKey = rsaSecurityPublicKey,}}}}

至此，就OK了，其他全部都不需要改，以下是一个签发的Jwt示例，缺点是签名部分会比对称加密的长很多（毕竟安全嘛，我们可以忍受O(∩_∩)O哈哈~）：

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6Ijk4NTUxMDE3YjBjYTRjOTU5NzNmMTM3Mjk2MWZlZWM2IiwibmFtZSI6InN0cmluZyIsIm5iZiI6MTY0MzIwOTIwNiwiZXhwIjoxNjQzMjA5ODA2LCJpYXQiOjE2NDMyMDkyMDYsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6NTAwMCIsImF1ZCI6Imh0dHA6Ly9sb2NhbGhvc3Q6NTAwMCJ9.GUCYTBytxv5yqGQFB6B6rlARF3F37CJh27e-qBCKApJShSr8vq-RkPu_o0dtCONKx0y1mb2Aq5hddFQYRFaMICQMeUeCJfaVoi96chsvwahnvx1_Snz4vvaiHSmTGCXm-WAkMJdpFny0zsicegLOrJJyHFecHGENGfWee28xYSi9R70bFJjVLxR965UJzOisi5pIXjemdlipaRhdITAWz-B4iKH_2-sv6j_drkJv2CNsEjOdHxHITN6oVUpP3i4i4PmXhRM7x4O0lKeKGQE9ezZIBtXa16nUCJo0VWDD2QAwWr1akzu99wtOSoJf2MoRETwK7vOOKIbTrNQOQ1WYUQ

对jwt进行加密

我们知道，Jwt中的Header和Payload都是明文，特别是Payload中我们务必不要放置敏感信息。如果你觉得Jwt明文不妥，那你可以选择针对它加一层加密，也就是Jwt标准的另一种实现Jwe。

下面是部分代码实现：

private string CreateJwtToken(UserDto user){var tokenDescriptor = new SecurityTokenDescriptor{// ...EncryptingCredentials = new EncryptingCredentials(new SymmetricSecurityKey(Encoding.UTF8.GetBytes("Total Bytes Length At Least 256!")), JwtConstants.DirectKeyUseAlg, SecurityAlgorithms.Aes128CbcHmacSha256)};// ...}public class Startup{public void ConfigureServices(IServiceCollection services){// ...services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme).AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, options =>{options.TokenValidationParameters = new TokenValidationParameters{// ...// 如果设置了 ValidAlgorithms，则加上 Aes128CbcHmacSha256ValidAlgorithms = new[] { SecurityAlgorithms.HmacSha256, SecurityAlgorithms.RsaSha256, SecurityAlgorithms.Aes128CbcHmacSha256 },// token解密密钥TokenDecryptionKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("Total Bytes Length At Least 256!"))}}}}

下方是一个Jwe示例：

eyJhbGciOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwidHlwIjoiSldUIn0..KsIPh-Wx8TOpgNBZ5xINSA.zgqErSkpnTaWJ1TsPoIKrgpP_2uR-Orjbn54Wo4FeGmIPczk2X8N8qx4zWe9CGztrFLxeoWvYLlfRwclfglmKE9372delByVwK_C-u7cFN2TaZ183JTWYTyJVPANTC1WtuEzSe3NEKjfRoC9QN7SN4z9cJ-CtIPb1t17XB0gG0fc7T9UARZ1eIUIfnCXROAyX96qB6ABJ5Xy8wrrYkA2m5OqqLyAd8FbZfcK_rii_lbXNZsbcfgNPBQGEO6lOdBg4I3nQv9A6cqGj9qTnsIH89Dx7mBnkx0W7C9UHtZQsNTG71VSzG8g_KVifC-oO62wrOYeh48y5l4czeIWlAl4GCZpnUQmq4Y_2cw2brgG4WV7FRYPch4RMeTB6y9qrm6Rj8TvZbf_hZ51yvDYvPPVUjMiM1xo5_KLXVZa3w5aEGB4jGynVXwuGDV8XwS8sTjEkziFfA85TWPq_N-ENm4R9K_HUzwfgpGYzM-Nrf54GV8BXpnpapTc-jWij3MOpsjeyzqXdG5t-JB9_Xt7-BadjMakiU1WihiigiYMGQBmkG30r8e6bGcoL58Ytb6PQZ3NfHGCakV5LRGWFOjRUSP7X_xC0xWhrH2R6LhD1QESoE8GsTU-YS9JUREECcD2b9gXx0JxYp2mGdCkKRspajhEj4b04PV-hpr0bNSf59GkSMu_KhHuF5AcWfLSqwzACMvsvW6QvIQTzm6gXy8Ui2N80JCGkp_LzW23RFwCPSlQQ7c7S3A-Ltd_AaDQJ9C5B-To_PHESy9bUKhU-MV2tbfSST-vBeJkSn4kz4feEWcG59A.KULA_w3_XEIIKhAHKuFpsw

它的头部就是：

{"alg": "dir","enc": "A128CBC-HS256","typ": "JWT"}

借助服务端增强Jwt认证方案

虽然无状态的Jwt使用非常方便快捷，但是适用场景非常有限。为了能够实现更多功能，就需要借助服务端，从而导致Jwt的无状态性被破坏。

在进入该主题之前，请先确认一下，前面所提到的Jwt的用法已经完全符合你的要求，如果是，那么恭喜你，Jwt绝对是最适合的方案。如果不是，且你认为需要服务端，那么你应该考虑一下，你是否真的需要服务端。因为这样会使得认证行为趋向于cookie + session，从而使得认证方案的复杂性大幅增加。

Jwt静默刷新实现自动续租

试想一下以下场景：用户登录后获得了一个有效期为30分钟的token，然后填写一个表单时，花费了40分钟，点击提交后，系统要求他重新登录并重新填写表单，你猜他会不会很开心？因此，就像我们之前基于Cookie进行身份认证时一样，在基于Jwt的认证方案中，我们也需要一种类似滑动过期的机制来实现自动续租。

那该如何设计这个自动续租方案呢？你可能会想到以下的方案：

方案一：每次通过认证的请求都会重新签发Jwt来重置过期时间。该方案虽然能够解决问题，但是太过暴力，也有严重的性能问题。
方案二：jwt即将过期时才重新签发Jwt。乍一看，这方案看起来可行，但是实际上Jwt能否刷新完全是看运气。假设签发了一个有效期为30分钟的Jwt，我们打算在它有效期仅剩5分钟时重新签发。如果用户在最后5分钟内请求了，那会刷新Jwt，但是如果没有请求，那就需要用户重新登录，体验大打折扣。
方案三：签发的Jwt中忽略过期时间，而将Jwt（或JwtId）记录在服务端的分布式缓存，并设置过期时间。然后，在初次进行Jwt校验时，不使用默认的校验器校验过期时间，校验通过后，再与缓存中的过期时间进行比对，如果有效则重置过期时间。该方案确实可行，不过这要求Jwt在有效期内才能进行刷新。

目前使用最广泛的一种方式是引入一个称为

refresh token

的参数。大概流程是在签发

access token

时，同时生成一个

refresh token

，并且

refresh token

的有效期要比

access token

长很多。然后，客户端将两个token都保存下来。当客户端请求服务端使用，若发现服务端返回“access token过期”的错误，那么就加上之前保存下来的

refresh token

请求服务端刷新token，服务端会签发一套全新的

access token

和

refresh token

给客户端。

其中，为了保证

refresh token

的安全性和有效性，除了发送给客户端外，还需要在服务端存储一份，并设置过期时间。这实际上在一定程度上破坏了Jwt的“无状态”性（个人认为可以接受）。

具体代码请参考XXTk.Auth.Samples.JwtBearerWithRefresh.HttpApi

首先，就先定义要返回给客户端的数据类型：

public class AuthTokenDto{// jwt tokenpublic string AccessToken { get; set; }// 用于刷新token的刷新令牌public string RefreshToken { get; set; }}

接下来定义token的服务接口

IAuthTokenService

和服务实现

AuthTokenService

：

public interface IAuthTokenService{Task<AuthTokenDto> CreateAuthTokenAsync(UserDto user);Task<AuthTokenDto> RefreshAuthTokenAsync(AuthTokenDto token);}public class AuthTokenService : IAuthTokenService{private const string RefreshTokenIdClaimType = "refresh_token_id";private readonly JwtBearerOptions _jwtBearerOptions;private readonly JwtOptions _jwtOptions;private readonly SigningCredentials _signingCredentials;private readonly IDistributedCache _distributedCache;private readonly ILogger<AuthTokenService> _logger;public AuthTokenService(IOptionsSnapshot<JwtBearerOptions> jwtBearerOptions,IOptionsSnapshot<JwtOptions> jwtOptions,SigningCredentials signingCredentials,IDistributedCache distributedCache,ILogger<AuthTokenService> logger){_jwtBearerOptions = jwtBearerOptions.Get(JwtBearerDefaults.AuthenticationScheme);_jwtOptions = jwtOptions.Value;_signingCredentials = signingCredentials;_distributedCache = distributedCache;_logger = logger;}}

接下来，我们来实现

CreateAuthTokenAsync

方法：

public async Task<AuthTokenDto> CreateAuthTokenAsync(UserDto user){var result = new AuthTokenDto();// 先创建refresh tokenvar (refreshTokenId, refreshToken) = await CreateRefreshTokenAsync(user.Id);result.RefreshToken = refreshToken;// 再签发Jwtresult.AccessToken = CreateJwtToken(user, refreshTokenId);return result;}private async Task<(string refreshTokenId, string refreshToken)> CreateRefreshTokenAsync(string userId){// refresh token id作为缓存Keyvar tokenId = Guid.NewGuid().ToString("N");// 生成refresh tokenvar rnBytes = new byte[32];using var rng = RandomNumberGenerator.Create();rng.GetBytes(rnBytes);var token = Convert.ToBase64String(rnBytes);// 设置refresh token的过期时间var options = new DistributedCacheEntryOptions();options.SetAbsoluteExpiration(TimeSpan.FromDays(_jwtOptions.RefreshTokenExpiresDays));// 缓存 refresh tokenawait _distributedCache.SetStringAsync(GetRefreshTokenKey(userId, tokenId), token, options);return (tokenId, token);}private string CreateJwtToken(UserDto user, string refreshTokenId){if (user is null) throw new ArgumentNullException(nameof(user));if (string.IsNullOrEmpty(refreshTokenId)) throw new ArgumentNullException(nameof(refreshTokenId));var tokenDescriptor = new SecurityTokenDescriptor{Subject = new ClaimsIdentity(new List<Claim>{new Claim(JwtClaimTypes.Id, user.Id),new Claim(JwtClaimTypes.Name, user.UserName),// 将 refresh token id 记录下来new Claim(RefreshTokenIdClaimType, refreshTokenId)}),Issuer = _jwtBearerOptions.TokenValidationParameters.ValidIssuer,Audience = _jwtBearerOptions.TokenValidationParameters.ValidAudience,Expires = DateTime.UtcNow.AddMinutes(_jwtOptions.AccessTokenExpiresMinutes),SigningCredentials = _signingCredentials,};var handler = _jwtBearerOptions.SecurityTokenValidators.OfType<JwtSecurityTokenHandler>().FirstOrDefault()?? new JwtSecurityTokenHandler();var securityToken = handler.CreateJwtSecurityToken(tokenDescriptor);var token = handler.WriteToken(securityToken);return token;}private string GetRefreshTokenKey(string userId, string refreshTokenId){if (string.IsNullOrEmpty(userId)) throw new ArgumentNullException(nameof(userId));if (string.IsNullOrEmpty(refreshTokenId)) throw new ArgumentNullException(nameof(refreshTokenId));return $"{userId}:{refreshTokenId}";}

下面看一下效果：

接着，实现

RefreshAuthTokenAsync

方法：

public async Task<AuthTokenDto> RefreshAuthTokenAsync(AuthTokenDto token){var validationParameters = _jwtBearerOptions.TokenValidationParameters.Clone();// 不校验生命周期validationParameters.ValidateLifetime = false;var handler = _jwtBearerOptions.SecurityTokenValidators.OfType<JwtSecurityTokenHandler>().FirstOrDefault()?? new JwtSecurityTokenHandler();ClaimsPrincipal principal = null;try{// 先验证一下，jwt是否真的有效principal = handler.ValidateToken(token.AccessToken, validationParameters, out _);}catch (Exception ex){_logger.LogWarning(ex.ToString());throw new BadHttpRequestException("Invalid access token");}var identity = principal.Identities.First();var userId = identity.Claims.FirstOrDefault(c => c.Type == JwtClaimTypes.Id).Value;var refreshTokenId = identity.Claims.FirstOrDefault(c => c.Type == RefreshTokenIdClaimType).Value;var refreshTokenKey = GetRefreshTokenKey(userId, refreshTokenId);var refreshToken = await _distributedCache.GetStringAsync(refreshTokenKey);// 验证refresh token是否有效if (refreshToken != token.RefreshToken){throw new BadHttpRequestException("Invalid refresh token");}// refresh token用过了记得清除掉await _distributedCache.RemoveAsync(refreshTokenKey);// 这里应该是从数据库中根据 userId 获取用户信息var user = new UserDto(){Id = userId,UserName = principal.Identity.Name};return await CreateAuthTokenAsync(user);}

下面看一下效果：

注意：引入刷新令牌后，要记得在用户注销将当前Jwt的刷新令牌清除，或修改密码后将该用户的刷新令牌清空。

最后，解释几个问题：

为什么Jwt中保存了refresh token id？直接保存refresh token不行吗？

保存refresh token id是为了实现一个用户对应多个refresh token，这适用于同一用户在多客户端登录的情况。

不能直接保存refresh token，由于Jwt是明文，所以这容易导致refresh token泄漏，从而导致他人可以在用户不知情的情况下申请access token。
为什么要设计为一个用户对应多个refresh token？

这适用于同一用户在多客户端登录的情况，防止其中一个客户端刷新了token，导致其他客户端无法刷新。

处理不同系统要求Jwt认证信息中存储不同的字段信息

假设有以下场景：商城采购系统和收货系统属于同一电商平台，使用的均是同一套基于JwtBearer的认证方案，现在，收货系统需要在认证信息中新增角色信息和每日最大收货次数信息，便于快速获取。

方案可能多种多样，比如就在Jwt签发时，将角色信息和每日最大收货次数存储到Jwt中，虽然这能够解决问题，但显然会使得Jwt存储很多冗余数据，在系统越来越多的情况下，就显得无法接受。

以下是我所想到的一种较为合理的方案：首先，角色信息较为通用，大部分系统都会用到，所以建议将角色信息加入到Jwt中存储，而对于每日最大收货次数，更倾向于收货系统使用，所以这条信息由收货系统在服务端进行维护，例如以用户Id为Key，记入分布式缓存中。

Jwt+服务端 vs Cookie + Session

很多人会说，我使用Jwt就是因为它的无状态性，既然它也要结合服务端，那我为啥不干脆就使用

Cookie + Session

？

确实，如果你的系统前端是H5，客户端均是浏览器，且后续也基本不可能发生改变，那你可以把扇Jwt俩大耳刮子，并把它踢出家门，因为

Cookie + Session

绝对是你的首选。

但是，如果你的系统包含了H5、小程序、Native App等，由于其中某些客户端不支持Cookie，所以Cookie就丧失了它的优势，此时使用Cookie还是Jwt貌似差别都不大，但是Jwt可以实现自动续租。实际上，我比较推荐的做法是

Jwt + Cookie

，即将Jwt保存在Cookie中，这样，在H5应用中，仍然利用Cookie机制传递认证信息，而在其他不支持Cookie的客户端中，则直接使用Jwt（通过Authorization Header），这样可以保证认证行为的统一。

防止Jwt泄露

文章最后，我们就来看一下如何防止Jwt泄漏吧。

假设Jwt泄露了，那么他人就可以使用你的身份访问服务器进行敏感操作，不过这相对来说，还好，因为Jwt过期了也就失效了。但是，如果refresh token也泄露了，那就会产生更加严重的后果，他人就可以通过refresh token无限制的获取到最新的token。

看完上面这段话，是不是不敢用Jwt了？别怕，任何认证方案都会有导致这种情况出现的可能，例如，通过用户名和密码登录时，不还是在请求过程中有用户名和密码被窃取的可能。

既然没有绝对的安全保护措施，那我们只有尽量让它安全，以下是两点建议：

使用Https协议
设置较短的Jwt有效期

理解ASP.NET Core – 基于JwtBearer的身份认证(Authentication)