最近，團隊的小伙伴們在做項目時，需要用到JWT認證。遂根據自己的經驗，整理成了這篇文章，用來幫助理清JWT認證的原理和代碼編寫操作。

第一部分：Dotnet core使用JWT認證授權最佳實踐(一)

（接上文）

測試運行

%?dotnet?run

等程序運行起來后，在瀏覽器輸入：http://localhost:5000/swagger/，會進到Swagger的API界面。選擇requestToken，點擊按鈕”Try it out“->”Execute“，可以看到運行結果：

["eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy93cy8yMDA1LzA1L2lkZW50aXR5L2NsYWltcy9uYW1lIjoic3RyaW5nIiwiZXhwIjoxNTg5MzgxMzQ4LCJpc3MiOiJXYW5nUGx1cyJ9.ojGuWUk9i2Vp5qu3s2UZSLC64Sm95Cao2eGF3GDVvec","123456"]

好吧，不要在意這個返回的格式。返回的兩個串中，第一個就是Token，第二個是refreshToken。

?

到這兒，我們成功拿到了用戶的Token。

四、Token認證

拿到Token后，我們就可以進行認證操作了。

既然是認證，那應該在每個API上進行。所以，認證的過程不會放到控制器里，而應該以MiddleWare的方式，放到主流程中。

這個MiddleWare，Microsoft.AspNetCore.Authentication.JwtBearer庫已經幫我們做好了。我們只需要配置就好。

在Startup.cs中，ConfigureServices方法里，添加以下內容

services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme) .AddJwtBearer(option?=> {option.RequireHttpsMetadata?=?false;option.SaveToken?=?true;var?token?=?Configuration.GetSection("tokenParameter").Get<tokenParameter>();option.TokenValidationParameters?=?new?TokenValidationParameters{ValidateIssuerSigningKey?=?true,IssuerSigningKey?=?new?SymmetricSecurityKey(Encoding.ASCII.GetBytes(token.Secret)),ValidIssuer?=?token.Issuer,ValidateIssuer?=?true,ValidateAudience?=?false,}; });

這里面，有幾個參數需要注意：

RequireHttpsMetadata: 限定認證操作是否必須通過https來做，這個要跟隨項目在生產環境中的運行情況來定。如果WebServer是我前文15分鐘從零開始搭建支持10w+用戶的生產環境(三)中介紹的Jexus，采用對外https，對內http的方式，那這兒可以設為false。

SaveToken: 決定Token在認證完成后，是否需要保存到上下文里并向后傳。這個設置也要看應用。我們Token生成后，用戶的相關信息已經包含在里面了。API里如果有涉及用戶的操作，按理可以不用往API里傳相關用戶的參數。一方面不安全，另一方面代碼也不好看。這時就可以把這個參數設為True，然后API從上下文中直接取用戶信息。

在Startup.cs里，Configure方法中，打開認證

app.UseAuthentication(); app.UseAuthorization();

?

這兩步完成，我們就完成的認證的開發工具。

用別人的輪子還是很爽的，雖然輪子的挑選工作很復雜很費力。

?

設置API認證。

在這個Demo里，我們選代碼生成時給的WeatherForecastController下的Get方法來測試。

在方法前邊，我們加上Authorize：

[HttpGet] [Authorize] public?IEnumerable<WeatherForecast>?Get() ...

測試運行。

啟動程序，跟上一章的方式一樣。

程序運行后，打開：http://localhost:5000/swagger/，進入WeatherForecast，點”Try it out“->”Execute“，我們會得到一個401 - Error: Unauthorized的返回，因為我們沒有做認證。

下面測試做認證后的訪問。

先去requestToken拿一個Token（refreshToken這章不用），在前邊加“Bearer ”，拼成一個串

Bearer?eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJodHRwOi8vc2NoZW1hcy54bWxzb2FwLm9yZy93cy8yMDA1LzA1L2lkZW50aXR5L2NsYWltcy9uYW1lIjoic3RyaW5nIiwiZXhwIjoxNTg5MzgxMzQ4LCJpc3MiOiJXYW5nUGx1cyJ9.ojGuWUk9i2Vp5qu3s2UZSLC64Sm95Cao2eGF3GDVvec

要注意，Bearer后邊要跟一個空格。這個串的格式是：Bearer + 空格 + Token。

在頁面的右上角，有一個“Authorize”，點進去，在Value輸入框中粘貼上面拼好的串，然后點按鈕“Authorize”，保存認證信息。

下面進入WeatherForecast，點”Try it out“->”Execute“，這時候，我們就能拿到正確的返回數據。

五、擴展：用戶角色認證

在上一章中，我們實現了用戶的認證。但這個認證有個不漂亮的地方：用戶只簡單的被認證系統分成了通過認證的和不通過認證的。

在實際項目中，我們有時候會有這樣的需求：對于某個API，我們希望只允許具有某種角色權限的用戶去訪問。

下面，我們對這個項目進行小量的修改，以完成這個需求。

在給用戶簽發Token的過程中，加入用戶的角色數據。

在AuthenticationController的RequestToken中，我們構建了一個用戶的Claims：

var?claims?=?new[] {new?Claim(ClaimTypes.Name,request.username), };

就是這兒。我們在這兒加入用戶的角色：

var?claims?=?new[] {new?Claim(ClaimTypes.Name,request.username),new?Claim(ClaimTypes.Role,?"testUser"), };

實際應用中，這個角色的名稱，可以根據需要，從用戶系統中拿來。

在這個Demo里，就直接寫成個字符串了。就是說，有一個角色，叫testUser。

給API增加認證的角色要求

[HttpGet] [Authorize(Roles="testUser")] public?IEnumerable<WeatherForecast>?Get() ...

在這里，這個Roles="testUser"里的testUser，就是這個方法授權所對應的角色名稱。

測試運行

按正常的步驟，取Token，拼串，保存認證信息，然后去運行WeatherForecast，API能正常返回。

我們可以把代碼中的testUser改成別的字符串進行測試，會返回403 - Error: Forbidden錯誤。

?

增加角色認證成功。

六、刷新Token

Token過期后，就需要刷新。

當然我們可以把Token設成永遠不過期，但這不是個安全的做法。還可以在Token過期后重新請求一個新Token，但這樣做會顯得Low。

賞心悅目的做法是：用refreshToken來刷新Token。設置refreshToken的過期時間長于Token。Token過期后，讓用戶提交Token和refreshToken到服務器，服務器驗證Token是否合法，并從中提取用戶信息，根據用戶信息和refreshToken核驗是否匹配。如果匹配，就重新生成Token給用戶。

至于refreshToken的過期時長，和是否需要在刷新Token時也刷新refreshToken，就看心情了，沒有固定的做法。我自己的項目中，Token是2小時過期，refreshToken是24小時過期。在Token刷新時，如果refreshToken的過期時間少于6小時，則刷新refreshToken。供參考。

?

下面，按這個方式，做一下刷新Token。

在DTOModels下建一個RefreshTokenDTO，用作API的輸入參數

using?System;namespace?demo.DTOModels {public?class?RefreshTokenDTO{public?string?Token?{?get;?set;?}?public?string?refreshToken?{?get;?set;?}}

在AuthenticationController里，創建一個RefreshToken的API，并補齊驗證代碼

[HttpPost,?Route("refreshToken")] public?ActionResult?RefreshToken([FromBody]RefreshTokenDTO?request) {if(request.Token?==?null?&&?request.refreshToken?==?null)return?BadRequest("Invalid?Request");//這兒是驗證Token的代碼var?handler?=?new?JwtSecurityTokenHandler();try{ClaimsPrincipal?claim?=?handler.ValidateToken(request.Token,?new?TokenValidationParameters{ValidateIssuerSigningKey?=?true,IssuerSigningKey?=?new?SymmetricSecurityKey(Encoding.ASCII.GetBytes(_tokenParameter.Secret)),ValidateIssuer?=?false,ValidateAudience?=?false,ValidateLifetime?=?false,},?out?SecurityToken?securityToken);var?username?=?claim.Identity.Name;//這兒是生成Token的代碼var?token?=?GenUserToken(username,?"testUser");var?refreshToken?=?"654321";return?Ok(new[]?{?token,?refreshToken?});}catch(Exception){return?BadRequest("Invalid?Request");} }

這樣，Token刷新就完成了?？梢杂蒙蒚oken運行測試，能正常認證通過。

?

單獨說一下refreshToken

refreshToken，名義上是為了刷新Token，實際上用處主要是給用戶重新登錄做計時。refreshToken過期了，用戶就必須重新登錄。就是這么個作用。要不然，Token自己刷新豈不更好？

refreshToken可以采用跟Token一樣的生成方式。但是，我們也看到，Token生成出來的串就很長，如果refreshToken也那樣生成，那就也會是一個很長的串。這樣會加大前端到API的傳輸量。因此，這不算是一個好主意。

一般來說，refreshToken會換一種生成方式。唯一序列、Hash，都是可以選擇的，可以減少很多傳輸。

至于持久化和過期，依托數據庫就好了。

七、彩蛋

最后，送大家一個彩蛋。

在生成Token時，我們把過期時間設置成少于五分鐘的時長，比方3分鐘。但這時，實測會發現，Token的過期失效了。

為什么呢？

TokenValidationParameters有一個屬性叫ClockSkew，這個參數有個默認值是TimeSpan.FromMinutes(5)。

這個參數的意義是：考慮到各個服務器之間的時間不一定完全同步，系統給了個5分鐘的誤差時間。

這個誤差時間導致的結果是：少于五分鐘的過期時間，會在實際認證檢查時被忽略。

這個情況，Microsoft上有N多人在討論，可以自己去查。

所以，當Token的過期小于5分鐘時，想要讓認證對這個時間生效，可以把這個值設為TimeSpan.Zero。

option.TokenValidationParameters?=?new?TokenValidationParameters {ValidateIssuerSigningKey?=?true,IssuerSigningKey?=?new?SymmetricSecurityKey(Encoding.ASCII.GetBytes(token.Secret)),ValidIssuer?=?token.Issuer,ValidateIssuer?=?true,ValidateAudience?=?false,ClockSkew?=?TimeSpan.Zero,????????//就是這一行 };

我把上面的代碼，傳到了Github上，需要了可以拉下來直接測試。

代碼地址：https://github.com/humornif/Demo-Code/tree/master/0007/demo

（全文完）

點「在看」，讓更多人因你而受益

↘ ?↘ ?↘

總結

以上是生活随笔為你收集整理的Dotnet core使用JWT认证授权最佳实践(二)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。