什么是JWT？
Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（(RFC 7519).该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。
什么时候应该使用JWT？
以下是JSON Web令牌有用的一些情况：
- 授权：这是使用JWT的最常见方案。一旦用户登录，每个后续请求将包括JWT，从而允许用户访问该令牌允许的路由，服务和资源。单一登录是当今广泛使用JWT的一项功能，因为它的开销很小并且可以在不同的域中轻松使用。
- 信息交换：JSON Web令牌是在各方之间安全传输信息的好方法。因为可以对JWT进行签名（例如，使用公钥/私钥对），所以您可以确定发件人是他们所说的人。此外，由于签名是使用标头和有效负载计算的，因此您还可以验证内容是否未被篡改。
JWT结构是什么？
第一部分我们称它为头部（header),第二部分我们称其为载荷（payload, 类似于飞机上承载的物品)，第三部分是签证（signature).
header
jwt的头部承载两部分信息：
- 声明类型，这里是jwt
- 声明加密的算法 通常直接使用 HMAC SHA256
完整的头部就像下面这样的JSON： { 'typ': 'JWT', 'alg': 'HS256' } 然后将头部进行base64加密（该加密是可以对称解密的),构成了第一部分. eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
playload
载荷就是存放有效信息的地方。这个名字像是特指飞机上承载的货品，这些有效信息包含三个部分
- 标准中注册的声明
- 公共的声明
- 私有的声明
标准中注册的声明 (建议但不强制使用) ：
- iss: jwt签发者
- sub: jwt所面向的用户
- aud: 接收jwt的一方
- exp: jwt的过期时间，这个过期时间必须要大于签发时间
- nbf: 定义在什么时间之前，该jwt都是不可用的.
- iat: jwt的签发时间
- jti: jwt的唯一身份标识，主要用来作为一次性token,从而回避重放入侵。
公共的声明 ： 公共的声明可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息.但不建议添加敏感信息，因为该部分在客户端可解密. 私有的声明 ： 私有声明是提供者和消费者所共同定义的声明，一般不建议存放敏感信息，因为base64是对称解密的，意味着该部分信息可以归类为明文信息。 定义一个payload: { "sub": "1234567890", "name": "John Doe", "admin": true } 然后将其进行base64加密，得到Jwt的第二部分。 eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9
signature
jwt的第三部分是一个签证信息，这个签证信息由三部分组成：
- header (base64后的)
- payload (base64后的)
- secret
这个部分需要base64加密后的header和base64加密后的payload使用.连接组成的字符串，然后通过header中声明的加密方式进行加盐secret组合加密，然后就构成了jwt的第三部分。 // javascript var encodedString = base64UrlEncode(header) + '.' + base64UrlEncode(payload); var signature = HMACSHA256(encodedString, 'secret'); // TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ 将这三部分用.连接成一个完整的字符串,构成了最终的jwt: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ 注意：secret是保存在服务器端的，jwt的签发生成也是在服务器端的，secret就是用来进行jwt的签发和jwt的验证，所以，它就是你服务端的私钥，在任何场景都不应该流露出去。一旦客户端得知这个secret, 那就意味着客户端是可以自我签发jwt了。
如何使用JWT
每当用户想要访问受保护的路由或资源时，用户代理都应发送JWT，通常使用承载模式在Authorization标头中发送JWT 。标头的内容应如下所示：
Authorization: Bearer <token>
在某些情况下，这可以是无状态授权机制。服务器的受保护路由将在Authorization标头中检查有效的JWT ，如果存在，则将允许用户访问受保护的资源。如果JWT包含必要的数据，则可以减少查询数据库中某些操作的需求，尽管这种情况并非总是如此。
如果令牌是在Authorization标头中发送的，则跨域资源共享（CORS）不会成为问题，因为它不使用cookie。
下图显示了如何获取JWT并将其用于访问API或资源：
- 应用程序或客户端向授权服务器请求授权。这是通过不同的授权流程之一执行的。例如，典型的符合OpenID Connect的Web应用程序将/oauth/authorize使用授权代码流通过端点。
- 授予授权后，授权服务器会将访问令牌返回给应用程序。
- 该应用程序使用访问令牌来访问受保护的资源（例如API）。
请注意，使用签名的令牌，令牌中包含的所有信息都会暴露给用户或其他方，即使他们无法更改它。这意味着您不应将机密信息放入令牌中。
.net core的JWT验证授权
新建一个.net core webapi的项目，版本可选择3.1 +
- 先使用nuget安装：Microsoft.AspNetCore.Authentication.JwtBearer。注意版本和.net core版本的兼容。net5的支持5.0.0+的版本，否则就用对应可以用的低版本吧。
- 在appsettings.json配置文件中写好我们的 JWT 的配置参数如下：
"JwtSettings": {
"Secret": "your-256-bit-secret",
"Iss": "https://localhost:45000",
"Aud": "api"
}
- 在Startup.cs的ConfigureServices方法中添加授权认证如下：
var jwtConfig = Configuration.GetSection("JwtSettings");
//生成密钥
var symmetricKeyAsBase64 = jwtConfig.GetValue<string>("Secret");
var keyByteArray = Encoding.ASCII.GetBytes(symmetricKeyAsBase64);
var signingKey = new SymmetricSecurityKey(keyByteArray);
//认证参数
services.AddAuthentication("Bearer")
.AddJwtBearer(o =>
{
o.TokenValidationParameters = new TokenValidationParameters
{
ValidateIssuerSigningKey = true,//是否验证签名,不验证的画可以篡改数据，不安全
IssuerSigningKey = signingKey,//解密的密钥
ValidateIssuer = true,//是否验证发行人，就是验证载荷中的Iss是否对应ValidIssuer参数
ValidIssuer = jwtConfig.GetValue<string>("Iss"),//发行人
ValidateAudience = true,//是否验证订阅人，就是验证载荷中的Aud是否对应ValidAudience参数
ValidAudience = jwtConfig.GetValue<string>("Aud"),//订阅人
ValidateLifetime = true,//是否验证过期时间，过期了就拒绝访问
ClockSkew = TimeSpan.Zero,//这个是缓冲过期时间，也就是说，即使我们配置了过期时间，这里也要考虑进去，过期时间+缓冲，默认好像是7分钟，你可以直接设置为0
RequireExpirationTime = true,
};
});
在Configure方法中添加 app.UseAuthentication() 和 app.UseAuthorization() 注意位置需要放置的位置：
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
if (env.IsDevelopment()){app.UseDeveloperExceptionPage();}
app.UseHttpsRedirection();
app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();
app.UseEndpoints(endpoints =>{ endpoints.MapControllers();});
}
- 生成jwt令牌，在默认生成的控制器 WeatherForecastController 中添加如下生成令牌的方法：
[HttpPost]
public IActionResult Authenticate()
{
var jwtConfig = Configuration.GetSection("Jwt");
//秘钥，就是标头，这里用Hmacsha256算法，需要256bit的密钥
var securityKey = new SigningCredentials(new SymmetricSecurityKey(Encoding.ASCII.GetBytes(jwtConfig.GetValue<string>("Secret"))), SecurityAlgorithms.HmacSha256);
//Claim，JwtRegisteredClaimNames中预定义了好多种默认的参数名，也可以像下面的Guid一样自己定义键名.
//ClaimTypes也预定义了好多类型如role、email、name。Role用于赋予权限，不同的角色可以访问不同的接口
//相当于有效载荷
var claims = new Claim[] {
new Claim(JwtRegisteredClaimNames.Iss,jwtConfig.GetValue<string>("Iss")),
new Claim(JwtRegisteredClaimNames.Aud,jwtConfig.GetValue<string>("Aud")),
new Claim("Guid",Guid.NewGuid().ToString("D")),
// 这里定义了admin 和 system 的角色
new Claim(ClaimTypes.Role,"system"),
new Claim(ClaimTypes.Role,"admin"),
};
SecurityToken securityToken = new JwtSecurityToken(
signingCredentials: securityKey,
expires: DateTime.Now.AddMinutes(1),//过期时间
claims: claims
);
//生成jwt令牌
return Content(new JwtSecurityTokenHandler().WriteToken(securityToken));
}
- 使用jwt控制接口的访问，我们在一个接口上添加一个特性 [Authorize(Roles ="admin")]，表示需要有admin这个角色的jwt令牌才能访问，没有roles参数的话表示只要是可用的令牌就可以访问，多个role角色可以叠加多个特性：
[HttpGet]
[Authorize(Roles = "admin")]
[Authorize(Roles = "system")]
public IEnumerable<WeatherForecast> Get()
{
var rng = new Random();
return Enumerable.Range(1, 5).Select(index => new WeatherForecast
{
Date = DateTime.Now.AddDays(index),
TemperatureC = rng.Next(-20, 55),
Summary = Summaries[rng.Next(Summaries.Length)]
})
.ToArray();
}
6.测试,然后我们用postman就可以测试了，可以看到非常成功有数据。
补充：
如果一个接口提供给很多的角色访问，那特性[Authorize]会写很多或者很长，也非常的麻烦，所以可以对不同的角色建立不同的策略，只需要在starup.cs中添加角色策略如下：
services.AddAuthorization(option => { option.AddPolicy("adminOrSystem", policy => policy.RequireRole("admin", "system")); });
之后赋值特性[Authorize]的Policy参数即可：
[Authorize(Policy = "adminOrSystem")]