网站建设实验报告手写,做网站如何挣钱,山西营销网站建设联系方式,网上怎么免费推广1.前言回顾#xff1a;认证方案之初步认识JWT在现代Web应用程序中#xff0c;即分为前端与后端两大部分。当前前后端的趋势日益剧增#xff0c;前端设备#xff08;手机、平板、电脑、及其他设备#xff09;层出不穷。因此#xff0c;为了方便满足前端设备与后端进行通讯… 1.前言回顾认证方案之初步认识JWT在现代Web应用程序中即分为前端与后端两大部分。当前前后端的趋势日益剧增前端设备手机、平板、电脑、及其他设备层出不穷。因此为了方便满足前端设备与后端进行通讯就必须有一种统一的机制。所以导致API架构的流行。而RESTful API这个API设计思想理论也就成为目前互联网应用程序比较欢迎的一套方式。这种API架构思想的引入因此我们就需要考虑用一种标准的通用的无状态的与语言无关的身份认证方式来实现API接口的认证。HTTP提供了一套标准的身份验证框架服务端可以用来针对客户端的请求发送质询(challenge)客户端根据质询提供应答身份验证凭证。质询与应答的工作流程如下服务端向客户端返回401Unauthorized未授权状态码并在WWW-Authenticate头中添加如何进行验证的信息其中至少包含有一种质询方式。然后客户端可以在请求中添加Authorization头进行验证其Value为身份验证的凭证信息。在本文中将要介绍的是以Jwt Bearer方式进行认证。2.Bearer认证本文要介绍的Bearer验证也属于HTTP协议标准验证它随着OAuth协议而开始流行详细定义见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 ---| |-------- ---------------A security token with the property that any party in possession of the token (a bearer) can use the token in any way that any other party in possession of it can. Using a bearer token does not require a bearer to prove possession of cryptographic key material (proof-of-possession).因此Bearer认证的核心是TokenBearer验证中的凭证称为BEARER_TOKEN或者是access_token它的颁发和验证完全由我们自己的应用程序来控制而不依赖于系统和Web服务器Bearer验证的标准请求方式如下Authorization: Bearer [BEARER_TOKEN]那么使用Bearer验证有什么好处呢CORS: cookies CORS 并不能跨不同的域名。而Bearer验证在任何域名下都可以使用HTTP header头部来传输用户信息。对移动端友好: 当你在一个原生平台(iOS, Android, WindowsPhone等)时使用Cookie验证并不是一个好主意因为你得和Cookie容器打交道而使用Bearer验证则简单的多。CSRF: 因为Bearer验证不再依赖于cookies, 也就避免了跨站请求攻击。标准在Cookie认证中用户未登录时返回一个302到登录页面这在非浏览器情况下很难处理而Bearer验证则返回的是标准的401 challenge。3.JWT上面介绍的Bearer认证其核心便是BEARER_TOKEN那么如何确保Token的安全是重中之重。一种是通过HTTPS的方式另一种是通过对Token进行加密编码签名而最流行的Token编码签名方式便是JSON WEB TOKEN。Json web token (Jwt), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准RFC 7519。该token被设计为紧凑且安全的特别适用于分布式站点的单点登录SSO场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息以便于从资源服务器获取资源也可以增加一些额外的其它业务逻辑所必须的声明信息该token也可直接被用于认证也可被加密。JWT是由.分割的如下三部分组成Header.Payload.Signature还记得之前说个的一篇认证方案之初步认识JWT吗没有的可以看看对JWT的特点和基本原理介绍可以进一步的了解。学习了之前的文章后我们可以发现使用JWT的好处在于通用性、紧凑性和可拓展性。通用性因为json的通用性所以JWT是可以进行跨语言支持的像JAVA,JavaScript,NodeJS,PHP等很多语言都可以使用。紧凑性JWT的构成非常简单字节占用很小通过 GET、POST 等放在 HTTP 的 header 中便于传输。可扩展性JWT是自我包涵的因为有了payload部分包含了必要的一些其他业务逻辑所必要的非敏感信息自身存储不需要在服务端保存会话信息, 非常易于应用的扩展。4.开始1. 注册认证服务在这里我们用微软给我们提供的JwtBearer认证方式实现认证服务注册 。引入nuget包Microsoft.AspNetCore.Authentication.JwtBearer注册服务将服务添加到容器中 public void ConfigureServices(IServiceCollection services){services.AddControllers();var Issurer JWTBearer.Auth; //发行人var Audience api.auth; //受众人var secretCredentials q2xiARx$4x3TKqBJ; //密钥//配置认证服务services.AddAuthentication(x {x.DefaultAuthenticateScheme JwtBearerDefaults.AuthenticationScheme;x.DefaultChallengeScheme JwtBearerDefaults.AuthenticationScheme;}).AddJwtBearer(o{o.TokenValidationParameters new TokenValidationParameters{//是否验证发行人ValidateIssuer true,ValidIssuer Issurer,//发行人//是否验证受众人ValidateAudience true,ValidAudience Audience,//受众人//是否验证密钥ValidateIssuerSigningKey true,IssuerSigningKey new SymmetricSecurityKey(Encoding.ASCII.GetBytes(secretCredentials)),ValidateLifetime true, //验证生命周期RequireExpirationTime true, //过期时间};});}注意说明一. TokenValidationParameters的参数默认值
1. ValidateAudience true, ----- 如果设置为false,则不验证Audience受众人
2. ValidateIssuer true , ----- 如果设置为false,则不验证Issuer发布人但建议不建议这样设置
3. ValidateIssuerSigningKey false,
4. ValidateLifetime true, ----- 是否验证Token有效期使用当前时间与Token的Claims中的NotBefore和Expires对比
5. RequireExpirationTime true, ----- 是否要求Token的Claims中必须包含Expires
6. ClockSkew TimeSpan.FromSeconds(300), ----- 允许服务器时间偏移量300秒即我们配置的过期时间加上这个允许偏移的时间值才是真正过期的时间(过期时间 偏移值)你也可以设置为0ClockSkew TimeSpan.Zero调用方法配置Http请求管道 public void Configure(IApplicationBuilder app, IWebHostEnvironment env){if (env.IsDevelopment()){app.UseDeveloperExceptionPage();}app.UseRouting();//1.先开启认证app.UseAuthentication();//2.再开启授权app.UseAuthorization();app.UseEndpoints(endpoints {endpoints.MapControllers();});}在JwtBearerOptions的配置中通常IssuerSigningKey(签名秘钥), ValidIssuer(Token颁发机构), ValidAudience(颁发给谁) 三个参数是必须的后两者用于与TokenClaims中的Issuer和Audience进行对比不一致则验证失败。2.接口资源保护创建一个需要授权保护的资源控制器这里我们用建立API生成项目自带的控制器WeatherForecastController.cs, 在控制器上使用Authorize即可[ApiController]
[Route([controller])]
[Authorize]
public class WeatherForecastController : ControllerBase
{private static readonly string[] Summaries new[]{Freezing, Bracing, Chilly, Cool, Mild, Warm, Balmy, Hot, Sweltering, Scorching};private readonly ILoggerWeatherForecastController _logger;public WeatherForecastController(ILoggerWeatherForecastController logger){_logger logger;}[HttpGet]public IEnumerableWeatherForecast 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();}
}3. 生成Token因为微软为我们内置了JwtBearer验证但是没有提供Token的发放所以这里我们要实现生成Token的方法引入Nugets包System.IdentityModel.Tokens.Jwt这里我们根据IdentityModel.Tokens.Jwt文档给我们提供的帮助类提供了方法WriteToken创建Token根据参数SecurityToken可以实例化JwtSecurityToken指定可选参数的类。 /// summary/// Initializes a new instance of the see crefJwtSecurityToken/ class specifying optional parameters./// /summary/// param nameissuerIf this value is not null, a { iss, issuer } claim will be added, overwriting any iss claim in claims if present./param/// param nameaudienceIf this value is not null, a { aud, audience } claim will be added, appending to any aud claims in claims if present./param/// param nameclaimsIf this value is not null then for each see crefClaim/ a { Claim.Type, Claim.Value } is added. If duplicate claims are found then a { Claim.Type, Listlt;objectgt; } will be created to contain the duplicate values./param/// param nameexpiresIf expires.HasValue a { exp, value } claim is added, overwriting any exp claim in claims if present./param/// param namenotBeforeIf notbefore.HasValue a { nbf, value } claim is added, overwriting any nbf claim in claims if present./param/// param namesigningCredentialsThe see crefSigningCredentials/ that will be used to sign the see crefJwtSecurityToken/. See see crefJwtHeader(SigningCredentials)/ for details pertaining to the Header Parameter(s)./param/// exception crefArgumentExceptionIf expires lt; notbefore./exceptionpublic JwtSecurityToken(string issuer null, string audience null, IEnumerableClaim claims null, DateTime? notBefore null, DateTime? expires null, SigningCredentials signingCredentials null){if (expires.HasValue notBefore.HasValue){if (notBefore expires)throw LogHelper.LogExceptionMessage(new ArgumentException(LogHelper.FormatInvariant(LogMessages.IDX12401, expires.Value, notBefore.Value)));}Payload new JwtPayload(issuer, audience, claims, notBefore, expires);Header new JwtHeader(signingCredentials);RawSignature string.Empty;}这样我们可以根据参数指定内容1. string iss JWTBearer.Auth; // 定义发行人
2. string aud api.auth; //定义受众人audience
3. IEnumerableClaim claims new Claim[]
{
new Claim(JwtClaimTypes.Id,1),
new Claim(JwtClaimTypes.Name,i3yuan),
};//定义许多种的声明Claim,信息存储部分,Claims的实体一般包含用户和一些元数据
4. var nbf DateTime.UtcNow; //notBefore 生效时间
5. var Exp DateTime.UtcNow.AddSeconds(1000); //expires 过期时间
6. string sign q2xiARx$4x3TKqBJ; //SecurityKey 的长度必须 大于等于 16个字符var secret Encoding.UTF8.GetBytes(sign);var key new SymmetricSecurityKey(secret);var signcreds new SigningCredentials(key, SecurityAlgorithms.HmacSha256);好了通过以上填充参数内容进行传参赋值得到完整代码如下新增AuthController.cs控制器 [HttpGet]public IActionResult GetToken(){try{//定义发行人issuerstring iss JWTBearer.Auth;//定义受众人audiencestring aud api.auth;//定义许多种的声明Claim,信息存储部分,Claims的实体一般包含用户和一些元数据IEnumerableClaim claims new Claim[]{new Claim(JwtClaimTypes.Id,1),new Claim(JwtClaimTypes.Name,i3yuan),};//notBefore 生效时间// long nbf new DateTimeOffset(DateTime.Now).ToUnixTimeSeconds();var nbf DateTime.UtcNow;//expires //过期时间// long Exp new DateTimeOffset(DateTime.Now.AddSeconds(1000)).ToUnixTimeSeconds();var Exp DateTime.UtcNow.AddSeconds(1000);//signingCredentials 签名凭证string sign q2xiARx$4x3TKqBJ; //SecurityKey 的长度必须 大于等于 16个字符var secret Encoding.UTF8.GetBytes(sign);var key new SymmetricSecurityKey(secret);var signcreds new SigningCredentials(key, SecurityAlgorithms.HmacSha256);var jwt new JwtSecurityToken(issuer: iss, audience: aud, claims:claims,notBefore:nbf,expires:Exp, signingCredentials: signcreds);var JwtHander new JwtSecurityTokenHandler();var token JwtHander.WriteToken(jwt);return Ok(new{access_token token,token_type Bearer,});}catch (Exception ex){throw;}}注意
1.SecurityKey 的长度必须 大于等于 16个字符否则生成会报错。可通过在线随机生成密钥5. 运行访问获取Token方法获取得到access_token:再访问授权资源接口可以发现再没有添加请求头token值的情况下返回了401没有权限。这次在请求头通过Authorization加上之前获取的token值后再次进行访问发现已经可以获取访问资源控制器并返回对应的数据。6.扩展说明在HTTP标准验证方案中我们比较熟悉的是Basic和Digest前者将用户名密码使用BASE64编码后作为验证凭证后者是Basic的升级版更加安全因为Basic是明文传输密码信息而Digest是加密后传输。一、Basic基础认证Basic认证是一种较为简单的HTTP认证方式客户端通过明文Base64编码格式传输用户名和密码到服务端进行认证通常需要配合HTTPS来保证信息传输的安全。客户端请求需要带Authorization请求头值为“Basic xxx”xxx为“用户名:密码”进行Base64编码后生成的值。若客户端是浏览器则浏览器会提供一个输入用户名和密码的对话框用户输入用户名和密码后浏览器会保存用户名和密码用于构造Authorization值。当关闭浏览器后用户名和密码将不再保存。凭证为“YWxhzGRpbjpvcGVuc2VzYWl1”是通过将“用户名:密码”格式的字符串经过的Base64编码得到的。而Base64不属于加密范畴可以被逆向解码等同于明文因此Basic传输认证信息是不安全的。Basic基础认证图示缺陷汇总1.用户名和密码明文Base64传输需要配合HTTPS来保证信息传输的安全。2.即使密码被强加密第三方仍可通过加密后的用户名和密码进行重放攻击。3.没有提供任何针对代理和中间节点的防护措施。4.假冒服务器很容易骗过认证诱导用户输入用户名和密码。二、Digest摘要认证Digest认证是为了修复基本认证协议的严重缺陷而设计的秉承“绝不通过明文在网络发送密码”的原则通过“密码摘要”进行认证大大提高了安全性。Digest认证步骤如下第一步客户端访问Http资源服务器。由于需要Digest认证服务器返回了两个重要字段nonce随机数和realm。第二步客户端构造Authorization请求头值包含username、realm、nouce、uri和response的字段信息。其中realm和nouce就是第一步返回的值。nouce只能被服务端使用一次。uri(digest-uri)即Request-URI的值但考虑到经代理转发后Request-URI的值可能被修改、因此实现会复制一份副本保存在uri内。response也可叫做Request-digest存放经过MD5运算后的密码字符串形成响应码。第三步服务器验证包含Authorization值的请求若验证通过则可访问资源。Digest认证可以防止密码泄露和请求重放但没办法防假冒。所以安全级别较低。Digest和Basic认证一样每次都会发送Authorization请求头也就相当于重新构造此值。所以两者易用性都较差。Digest认证图示7.注意在进行JwtBearer认证时在生成token之后还需要与刷新token配合使用因为当用户执行了退出修改密码等操作时需要让该token无效无法再次使用所以会给access_token设置一个较短的有效期间(JwtBearer认证默认会验证有效期通过notBefore和expires来验证)当access_token过期后可以在用户无感知的情况下使用refresh_token重新获取access_token但这就不属于Bearer认证的范畴了但是我们可以通过另一种方式通过IdentityServer的方式来实现在后续中会对IdentityServer进行详细讲解。在生成token的时候需要用的secret主要是用来防止token被伪造与篡改。因为当token被劫取的时候可以得到你的令牌中带的一些个人不重要的信息明文但不用担心只要你不在生成token里把私密的个人信息放出去的话就算被动机不良的人得到也做不了什么事情。但是你可能会想如果用户自己随便的生成一个 token 带上你的信息那不就可以随便访问你的资源服务器了因此这个时候就需要利用secret 来生成 token来确保数字签名的正确性。而且在认证授权资源进行token解析的时候通过微软的源码发现已经帮我们封装了方法对secret进行了校验了确保了token的安全性从而保证api资源的安全。8.总结JwtToken在认证时无需Security token service安全令牌服务器的参与都是基于Claim的默认会验证有效期通过notBefore和expires来验证这在分布式中提供给了极大便利。JwtToken与平台、无言无关在前端也可以直接解析出Claims。如果有不对的或不理解的地方希望大家可以多多指正提出问题一起讨论,不断学习,共同进步。后面会对认证授权方案中的授权这一块进行说明分享。参考JwtBearer源码往期精彩回顾
