Dotnet core使用JWT认证授权最佳实践(二)
最近，團隊的小伙伴們在做項目時，需要用到JWT認證。遂根據(jù)自己的經(jīng)驗，整理成了這篇文章，用來幫助理清JWT認證的原理和代碼編寫操作。
第一部分：Dotnet core使用JWT認證授權最佳實踐(一)
（接上文）
測試運行
等程序運行起來后，在瀏覽器輸入：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庫已經(jīng)幫我們做好了。我們只需要配置就好。
在Startup.cs中，ConfigureServices方法里，添加以下內(nèi)容
這里面，有幾個參數(shù)需要注意：
RequireHttpsMetadata: 限定認證操作是否必須通過https來做，這個要跟隨項目在生產(chǎn)環(huán)境中的運行情況來定。如果WebServer是我前文15分鐘從零開始搭建支持10w+用戶的生產(chǎn)環(huán)境(三)中介紹的Jexus，采用對外https，對內(nèi)http的方式，那這兒可以設為false。
SaveToken: 決定Token在認證完成后，是否需要保存到上下文里并向后傳。這個設置也要看應用。我們Token生成后，用戶的相關信息已經(jīng)包含在里面了。API里如果有涉及用戶的操作，按理可以不用往API里傳相關用戶的參數(shù)。一方面不安全，另一方面代碼也不好看。這時就可以把這個參數(shù)設為True，然后API從上下文中直接取用戶信息。
在Startup.cs里，Configure方法中，打開認證
?
這兩步完成，我們就完成的認證的開發(fā)工具。
用別人的輪子還是很爽的，雖然輪子的挑選工作很復雜很費力。
?
設置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“，這時候，我們就能拿到正確的返回數(shù)據(jù)。
五、擴展：用戶角色認證
在上一章中，我們實現(xiàn)了用戶的認證。但這個認證有個不漂亮的地方：用戶只簡單的被認證系統(tǒng)分成了通過認證的和不通過認證的。
在實際項目中，我們有時候會有這樣的需求：對于某個API，我們希望只允許具有某種角色權限的用戶去訪問。
下面，我們對這個項目進行小量的修改，以完成這個需求。
在給用戶簽發(fā)Token的過程中，加入用戶的角色數(shù)據(jù)。
在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"), };實際應用中，這個角色的名稱，可以根據(jù)需要，從用戶系統(tǒng)中拿來。
在這個Demo里，就直接寫成個字符串了。就是說，有一個角色，叫testUser。
給API增加認證的角色要求
在這里，這個Roles="testUser"里的testUser，就是這個方法授權所對應的角色名稱。
測試運行
按正常的步驟，取Token，拼串，保存認證信息，然后去運行WeatherForecast，API能正常返回。
我們可以把代碼中的testUser改成別的字符串進行測試，會返回403 - Error: Forbidden錯誤。
?
增加角色認證成功。
六、刷新Token
Token過期后，就需要刷新。
當然我們可以把Token設成永遠不過期，但這不是個安全的做法。還可以在Token過期后重新請求一個新Token，但這樣做會顯得Low。
賞心悅目的做法是：用refreshToken來刷新Token。設置refreshToken的過期時間長于Token。Token過期后，讓用戶提交Token和refreshToken到服務器，服務器驗證Token是否合法，并從中提取用戶信息，根據(jù)用戶信息和refreshToken核驗是否匹配。如果匹配，就重新生成Token給用戶。
至于refreshToken的過期時長，和是否需要在刷新Token時也刷新refreshToken，就看心情了，沒有固定的做法。我自己的項目中，Token是2小時過期，refreshToken是24小時過期。在Token刷新時，如果refreshToken的過期時間少于6小時，則刷新refreshToken。供參考。
?
下面，按這個方式，做一下刷新Token。
在DTOModels下建一個RefreshTokenDTO，用作API的輸入?yún)?shù)
在AuthenticationController里，創(chuàng)建一個RefreshToken的API，并補齊驗證代碼
這樣，Token刷新就完成了。可以用生成Token運行測試，能正常認證通過。
?
單獨說一下refreshToken
refreshToken，名義上是為了刷新Token，實際上用處主要是給用戶重新登錄做計時。refreshToken過期了，用戶就必須重新登錄。就是這么個作用。要不然，Token自己刷新豈不更好？
refreshToken可以采用跟Token一樣的生成方式。但是，我們也看到，Token生成出來的串就很長，如果refreshToken也那樣生成，那就也會是一個很長的串。這樣會加大前端到API的傳輸量。因此，這不算是一個好主意。
一般來說，refreshToken會換一種生成方式。唯一序列、Hash，都是可以選擇的，可以減少很多傳輸。
至于持久化和過期，依托數(shù)據(jù)庫就好了。
七、彩蛋
最后，送大家一個彩蛋。
在生成Token時，我們把過期時間設置成少于五分鐘的時長，比方3分鐘。但這時，實測會發(fā)現(xiàn)，Token的過期失效了。
為什么呢？
TokenValidationParameters有一個屬性叫ClockSkew，這個參數(shù)有個默認值是TimeSpan.FromMinutes(5)。
這個參數(shù)的意義是：考慮到各個服務器之間的時間不一定完全同步，系統(tǒng)給了個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认证授权最佳实践(二)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 使用PInvoke互操作，让C#和C++
- 下一篇： Dotnet core使用JWT认证授权