1.前言

回顧：認(rèn)證方案之初步認(rèn)識JWT

在現(xiàn)代Web應(yīng)用程序中，即分為前端與后端兩大部分。當(dāng)前前后端的趨勢日益劇增，前端設(shè)備（手機(jī)、平板、電腦、及其他設(shè)備）層出不窮。因此，為了方便滿足前端設(shè)備與后端進(jìn)行通訊，就必須有一種統(tǒng)一的機(jī)制。所以導(dǎo)致API架構(gòu)的流行。而RESTful API這個(gè)API設(shè)計(jì)思想理論也就成為目前互聯(lián)網(wǎng)應(yīng)用程序比較歡迎的一套方式。

這種API架構(gòu)思想的引入，因此，我們就需要考慮用一種標(biāo)準(zhǔn)的，通用的，無狀態(tài)的，與語言無關(guān)的身份認(rèn)證方式來實(shí)現(xiàn)API接口的認(rèn)證。

HTTP提供了一套標(biāo)準(zhǔn)的身份驗(yàn)證框架：服務(wù)端可以用來針對客戶端的請求發(fā)送質(zhì)詢(challenge)，客戶端根據(jù)質(zhì)詢提供應(yīng)答身份驗(yàn)證憑證。

質(zhì)詢與應(yīng)答的工作流程如下：服務(wù)端向客戶端返回401（Unauthorized，未授權(quán)）狀態(tài)碼，并在WWW-Authenticate頭中添加如何進(jìn)行驗(yàn)證的信息，其中至少包含有一種質(zhì)詢方式。然后客戶端可以在請求中添加Authorization頭進(jìn)行驗(yàn)證，其Value為身份驗(yàn)證的憑證信息。

在本文中，將要介紹的是以Jwt Bearer方式進(jìn)行認(rèn)證。

2.Bearer認(rèn)證

本文要介紹的Bearer驗(yàn)證也屬于HTTP協(xié)議標(biāo)準(zhǔn)驗(yàn)證，它隨著OAuth協(xié)議而開始流行，詳細(xì)定義見：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認(rèn)證的核心是Token，Bearer驗(yàn)證中的憑證稱為BEARER_TOKEN，或者是access_token，它的頒發(fā)和驗(yàn)證完全由我們自己的應(yīng)用程序來控制，而不依賴于系統(tǒng)和Web服務(wù)器，Bearer驗(yàn)證的標(biāo)準(zhǔn)請求方式如下：

Authorization: Bearer [BEARER_TOKEN]

那么使用Bearer驗(yàn)證有什么好處呢？

• CORS: cookies + CORS 并不能跨不同的域名。而Bearer驗(yàn)證在任何域名下都可以使用HTTP header頭部來傳輸用戶信息。

• 對移動(dòng)端友好: 當(dāng)你在一個(gè)原生平臺(iOS, Android, WindowsPhone等)時(shí)，使用Cookie驗(yàn)證并不是一個(gè)好主意，因?yàn)槟愕煤虲ookie容器打交道，而使用Bearer驗(yàn)證則簡單的多。

• CSRF: 因?yàn)锽earer驗(yàn)證不再依賴于cookies, 也就避免了跨站請求攻擊。

• 標(biāo)準(zhǔn)：在Cookie認(rèn)證中，用戶未登錄時(shí)，返回一個(gè)302到登錄頁面，這在非瀏覽器情況下很難處理，而Bearer驗(yàn)證則返回的是標(biāo)準(zhǔn)的401 challenge。

3.JWT

上面介紹的Bearer認(rèn)證，其核心便是BEARER_TOKEN，那么，如何確保Token的安全是重中之重。一種是通過HTTPS的方式，另一種是通過對Token進(jìn)行加密編碼簽名，而最流行的Token編碼簽名方式便是：JSON WEB TOKEN。

Json web token (Jwt), 是為了在網(wǎng)絡(luò)應(yīng)用環(huán)境間傳遞聲明而執(zhí)行的一種基于JSON的開放標(biāo)準(zhǔn)（RFC 7519）。該token被設(shè)計(jì)為緊湊且安全的，特別適用于分布式站點(diǎn)的單點(diǎn)登錄（SSO）場景。JWT的聲明一般被用來在身份提供者和服務(wù)提供者間傳遞被認(rèn)證的用戶身份信息，以便于從資源服務(wù)器獲取資源，也可以增加一些額外的其它業(yè)務(wù)邏輯所必須的聲明信息，該token也可直接被用于認(rèn)證，也可被加密。

JWT是由.分割的如下三部分組成：

Header.Payload.Signature

還記得之前說個(gè)的一篇認(rèn)證方案之初步認(rèn)識JWT嗎？沒有的，可以看看，對JWT的特點(diǎn)和基本原理介紹，可以進(jìn)一步的了解。

學(xué)習(xí)了之前的文章后，我們可以發(fā)現(xiàn)使用JWT的好處在于通用性、緊湊性和可拓展性。

• 通用性：因?yàn)閖son的通用性，所以JWT是可以進(jìn)行跨語言支持的，像JAVA,JavaScript,NodeJS,PHP等很多語言都可以使用。

• 緊湊性：JWT的構(gòu)成非常簡單，字節(jié)占用很小，通過 GET、POST 等放在 HTTP 的 header 中，便于傳輸。

• 可擴(kuò)展性：JWT是自我包涵的，因?yàn)橛辛藀ayload部分，包含了必要的一些其他業(yè)務(wù)邏輯所必要的非敏感信息，自身存儲，不需要在服務(wù)端保存會話信息, 非常易于應(yīng)用的擴(kuò)展。

4.開始

1. 注冊認(rèn)證服務(wù)

在這里，我們用微軟給我們提供的JwtBearer認(rèn)證方式，實(shí)現(xiàn)認(rèn)證服務(wù)注冊 。

引入nuget包：Microsoft.AspNetCore.Authentication.JwtBearer

注冊服務(wù)，將服務(wù)添加到容器中，

? ?public void ConfigureServices(IServiceCollection services){services.AddControllers();var Issurer = "JWTBearer.Auth"; ?//發(fā)行人var Audience = "api.auth"; ? ? ? //受眾人var secretCredentials = "q2xiARx$4x3TKqBJ"; ? //密鑰//配置認(rèn)證服務(wù)services.AddAuthentication(x =>{x.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;x.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;}).AddJwtBearer(o=>{o.TokenValidationParameters = new TokenValidationParameters{//是否驗(yàn)證發(fā)行人ValidateIssuer = true,ValidIssuer = Issurer,//發(fā)行人//是否驗(yàn)證受眾人ValidateAudience = true,ValidAudience = Audience,//受眾人//是否驗(yàn)證密鑰ValidateIssuerSigningKey = true,IssuerSigningKey = new SymmetricSecurityKey(Encoding.ASCII.GetBytes(secretCredentials)),ValidateLifetime = true, //驗(yàn)證生命周期RequireExpirationTime = true, //過期時(shí)間};});}

注意說明：

一. TokenValidationParameters的參數(shù)默認(rèn)值： 1. ValidateAudience = true, ----- 如果設(shè)置為false,則不驗(yàn)證Audience受眾人 2. ValidateIssuer = true , ? ----- 如果設(shè)置為false,則不驗(yàn)證Issuer發(fā)布人，但建議不建議這樣設(shè)置 3. ValidateIssuerSigningKey = false, 4. ValidateLifetime = true, ----- 是否驗(yàn)證Token有效期，使用當(dāng)前時(shí)間與Token的Claims中的NotBefore和Expires對比 5. RequireExpirationTime = true, ----- 是否要求Token的Claims中必須包含Expires 6. ClockSkew = TimeSpan.FromSeconds(300), ----- 允許服務(wù)器時(shí)間偏移量300秒，即我們配置的過期時(shí)間加上這個(gè)允許偏移的時(shí)間值，才是真正過期的時(shí)間(過期時(shí)間 +偏移值)你也可以設(shè)置為0，ClockSkew = TimeSpan.Zero

調(diào)用方法，配置Http請求管道：

? ?public void Configure(IApplicationBuilder app, IWebHostEnvironment env){if (env.IsDevelopment()){app.UseDeveloperExceptionPage();}app.UseRouting();//1.先開啟認(rèn)證app.UseAuthentication();//2.再開啟授權(quán)app.UseAuthorization();app.UseEndpoints(endpoints =>{endpoints.MapControllers();});}

在JwtBearerOptions的配置中，通常IssuerSigningKey(簽名秘鑰), ValidIssuer(Token頒發(fā)機(jī)構(gòu)), ValidAudience(頒發(fā)給誰) 三個(gè)參數(shù)是必須的，后兩者用于與TokenClaims中的Issuer和Audience進(jìn)行對比，不一致則驗(yàn)證失敗。

2.接口資源保護(hù)

創(chuàng)建一個(gè)需要授權(quán)保護(hù)的資源控制器，這里我們用建立API生成項(xiàng)目自帶的控制器，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

因?yàn)槲④洖槲覀儍?nèi)置了JwtBearer驗(yàn)證，但是沒有提供Token的發(fā)放，所以這里我們要實(shí)現(xiàn)生成Token的方法

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

這里我們根據(jù)IdentityModel.Tokens.Jwt文檔給我們提供的幫助類，提供了方法WriteToken創(chuàng)建Token，根據(jù)參數(shù)SecurityToken，可以實(shí)例化，JwtSecurityToken，指定可選參數(shù)的類。

? ? ? ?/// <summary>/// Initializes a new instance of the <see cref="JwtSecurityToken"/> class specifying optional parameters./// </summary>/// <param name="issuer">If this value is not null, a { iss, 'issuer' } claim will be added, overwriting any 'iss' claim in 'claims' if present.</param>/// <param name="audience">If this value is not null, a { aud, 'audience' } claim will be added, appending to any 'aud' claims in 'claims' if present.</param>/// <param name="claims">If this value is not null then for each <see cref="Claim"/> a { 'Claim.Type', 'Claim.Value' } is added. If duplicate claims are found then a { 'Claim.Type', List&lt;object&gt; } will be created to contain the duplicate values.</param>/// <param name="expires">If expires.HasValue a { exp, 'value' } claim is added, overwriting any 'exp' claim in 'claims' if present.</param>/// <param name="notBefore">If notbefore.HasValue a { nbf, 'value' } claim is added, overwriting any 'nbf' claim in 'claims' if present.</param>/// <param name="signingCredentials">The <see cref="SigningCredentials"/> that will be used to sign the <see cref="JwtSecurityToken"/>. See <see cref="JwtHeader(SigningCredentials)"/> for details pertaining to the Header Parameter(s).</param>/// <exception cref="ArgumentException">If 'expires' &lt;= 'notbefore'.</exception>public JwtSecurityToken(string issuer = null, string audience = null, IEnumerable<Claim> 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;}

這樣，我們可以根據(jù)參數(shù)指定內(nèi)容：

1. string iss = "JWTBearer.Auth"; // 定義發(fā)行人 2. string aud = "api.auth"; ? ? ? //定義受眾人audience 3. IEnumerable<Claim> claims = new Claim[] { new Claim(JwtClaimTypes.Id,"1"), new Claim(JwtClaimTypes.Name,"i3yuan"), };//定義許多種的聲明Claim,信息存儲部分,Claims的實(shí)體一般包含用戶和一些元數(shù)據(jù) 4. var nbf = DateTime.UtcNow; //notBefore 生效時(shí)間 5. var Exp = DateTime.UtcNow.AddSeconds(1000); //expires 過期時(shí)間 6. string sign = "q2xiARx$4x3TKqBJ"; //SecurityKey 的長度必須 大于等于 16個(gè)字符var secret = Encoding.UTF8.GetBytes(sign);var key = new SymmetricSecurityKey(secret);var signcreds = new SigningCredentials(key, SecurityAlgorithms.HmacSha256);

好了，通過以上填充參數(shù)內(nèi)容，進(jìn)行傳參賦值得到，完整代碼如下：

新增AuthController.cs控制器：

? [HttpGet]public IActionResult GetToken(){try{//定義發(fā)行人issuerstring iss = "JWTBearer.Auth";//定義受眾人audiencestring aud = "api.auth";//定義許多種的聲明Claim,信息存儲部分,Claims的實(shí)體一般包含用戶和一些元數(shù)據(jù)IEnumerable<Claim> claims = new Claim[]{new Claim(JwtClaimTypes.Id,"1"),new Claim(JwtClaimTypes.Name,"i3yuan"),};//notBefore 生效時(shí)間// long nbf =new DateTimeOffset(DateTime.Now).ToUnixTimeSeconds();var nbf = DateTime.UtcNow;//expires ? //過期時(shí)間// long Exp = new DateTimeOffset(DateTime.Now.AddSeconds(1000)).ToUnixTimeSeconds();var Exp = DateTime.UtcNow.AddSeconds(1000);//signingCredentials 簽名憑證string sign = "q2xiARx$4x3TKqBJ"; //SecurityKey 的長度必須 大于等于 16個(gè)字符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個(gè)字符，否則生成會報(bào)錯(cuò)。（可通過在線隨機(jī)生成密鑰）

5. 運(yùn)行

訪問獲取Token方法，獲取得到access_token:

再訪問，授權(quán)資源接口，可以發(fā)現(xiàn)，再沒有添加請求頭token值的情況下，返回了401沒有權(quán)限。

這次，在請求頭通過Authorization加上之前獲取的token值后，再次進(jìn)行訪問，發(fā)現(xiàn)已經(jīng)可以獲取訪問資源控制器，并返回對應(yīng)的數(shù)據(jù)。

6.擴(kuò)展說明

在HTTP標(biāo)準(zhǔn)驗(yàn)證方案中，我們比較熟悉的是"Basic"和"Digest"，前者將用戶名密碼使用BASE64編碼后作為驗(yàn)證憑證，后者是Basic的升級版，更加安全，因?yàn)锽asic是明文傳輸密碼信息，而Digest是加密后傳輸。

一、Basic基礎(chǔ)認(rèn)證

Basic認(rèn)證是一種較為簡單的HTTP認(rèn)證方式，客戶端通過明文（Base64編碼格式）傳輸用戶名和密碼到服務(wù)端進(jìn)行認(rèn)證，通常需要配合HTTPS來保證信息傳輸?shù)陌踩?/p>

客戶端請求需要帶Authorization請求頭，值為“Basic xxx”，xxx為“用戶名:密碼”進(jìn)行Base64編碼后生成的值。若客戶端是瀏覽器，則瀏覽器會提供一個(gè)輸入用戶名和密碼的對話框，用戶輸入用戶名和密碼后，瀏覽器會保存用戶名和密碼，用于構(gòu)造Authorization值。當(dāng)關(guān)閉瀏覽器后，用戶名和密碼將不再保存。

憑證為“YWxhzGRpbjpvcGVuc2VzYWl1”，是通過將“用戶名:密碼”格式的字符串經(jīng)過的Base64編碼得到的。而Base64不屬于加密范疇，可以被逆向解碼，等同于明文，因此Basic傳輸認(rèn)證信息是不安全的。

Basic基礎(chǔ)認(rèn)證圖示：

缺陷匯總1.用戶名和密碼明文（Base64）傳輸，需要配合HTTPS來保證信息傳輸?shù)陌踩?.即使密碼被強(qiáng)加密，第三方仍可通過加密后的用戶名和密碼進(jìn)行重放攻擊。3.沒有提供任何針對代理和中間節(jié)點(diǎn)的防護(hù)措施。4.假冒服務(wù)器很容易騙過認(rèn)證，誘導(dǎo)用戶輸入用戶名和密碼。

二、Digest摘要認(rèn)證

Digest認(rèn)證是為了修復(fù)基本認(rèn)證協(xié)議的嚴(yán)重缺陷而設(shè)計(jì)的，秉承“絕不通過明文在網(wǎng)絡(luò)發(fā)送密碼”的原則，通過“密碼摘要”進(jìn)行認(rèn)證，大大提高了安全性。

Digest認(rèn)證步驟如下：第一步：客戶端訪問Http資源服務(wù)器。由于需要Digest認(rèn)證，服務(wù)器返回了兩個(gè)重要字段nonce（隨機(jī)數(shù)）和realm。第二步：客戶端構(gòu)造Authorization請求頭，值包含username、realm、nouce、uri和response的字段信息。其中，realm和nouce就是第一步返回的值。nouce只能被服務(wù)端使用一次。uri(digest-uri)即Request-URI的值，但考慮到經(jīng)代理轉(zhuǎn)發(fā)后Request-URI的值可能被修改、因此實(shí)現(xiàn)會復(fù)制一份副本保存在uri內(nèi)。response也可叫做Request-digest，存放經(jīng)過MD5運(yùn)算后的密碼字符串，形成響應(yīng)碼。第三步：服務(wù)器驗(yàn)證包含Authorization值的請求，若驗(yàn)證通過則可訪問資源。Digest認(rèn)證可以防止密碼泄露和請求重放，但沒辦法防假冒。所以安全級別較低。Digest和Basic認(rèn)證一樣，每次都會發(fā)送Authorization請求頭，也就相當(dāng)于重新構(gòu)造此值。所以兩者易用性都較差。

Digest認(rèn)證圖示：

7.注意

在進(jìn)行JwtBearer認(rèn)證時(shí)，在生成token之后，還需要與刷新token配合使用，因?yàn)楫?dāng)用戶執(zhí)行了退出，修改密碼等操作時(shí)，需要讓該token無效，無法再次使用，所以，會給access_token設(shè)置一個(gè)較短的有效期間，(JwtBearer認(rèn)證默認(rèn)會驗(yàn)證有效期，通過notBefore和expires來驗(yàn)證)，當(dāng)access_token過期后，可以在用戶無感知的情況下，使用refresh_token重新獲取access_token，但這就不屬于Bearer認(rèn)證的范疇了，但是我們可以通過另一種方式通過IdentityServer的方式來實(shí)現(xiàn)，在后續(xù)中會對IdentityServer進(jìn)行詳細(xì)講解。

在生成token的時(shí)候，需要用的secret，主要是用來防止token被偽造與篡改。因?yàn)楫?dāng)token被劫取的時(shí)候，可以得到你的令牌中帶的一些個(gè)人不重要的信息明文，但不用擔(dān)心，只要你不在生成token里把私密的個(gè)人信息放出去的話，就算被動(dòng)機(jī)不良的人得到，也做不了什么事情。但是你可能會想，如果用戶自己隨便的生成一個(gè) token ，帶上你的信息，那不就可以隨便訪問你的資源服務(wù)器了，因此這個(gè)時(shí)候就需要利用secret 來生成 token，來確保數(shù)字簽名的正確性。而且在認(rèn)證授權(quán)資源，進(jìn)行token解析的時(shí)候，通過微軟的源碼發(fā)現(xiàn)，已經(jīng)幫我們封裝了方法，對secret進(jìn)行了校驗(yàn)了，確保了token的安全性，從而保證api資源的安全。

8.總結(jié)

JwtToken在認(rèn)證時(shí)，無需Security token service安全令牌服務(wù)器的參與，都是基于Claim的，默認(rèn)會驗(yàn)證有效期，通過notBefore和expires來驗(yàn)證，這在分布式中提供給了極大便利。

JwtToken與平臺、無言無關(guān)，在前端也可以直接解析出Claims。

如果有不對的或不理解的地方，希望大家可以多多指正，提出問題，一起討論,不斷學(xué)習(xí),共同進(jìn)步。

后面會對認(rèn)證授權(quán)方案中的授權(quán)這一塊進(jìn)行說明分享。

參考JwtBearer源碼

往期精彩回顧

總結(jié)

以上是生活随笔為你收集整理的认证授权方案之JwtBearer认证的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。