亲宝软件园·资讯

展开

.Net Core证授权JwtBearer认证

springsnow 人气:0

一.前言

回顾认证方案之初步认识JWT

在现代Web应用程序中,即分为前端与后端两大部分。当前前后端的趋势日益剧增,前端设备(手机、平板、电脑、及其他设备)层出不穷。因此,为了方便满足前端设备与后端进行通讯,就必须有一种统一的机制。所以导致API架构的流行。而RESTful API这个API设计思想理论也就成为目前互联网应用程序比较欢迎的一套方式。

这种API架构思想的引入,因此,我们就需要考虑用一种标准的,通用的,无状态的,与语言无关的身份认证方式来实现API接口的认证。

HTTP提供了一套标准的身份验证框架:服务端可以用来针对客户端的请求发送质询(challenge),客户端根据质询提供应答身份验证凭证。

质询与应答的工作流程如下:服务端向客户端返回401(Unauthorized,未授权)状态码,并在WWW-Authenticate头中添加如何进行验证的信息,其中至少包含有一种质询方式。然后客户端可以在请求中添加Authorization头进行验证,其Value为身份验证的凭证信息。

在本文中,将要介绍的是以Jwt Bearer方式进行认证。 

二.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认证的核心是Token,Bearer验证中的凭证称为BEARER_TOKEN,或者是access_token,它的颁发和验证完全由我们自己的应用程序来控制,而不依赖于系统和Web服务器,Bearer验证的标准请求方式如下:

Authorization: Bearer [BEARER_TOKEN] 

那么使用Bearer验证有什么好处呢?

三.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的好处在于通用性、紧凑性和可拓展性。

四.开始

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秒,即我们配置的过期时间加上这个允许偏移的时间值,才是真正过期的时间(过期时间 +偏移值)你也可以设置为0,ClockSkew = 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中的IssuerAudience进行对比,不一致则验证失败。

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 ILogger<WeatherForecastController> _logger;

    public WeatherForecastController(ILogger<WeatherForecastController> logger)
    {
        _logger = logger;
    }

    [HttpGet]
    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();
    }
}

3. 生成Token

因为微软为我们内置了JwtBearer验证,但是没有提供Token的发放,所以这里我们要实现生成Token的方法

引入Nugets包:System.IdentityModel.Tokens.Jwt

这里我们根据IdentityModel.Tokens.Jwt文档给我们提供的帮助类,提供了方法WriteToken创建Token,根据参数SecurityToken,可以实例化,JwtSecurityToken,指定可选参数的类。

新增AuthController.cs控制器:

    [HttpGet]
    public IActionResult GetToken()
    {
        try
        {
            //定义发行人issuer
            string iss = "JWTBearer.Auth";
            //定义受众人audience
            string aud = "api.auth";

            //定义许多种的声明Claim,信息存储部分,Claims的实体一般包含用户和一些元数据
            IEnumerable<Claim> 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;
        }
    }
注意:
SecurityKey 的长度必须 大于等于 16个字符,否则生成会报错。(可通过在线随机生成密钥)

五. 运行

访问获取Token方法,获取得到access_token:

再访问,授权资源接口,可以发现,再没有添加请求头token值的情况下,返回了401没有权限。

这次,在请求头通过Authorization加上之前获取的token值后,再次进行访问,发现已经可以获取访问资源控制器,并返回对应的数据。

六.扩展说明

在HTTP标准验证方案中,我们比较熟悉的是"Basic"和"Digest",前者将用户名密码使用BASE64编码后作为验证凭证,后者是Basic的升级版,更加安全,因为Basic是明文传输密码信息,而Digest是加密后传输。

1、Basic基础认证

Basic认证是一种较为简单的HTTP认证方式,客户端通过明文(Base64编码格式)传输用户名和密码到服务端进行认证,通常需要配合HTTPS来保证信息传输的安全。

客户端请求需要带Authorization请求头,值为“Basic xxx”,xxx为“用户名:密码”进行Base64编码后生成的值。 若客户端是浏览器,则浏览器会提供一个输入用户名和密码的对话框,用户输入用户名和密码后,浏览器会保存用户名和密码,用于构造Authorization值。当关闭浏览器后,用户名和密码将不再保存。

凭证为“YWxhzGRpbjpvcGVuc2VzYWl1”,是通过将“用户名:密码”格式的字符串经过的Base64编码得到的。而Base64不属于加密范畴,可以被逆向解码,等同于明文,因此Basic传输认证信息是不安全的。

Basic基础认证图示:

缺陷汇总

2、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认证图示:

七.注意

八.总结

本示例源码地址 
参考JwtBearer源码

到此这篇关于基于.Net Core认证授权方案之JwtBearer认证的文章就介绍到这了。希望对大家的学习有所帮助,也希望大家多多支持。

加载全部内容

相关教程
猜你喜欢
用户评论