歡迎大家閱讀《朝夕Net社區(qū)技術(shù)專刊》第6期

我們致力于.NetCore的推廣和落地，為更好的幫助大家學(xué)習(xí)，方便分享干貨，特創(chuàng)此刊！很高興你能成為忠實(shí)讀者，文末福利不要錯(cuò)過(guò)哦！

前言：

本部分文檔將詳細(xì)給大家介紹CoreWebApi的Authorize鑒權(quán)授權(quán)；為什么要鑒權(quán)授權(quán)呢？如果沒(méi)有啟用身份認(rèn)證，那么任何匿名用戶只要知道了我們服務(wù)的url，就能隨意訪問(wèn)我們的服務(wù)接口，從而訪問(wèn)或修改數(shù)據(jù)庫(kù)。所以在各種系統(tǒng)開(kāi)發(fā)中授權(quán)是必備的；今天這里就給大家說(shuō)說(shuō)授權(quán)的事兒。

01

PART

傳統(tǒng)方式的授權(quán)

請(qǐng)看下圖，在傳統(tǒng)授權(quán)中，因?yàn)镠ttp請(qǐng)求是沒(méi)有狀態(tài)的，http請(qǐng)求第一次請(qǐng)求和第二次請(qǐng)求是沒(méi)有關(guān)系的，所有在傳統(tǒng)的授權(quán)方式里面使用的是Session+Cookes;Session使用的較多；思路：客戶端（瀏覽器）第一次請(qǐng)求服務(wù)器的時(shí)候，服務(wù)器針對(duì)于當(dāng)前這個(gè)瀏覽器生成一個(gè)Session:Key-value形式，SessionId:Session值；客戶端來(lái)登錄獲取權(quán)限的時(shí)候，服務(wù)器然后在響應(yīng)請(qǐng)求的時(shí)候，把SessionId返回給客戶端瀏覽器；瀏覽器把SessionId保存在cookies中，再次去請(qǐng)求服務(wù)器的時(shí)候帶上這個(gè)SessionId的標(biāo)識(shí)，然后服務(wù)器就可以識(shí)別到，這是上次某某某瀏覽器來(lái)訪問(wèn)過(guò)我，登陸過(guò)，這個(gè)SessionId是我服務(wù)器頒發(fā)的，就通過(guò)了權(quán)限認(rèn)證了。

基于Session cookies的權(quán)限校驗(yàn)是比較傳統(tǒng)的，也是最常見(jiàn)的，不過(guò)基于Session、Cookies的權(quán)限校驗(yàn)，存在一些尷尬事兒。

因?yàn)镾ession是存儲(chǔ)在服務(wù)器的，在一些大型分布集群服務(wù)器中，Session共享的問(wèn)題不太好解決（當(dāng)然這里不是說(shuō)不能解決），比方說(shuō)有A/B/C/D四個(gè)服務(wù)器集群，那么登錄時(shí)候如果是A服務(wù)器生成的Session,那么B服務(wù)器是不能用的；需要做Session共享，成本相對(duì)來(lái)說(shuō)較高；

像大家在使用一些系統(tǒng)的時(shí)候，常常會(huì)見(jiàn)到一些像QQ、微信、淘寶賬號(hào) 這類第三方賬號(hào)登錄，如果使用Cookies和Session來(lái)實(shí)現(xiàn)，成本很高；

02

PART

基于令牌的鑒權(quán)授權(quán)——Basic授權(quán)

在Asp.NetWebApi中可以使用Basic授權(quán)；Basic授權(quán)是基于令牌的，在登錄的時(shí)候，服務(wù)器給頒發(fā)一個(gè)tiket（這里可以理解成一個(gè)鑰匙），然后你去訪問(wèn)Api的時(shí)候，把這個(gè)tiket給帶上，就可以通過(guò)校驗(yàn)；Basic認(rèn)證實(shí)現(xiàn)起來(lái)非常簡(jiǎn)單；下面我把代碼貼在這里供大家參考。

圖1

注：就是在用戶登錄的時(shí)候通過(guò)在請(qǐng)求登錄的時(shí)候傳遞的參數(shù)生成一個(gè)Tiket；使用PostMan調(diào)用如圖2所示；

圖2

那么有tiket了，在調(diào)用Api的時(shí)候，就需要驗(yàn)證這個(gè)tiket了，怎么驗(yàn)證呢？Richard老師這里是使用Asp.NetMVC中的Filter---AuthorizeAttribute來(lái)實(shí)現(xiàn)的。

圖3

定義個(gè)Api:GetUserInfo.

在沒(méi)有標(biāo)記任何Filter的時(shí)候，通過(guò)Ajax請(qǐng)求Api；結(jié)果可以正常拿到，請(qǐng)看圖4、圖5

圖4

圖5

那標(biāo)記特性以后呢？請(qǐng)看圖6；圖7

圖6

圖7

請(qǐng)求結(jié)果拿不到，因?yàn)樵谡?qǐng)求WebApi的時(shí)候沒(méi)有把tiket帶上。請(qǐng)看圖8、圖9、圖10；

圖8

圖9

圖10

現(xiàn)在可以正常調(diào)用Api獲取到數(shù)據(jù)；那么Basic的流程如下：

1.????獲取tiket;

2.????在調(diào)用Api的時(shí)候，把tiket帶上；通過(guò)驗(yàn)證tiket的來(lái)達(dá)到授權(quán)的效果；

03

PART

基于令牌的鑒權(quán)授權(quán)——Jwt鑒權(quán)授權(quán)

Jwt鑒權(quán)：Json Web Token是在.NetCore中最主流的鑒權(quán)授權(quán)方式，這里Richard老師準(zhǔn)備給大家詳細(xì)解讀Jwt鑒權(quán)授權(quán)的核心思路；請(qǐng)看圖1

圖1

圖1為jwt鑒權(quán)授權(quán)的架構(gòu)圖，圖1中分別有四個(gè)角色，客戶端-User,鑒權(quán)中心AuthorziationServer，資源提供-Api, ?第三方Api-Third-Party。

根據(jù)圖中的流程:

?請(qǐng)求鑒權(quán)中心AuthorziationServer（根據(jù)賬號(hào)密碼到鑒權(quán)中心登錄），獲取Token

去請(qǐng)求資源Api 或者第三方Api Third-Party 的時(shí)候帶上token,就可以獲取數(shù)據(jù)；

小伙伴兒在看到這個(gè)圖以后，可能會(huì)覺(jué)得奇怪，資源Api并沒(méi)有和鑒權(quán)中心AuthorizatinServer發(fā)生交互，是怎么驗(yàn)證權(quán)限的呢？這其實(shí)是Jwt鑒權(quán)的一大特點(diǎn)；

那是怎么鑒權(quán)的呢？下面就給大家解惑一下：

其實(shí)鑒權(quán)中心在生成Token, ?Api在通過(guò)Token驗(yàn)證權(quán)限的時(shí)候，這二者或有一個(gè)非對(duì)稱可逆加密解密的過(guò)程；

1.????鑒權(quán)中心兜兒里有一個(gè)私鑰，用來(lái)加密；私鑰是私密的，只有鑒權(quán)中心知道；

2.????資源Api或者第三方Api Thrid-Party兜兒里有一個(gè)和鑒權(quán)中的那個(gè)私鑰對(duì)應(yīng)的解密公鑰，就是鑒權(quán)中心私鑰加密，資源Api，公鑰解密；公鑰是公開(kāi)的；誰(shuí)都是知道的；

【這里涉及到有非對(duì)稱加密解密的知識(shí)，如果對(duì)這一塊的內(nèi)容不是很理解的，可以聯(lián)系QQ: 1432568536獲取關(guān)于加密解密的內(nèi)容】

?

那么鑒權(quán)中心和資源Api之間是怎么完成的呢？

?在鑒權(quán)中心，登錄以后，生成的Token是通過(guò)私鑰加密的，這里就只有公鑰能解開(kāi)。

?在請(qǐng)求Api的時(shí)候，資源Api有公鑰，那么資源Api就去嘗試解密，如果能解開(kāi)，說(shuō)明這個(gè)Token確實(shí)是來(lái)自于鑒權(quán)中心，那OK，那資源Api就通過(guò)校驗(yàn)，正常返回?cái)?shù)據(jù)；否則就表示沒(méi)有權(quán)限。

下面給大家介紹一下這個(gè)Token的內(nèi)容結(jié)構(gòu)：如圖2，是一段標(biāo)準(zhǔn)的Token內(nèi)容；一共分為三段。?

圖2

第一段：頭信息，紅色部分，圖3所示，表示加密算法：HS256,類型是jwt鑒權(quán)；

圖3

第二段：圖4所示：紫色部分，表示有效載荷，也就是在這個(gè)Token里面可以攜帶一些信息，有Token標(biāo)準(zhǔn)的信息內(nèi)容，也可以自定義加一些內(nèi)容。

圖4

第三段：簽名

簽名Signature　

=HMACSHA256( base64UrlEncode(頭信息) + "." +? base64UrlEncode(有效載荷信息),? 公鑰)

通過(guò)HMACSHA256 算法加密 +.+ ?Base64位的頭信息+.+Base64位的有效載荷信息+.+公鑰;三段內(nèi)容通過(guò)點(diǎn)連接起來(lái)形成一個(gè)完整的Token 令牌。

那Token里的內(nèi)容能修改嗎？不能修改，如果修改過(guò)了，內(nèi)容解密后，跟真實(shí)內(nèi)容就不一樣了；下面就基于Jwt在Core環(huán)境下做一個(gè)實(shí)現(xiàn)。

如果圖1中所示，得有一個(gè)鑒權(quán)中心專門用來(lái)頒發(fā)Token；

圖5

這里使用到了一個(gè)JwtService: 如圖6jwtService 實(shí)現(xiàn)；

1.需要Nuget引入程序包：Microsoft.IdentityModel.Tokens

????????????? Nuget引入程序包：System.IdentityModel.Tokens.Jwt

圖6

2.需要在配置文件里配置：如圖7所示

圖7

【這部分的代碼可以聯(lián)系朝夕教育助教老師獲取：QQ: 1432568536】如此鑒權(quán)中心就OK了；那Api部分呢？下面將繼續(xù)說(shuō)說(shuō)Api如何基于Jwt授權(quán)。

1. ?? CoreWebApi需要在Startup 下的ConfigureServices中增加如下代碼：

如圖8所示

圖8

2.在Startup中的Configure中指定使用授權(quán);如圖9所示；

圖9

3.???在資源Api中標(biāo)記特性；如圖10所示。

圖10

測(cè)試：

第一步：命令啟動(dòng)WebApi: dotnet Zhaoxi.Core.WebApi.dll --urls="http://*:8004" --?? ?????? ?????? ???? ???????ip="127.0.0.1" --port= 8004

如圖11所示：

圖11

第二步：PostMan 請(qǐng)求Api;圖12所示，表示沒(méi)有授權(quán)；所以需要授權(quán)，那怎么授權(quán)呢？需要啟動(dòng)鑒權(quán)中心，獲取令牌Toke

圖12

第三步：命令啟動(dòng)鑒權(quán)中心：dotnet Zhaoxi.Core.AuthenticationCenter.dll --urls="http://*:8001" --??? ?????? ? ???? ?????? ip="127.0.0.1" --port= 8001

如圖13所示

圖13

第四步：PostMan請(qǐng)求獲取Token；如圖14所示：

圖14

第五步：圖14獲取到了Toke, 就可以帶上token 請(qǐng)求Api，正常獲取數(shù)據(jù)，圖15，圖16所示。

圖15

圖16

以上就是整套的Jwt權(quán)限驗(yàn)證過(guò)程，使用的是Jwt鑒權(quán)授權(quán)。

總結(jié)

以上是生活随笔為你收集整理的【朝夕技术专刊】Core3.1WebApi_Filter-Authorize详解的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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