您好,登錄后才能下訂單哦!
這期內(nèi)容當中小編將會給大家?guī)碛嘘P(guān)ASP.NET MVC中怎么使用Oauth2.0驗證身份,文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述,閱讀完這篇文章希望大家可以有所收獲。
● Resource Owner:資源擁有者,就是能夠訪問被限制資源的用戶(注:這里的用戶是個泛指,它既可以是真實用戶也可以是服務程序)。
● Resource Server:資源宿主,能夠接受和處理,使用訪問令牌(access token)訪問受保護資源的請求(如提供API的服務器)。
● Client:它泛指所有的第三方程序(無論是Web應用、桌面應用還是服務端應用),它通過資源擁有者以及它的授權(quán)來訪問受保護的資源。
● Authorization Server:用來對授權(quán)成功的客戶端發(fā)布令牌以及對令牌的驗證授權(quán)。并對Client進行管理。
A. 第三方程序向資源擁有者(用戶)發(fā)送授權(quán)請求,這個過程既可以通過客戶端直接向用戶請求,也可以通過授權(quán)服務器作為中介來完成請求。(注:對于授權(quán)請求這個概念相當于用戶登錄,應用程序可以直接顯示一個登錄頁面,也可以跳轉(zhuǎn)到驗證服務器的統(tǒng)一登錄頁面)
B. 用戶將授權(quán)相關(guān)信息“提交”給第三方程序,在OAuth中有4種不同的權(quán)限授予方式,每種方式需要的數(shù)據(jù)不同,如基于用戶密碼的授權(quán)方式就需要用戶名和密碼。
C. 第三方程序?qū)⒂脩舻氖跈?quán)信息提交到授權(quán)服務器,請求一個Access Token。
D. 授權(quán)服務器驗證完成用戶的授權(quán)信息后,將Access Token發(fā)放到第三方程序。
E. 第三方程序攜帶Access Token訪問被保護的資源。
F. 資源服務器驗證Access Token有效后,將資源返回到第三方程序。
● Authorization Code(授權(quán)碼模式):該模式的核心是客戶端通過一個授權(quán)碼來向授權(quán)服務器申請Access Token。是一種基于重定向的授權(quán)模式,授權(quán)服務器作為用戶和第三方應用(Client)的中介,當用戶訪問第三方應用是,第三方應用跳轉(zhuǎn)到授權(quán)服務器引導用戶完成身份驗證,生成Authorization Code并轉(zhuǎn)交到第三方應用,以便于第三方應用根據(jù)這個授權(quán)碼完成后續(xù)的Access Token獲取。
● Implicit(簡化模式):簡化模式是一種簡化的授權(quán)碼模式,授權(quán)碼模式在首次訪問第三方應用時跳轉(zhuǎn)到授權(quán)服務器進行身份驗證返回授權(quán)碼,而簡化模式在跳轉(zhuǎn)到授權(quán)服務器后直接返回Access Token,這種模式減少了獲取Access Token的請求次數(shù)。
● Resource Owner Password Credentials(用戶密碼模式):通過資源擁有者(用戶)的用戶名和密碼來直接獲取Access Token的一種方法,這種方法要求第三方應用(Client)是高度可信任的,并且其它授權(quán)方式不可用的情況下使用。
● Client Credentials(客戶端模式):該模式是通過第三方應用(Client)發(fā)送一個自己的憑證到授權(quán)服務器獲得Access Token,這種模式的使用要求該Client已經(jīng)被授權(quán)服務器管理并限制其對被保護資源的訪問范圍。另外這種模式下Client應該就是一個資源擁有者(用戶),如微服務程序。
這個很好理解,第三方應用通過Access Token去獲取受保護的資源,但是Access Token是存在有效期的,一旦過期就無法使用,為了避免Access Token過期后無法使用,所以加入了Refresh Token的概念,通過刷新的方式來完成Access Token的更新。
在OAuth3.0中,所有需要訪問受限資源的程序都視為第三方應用(Client),為了保證這個Client是安全的、可信任的,所以OAuth需要對Client進行管理。參考:https://tools.ietf.org/html/rfc6749#section-2
這里終結(jié)點代表的是HTTP資源,在OAuth授權(quán)過程中需要使用到一些終結(jié)點的支持,如Authorization code(授權(quán)碼)的獲取,以及Access Token的獲取,終結(jié)點由授權(quán)服務器提供。參考:https://tools.ietf.org/html/rfc6749#section-3
Access Token的類型是讓Client根據(jù)具體類型來使用Access Token完成對受保護資源的請求。
OAuth3.0中有兩種類型分別是Bearer和Mac,它們體現(xiàn)方式如下:
● Bearer:
● Mac:
參考:https://tools.ietf.org/html/rfc6750
OAuth3.0是一個開放標準,既然是標準那么就可以有實現(xiàn),在.Net中微軟基于Owin實現(xiàn)了OAuth3.0協(xié)議,下面就介紹如何在ASP.NET MVC程序中實現(xiàn)OAuth身份驗證。
注:本例基于ASP.NET MVC默認帶身份驗證模板完成。
通過NuGet安裝Microsoft.Owin.Security.OAuth組件:
注:從該組件的名稱可以看出,.Net對OAuth的實現(xiàn)實際上是基于Owin的,所以很多內(nèi)容均使用Owin中相關(guān)的身份驗證概念,這些內(nèi)容可參考本系列與身份驗證的文章。
根據(jù)上面OAuth的介紹可知,授權(quán)服務器是OAuth其中一個角色,該角色最主要的功能就是Access Token的發(fā)放以及授權(quán),另外它還用于支持授權(quán)碼模式的授權(quán)碼發(fā)放以及Client的管理。
在Startup類型的Configuration方法中加入以下代碼,該代碼是為Owin中間件添加一個授權(quán)服務器(注:該中間件是一個Owin的身份驗證中間件可參考《ASP.NET沒有魔法——ASP.NET Identity 的“多重”身份驗證》)。
其中OAuthAuthorizationServerOptions定義如下:
上面的定義可以分為以下幾類:
● 終結(jié)點地址:AuthorizeEndpointPath、TokenEndpointPath等,它定義了訪問獲取授權(quán)碼以及獲取Token的地址信息。
● Token提供器:AuthorizationCodeProvider、AccessTokenProvider、RefreshTokenProvider負責完成對應令牌的創(chuàng)建和處理功能。
● Token的“加密”與“解密”:該功能是OAuth與Owin身份驗證的結(jié)合,通過AccessTokenFormat等ISecureDataFormat接口的實現(xiàn)可以將對應的Token轉(zhuǎn)換成一個 AuthenticationTicket??蓞⒖肌禔SP.NET沒有魔法——ASP.NET Identity的加密與解密》文中TicketDataFormat的用法。
● OAuth授權(quán)服務:Provider是整個OAuth服務器的核心,它包含了終結(jié)點的處理與響應、OAuth中的4種Access Token授權(quán)方式和刷新令牌獲取Access Token的方式以及請求、客戶端的相關(guān)驗證:
上面介紹OAuth時介紹了終結(jié)點實際上就是用來獲取授權(quán)碼或者Access Token的,在.Net中使用Microsoft.Owin.Security.OAuth組件僅需要通過配置的形式就可以指定授權(quán)碼及Token獲取的終結(jié)點訪問地址(注:把AllowInsecureHttp配置屬性設為true,可以允許不安全的http來訪問終結(jié)點,該配置僅用于開發(fā)環(huán)境):
完成后就可以通過瀏覽器訪問這兩個地址:
可以看到是可以訪問,只不過是有錯誤的(注:請求地址的QueryString的參數(shù)參考文檔)。
Client在OAuth中指代了所有的第三方需要訪問受限制資源的應用程序,授權(quán)服務器為了能夠識別和驗證Client所以需要完成Client的管理以及驗證功能。(注:微軟在Microsoft.Owin.Security.OAuth組件中僅僅提供了Client驗證的接口,所以要自己實現(xiàn)Client數(shù)據(jù)的管理以及驗證邏輯):
1). 添加Client實體以及對應的倉儲(本例以內(nèi)存的方式實現(xiàn)倉儲,實際使用中至少應該保存數(shù)據(jù)庫):
上圖是Client最基礎的屬性(注:如果還需要對Client的訪問范圍進行限制,那么還應該加入一個Scope的列表,本例不再加入Scope的限制)。
2). Client的倉儲:
3). 實現(xiàn)授權(quán)服務器對Client的驗證:
由于授權(quán)服務器對客戶端驗證的接口位于OAuthAuthorizationServerProvider類型中,所以首先要繼承該類型,并重載相應的驗證方法:
上面代碼做了以下幾件事:
● 嘗試從Http請求header或者請求body中獲取Client信息,包含Id和密碼。
● 如果沒有Client的Id信息,那么直接判斷為不通過驗證,如果有Client的密碼信息則保存到Owin上下文中,供后續(xù)處理使用。
● 使用獲得的ClientId在Client倉儲中查詢,判斷是否是一個合法的Client,如不是則判斷為不通過驗證。
4). 驗證完成后設置該Client的重定向Url(注:該方法仍舊是重載OAuthAuthorizationServerProvider類型中的方法):
授權(quán)碼的生成是授權(quán)服務器終結(jié)點的一項功能,當使用授權(quán)碼模式時,用戶訪問Client會被引導跳轉(zhuǎn)到授權(quán)服務器完成身份驗證(登錄),隨后又攜帶授權(quán)碼跳轉(zhuǎn)回Client,Client使用該授權(quán)碼獲取Access Token。在OAuth的.Net實現(xiàn)中,需要通過在配置中配置一個類型為IAuthenticationTokenProvider的令牌提供器,該提供器用于創(chuàng)建和解析令牌,這里的創(chuàng)建實際就是用戶完成登錄后授權(quán)碼的生成以及授權(quán)碼和用戶登錄身份信息的關(guān)聯(lián),而解析實際就是根據(jù)授權(quán)碼獲得對應用戶身份信息并生成Access Token的過程。
下面就通過實現(xiàn)IAuthenticationTokenProvider的方式實現(xiàn)一個自定義授權(quán)碼提供器:
從上面代碼可以看出這個提供器的核心功能是以Guid的方式生成一個鍵值(授權(quán)碼)保存了當前用戶的信息,當解析時通過該鍵值(即授權(quán)碼)獲取用戶身份信息。(注:AuthenticationTokenCreateContext對象用于對當前用戶身份信息AuthenticationTicket對的的序列化和反序列化)
完成后將該提供器配置到授權(quán)服務器中間件中:
當用戶訪問授權(quán)碼終結(jié)點時理應讓用戶知道Client需要他的授權(quán),為此在ASP.NET MVC程序中需要添加一個路由與授權(quán)碼終結(jié)點地址匹配的Controller、Action以及View:
1). Controller及Action(注:該Action需要通過身份驗證,如果沒有需要跳轉(zhuǎn)到登錄頁面完成身份驗證后才可訪問):
2). View:顯示授權(quán)提示
1). 訪問授權(quán)碼終結(jié)點獲取授權(quán)碼:http://localhost:59273/oauth3/authorize?response_type=code&client_id=test1
由于沒有登錄,所以先跳轉(zhuǎn)到登錄頁面。
完成登錄后跳轉(zhuǎn)回授權(quán)頁面:
點擊授權(quán)按鈕后,攜帶授權(quán)碼跳轉(zhuǎn)到test1這個client的重定向Url(注:此處test1這個Client設置的Url就是授權(quán)服務器本身,所以看上去沒有做重定向)
得到授權(quán)碼后,攜帶授權(quán)碼訪問Access Token終結(jié)點獲取Access Token(注:這里使用Chrome瀏覽器的Postman拓展來實現(xiàn)請求的模擬):
注:上面響應信息中的access_token包含了加密后用戶的身份信息,其加密過程可參考基于Cookie的用戶信息加密過程。ASP.NET沒有魔法——ASP.NET Identity的加密與解密
上面介紹了如何基于授權(quán)碼模式獲得Access Token,接下來將介紹如何使用Access Token來訪問受限制的資源(注:本例中的資源服務器與授權(quán)服務器位于同一實例中,所以當資源服務器對access token解密時,能夠保證與授權(quán)服務器用于生成access token所用密鑰一致,能夠正常解密,這里的Access Token和基于Cookie的身份驗證中的身份驗證Cookie性質(zhì)是相同的,都是將用戶的身份信息序列化后的加密字符串)
1. 在Startup類中添加基于Bearer的OAuth身份驗證中間件:
2. 添加訪問受限制的資源:
3. 訪問受限資源:
未添加授權(quán)信息直接跳轉(zhuǎn)到登錄頁面。
添加Access Token后可正常訪問資源:
上面使用授權(quán)碼模式生成的Access Token是存在過期時間的(實際上無論什么方式生成的Access Token都存在過期時間),Token過期后又不可能讓用戶再授權(quán)一次,所以需要使用Refresh Token來定期刷新Access Token,.Net中實現(xiàn)Refresh Token的方式與授權(quán)碼類似,在生成Refresh Token的同時會關(guān)聯(lián)用戶的身份信息,后續(xù)可以使用這個Refresh Token來生成新的Access Token。
1. 創(chuàng)建Refresh Token提供器(實現(xiàn)方式與授權(quán)碼提供器基本一致):
2. 為授權(quán)服務器配置Refresh Token提供器:
3. 再次獲取到授權(quán)碼后,根據(jù)該授權(quán)碼獲取Access Token,返回信息中將攜帶Refresh Token:
4. 根據(jù)Refresh Token刷新Access Token:
上面介紹了授權(quán)碼模式的實現(xiàn)方式,但這種方式的核心實際上是建立了一個授權(quán)碼和用戶信息的映射(包括刷新令牌方式也是建立了刷新令牌與用戶信息的映射),后續(xù)的Access Token實際上是使用這個了用戶信息生成的。換句話用戶信息才是核心,.Net中用戶信息的體現(xiàn)從底到高分別是:IIdentity->ClaimsIdentity-> AuthenticationTicket,關(guān)于用戶的身份信息可參考:《ASP.NET沒有魔法——ASP.NET Identity與授權(quán)》,在基于授權(quán)碼的模式時通過在授權(quán)服務器的登錄功能獲得了用戶信息,而基于用戶名密碼模式時沒有這個跳轉(zhuǎn)登錄環(huán)節(jié),所以需要直接通過用戶名密碼來獲取用戶信息,其實現(xiàn)如下重載了OAuthAuthorizationServerProvider類型的GrantResourceOwnerCredentials方法:
該方法從Owin環(huán)境中獲取Identity中的UserManager對象,通過UserManager來驗證用戶是否存在,如果存在則將使用用戶信息來創(chuàng)建一個ClaimsIdentity對象(注:此處是省略的實現(xiàn),正常實現(xiàn)可根據(jù)需求參考Cookie驗證方式將Scope或者Role等信息也添加到Identity對象中)。另UserManager是通過以下代碼添加到Owin上下文中的,它的Key值是"AspNet.Identity.Owin:" + typeof(ApplicationUserManager).AssemblyQualifiedName。
使用用戶名密碼獲取Access Token:
客戶端模式和用戶名密碼模式是類似的,它是通過Client的Id以及密碼來進行授權(quán),使用的是Client相關(guān)的信息,它的實現(xiàn)方式如下,重載GrantClientCredentials方法,通過客戶端驗證后的id和密碼信息來驗證改Client是否合法,對于合法的Client為其創(chuàng)建Identity對象(注:此處可以根據(jù)實際需求在Identity中添加相應的屬性):
使用Client信息獲取Access Token:
以上就是.Net中對于OAuth的實現(xiàn),另外.Net中沒有提供簡化模式的接口,但是提供了一個GrantCustomExtension,也就是說授權(quán)模式是可拓展的。
本例中除了授權(quán)碼以及刷新令牌是2個Guid連接外,訪問令牌(包括所有授權(quán)模式生成的令牌)以及授權(quán)碼對應的用戶信息、刷新令牌對應的用戶信息都是經(jīng)過加密的,其加解密對象創(chuàng)建過程如下,具體內(nèi)容可參考《ASP.NET沒有魔法——ASP.NET Identity的加密與解密》
上述就是小編為大家分享的ASP.NET MVC中怎么使用Oauth2.0驗證身份了,如果剛好有類似的疑惑,不妨參照上述分析進行理解。如果想知道更多相關(guān)知識,歡迎關(guān)注億速云行業(yè)資訊頻道。
免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。